You've got to challenge yourself once in a while. In this series, we'll build a number of microservices and show how it pushes the boundaries of what can be accomplished with low code platforms. This challenge will provide a valuable opportunity for senior developers to test their skills and gain a deeper understanding of the potential of low code development. So, without further ado, let's dive into it!
We will build an enterprise IT solution for DPS, which I will introduce you to in a minute. I’ve been developing for a while now, but I would like to improve my skills to write user stories. It’s fun to acquire new skills by doing, so I created this code challenge. The case I’ve chosen is quite comprehensive, so I didn’t go into much detail for some stories. Take your creative freedom and enjoy it! 💫
In the coming weeks I will be releasing stories for this challenge. I'll keep this post updated as an overview for coming stories.
Please download the ZIP file here. That'll give you head start. The starter pack will contain the following things:
- An Outsystems application to create test data (OML)
- A project description
- The first story of this code challenge
As mentioned above, I'm using Outsystems to develop my applications. However, you may choose your language / framework / IDE of choice. I have included my mock data in the Resources / Data folder, so you can use that to test your application. Now we are set up, let the fun part begin!
Introduction
Difficulty: Advanced
Stories: 11
The renowned Dutch Parcel Services has issues to keep up with its growing demand. Legacy systems are preventing it from scaling up its business. Changes necessary to attract new drivers and customers take months to implement. This means astronomical costs in both maintenance and development. For example, of every dollar paid for a parcel, $0.28 of it was spent on IT infrastructure. One example why DPS needs to spend so much, is due the use of COBOL in most of its core systems. The consultants to develop these systems, if available at all, charge excessive amounts. This is threatening for DPS revenue. Last year DPS lost 1.19 million in profit. Shareholders are warning this year will be the same, if no immediate actions are undertaken. In short, DPS’ core systems needs to change, and they need to change fast.
Recently, DPS came into contact with Outsystems. They have asked you to create a MVP for some their core systems. In short they want to receive request to send parcels from business customers, track and update parcels throughout their journey and expose that to their customers.
As the board is a bit sceptical about Outsystems capabilities, it’s your job to convince them. Since DPS is a multinational, architecture is important. Before jumping into development, take a step back and consider all the parts required. Read all the stories, map them to larger concepts and consider how they impact each other. This ensures that DPS is able to grow as promised.
DPS is mainly focused on delivery parcels, since the rise of e-commerce. We’ll be building application to support this process. In short this process looks like this:
![Parcel delivery process of DPS](https://res.cloudinary.com/dqwogyxqp/image/upload/v1679520186/Shipment_process_description_e4cdb55584.png)
User stories
Each part of this process will be described in one or multiple stories. DPS requires high performance applications. Each day, DPS delivers roughly 560.000 parcels to their customers. All these packages needs to be registered, tracked and planned properly. Both logic and interfaces need to be efficient. Fault tolerance is also a topic to consider. Not every parcels journey is completed the first try. Packages might get lost, are send to incorrect addresses or exceed weight limits. Log errors, implement business checks and provide ways for employees to resolve errors.
Good luck and have fun while completing this challenge!
Story #1: Request shipments
Description
As an business to business customer I would like to request shipments using my own e-commerce package through an integration. In this request I will provide an origin and destination address, addressee, packet size and weight. After submitting the request, a shipment is generated. I can retrieve this shipment, and other shipments, via a second integration endpoint.
For each shipment an unique code is generated, which follows the following pattern: DPS028523112862212. This code will be used later to identify the package.
To request shipments in a secure matter, we need to verify shipment requests using a client id and token. After validation, a shipment request may be registered. If validation fails, the request is simply discarded. A list of valid credentials is provided below.
Shipment addresses will need to be created, if not available.
Since DPS receives thousands of these requests, possibly simultaneously, we need to guarantee handling of the requests. This means we need to implement scalability right into our infrastructure.
To simulate the package requests, we created small mock application. We included the application package below. Run the timer in RequestGenerator_CS to generate shipment requests.
Criteria
- Requests are processed real-time
- Requests can only be made authenticated
- Unique shipment code is created per shipment
- Invalid requests are moved to an error queue, including an error message
- Able to retrieve a list of shipments including details