Artykuł How Advanced Routing and Optimization can support an emergency response actions – use case study pochodzi z serwisu Inero Software - Software Consulting.

Why Angular?

At Inero Software we are using Angular at the front-end side of most of our projects and that is not without a reason.

• It is suitable for big software systems because of its component-based architecture which provides a higher quality of code, better maintainability, and code reusability.
• Native Typescript support, Typescript means Types and that means safer code.
• Angular, unlike other frameworks, is fully stacked with predefined solutions to problems you may approach, you don’t have to think about which library to use for every single implementation case whether it be routing, reactive programming, or making Http requests.

What’s a back-end long-running asynchronous task?

The easiest way to understand what’s a back-end long-running asynchronous task is to explain it with an example of our product which possesses this kind of task.

At Inero Software we are developing a product called DeliverM8 which is a delivery optimization platform. It has many functionalities but let’s focus on the important one for today’s article. Imagine that you run a company that is delivering products all around the country. You need a system that would display to you how many products and which products to put onto a truck and also how should they be ordered so that everything fits nicely.

Input requires the following data:

• How many products should be delivered?
• What are their sizes?
• Where do they go? (so we know which products should be on the beginning or end of the truck etc.)

The output is a 3d visualization which looks like this:

As you may imagine – it does take time for a backend service to create output like this, the AI that stands behind DeliverM8 logic runs millions of operations per second in order to find the best optimal available element arrangement. This is the back-end long-running asynchronous task. Depending on the input this may take up to 10 minutes and of course freezing of the frontend application until the data is retrieved is the last thing that we need, so what should we do?

Approaches

A DISCLAIMER: All examples are made with Angular, but the concepts mentioned below can easily be applied to any other frameworks/languages.

Synchronous

Probably the worst option out there but should be mentioned nevertheless. If in fact, the user shouldn’t be using the application, while he is waiting for the response, then you can just put some kind of modal loading screen while the user awaits the data and the problem is solved.

How:

You send a single POST request that tells the backend to start the calculations and return the data within the response of the beforementioned request.

Example:

public loadTrucks(loadTruckData): Observable<Route[]> {
return this.http.post<Route[]>('/api/load-trucks', loadTruckData);
}

Polling

Now polling is a slightly better option if the user wants to use the application while the data is loading and you don’t have that much time to invest in the solution and/or your backend is not providing you with WebSockets then polling is the way to go.

Polling means checking the status of (a backend endpoint in this case ), especially as part of a repeated cycle. Translating it to front-end language means making a get request every few seconds to see if the asynchronous task is finished. For backend that would mean creating a new GET endpoint that would return the calculated data. (if in fact it has been calculated before)

Not the most elegant solution out there but still pretty usable!

How:

We make one POST request that informs the backend to start the calculations and one more GET request to get the output data.

One of the ways of polling is combining RxJs’s timer with switchMap. Also remember to unsubscribe, because all sorts of intervals can easily produce memory leaks, in this example, we are using takeUntil operator that unsubscribes from the observable when it’s component is destroyed.

Example:

timer(0, 5000).pipe( switchMap(() => this.truckService.getLoadedTrucks()), takeUntil(this.stopPolling) )

Websockets

Websocket is a communication protocol (just like HTTP) “for a persistent, bi-directional, full duplex TCP connection from a user’s web browser to a server”. Basically what it means is that with WebSockets you can send out the data from the server and receive it in your frontend application without making any unnecessary requests (like you would using polling).

With the Websocket approach, you would send an HTTP POST request to start calculating the truckload. And at the same time, you would establish a WebSocket connection between the Frontend application and the server so that when the backend tasks finish the output is sent through that WebSocket connection.

How:

Send HTTP POST request that informs the backend to start the calculations and listen on Websocket connection with a backend that returns data when the calculations finish

Example:

At first, you connect to a WebSocket:

public connect() {
const socket = new WebSocket(this.webSocketUri);
this.stompClient = Stomp.over(socket);
this.stompClient.connect({},
() => this.subscribe()
}

And later on, you subscribe to its values:

this.stompClient.subscribe('/user/queue/truck-load-updates-queue', (msg: Stomp.Frame) => {
const msgBody = JSON.parse(msg.body);
...
});

The subscription above is triggered after the calculation is done.

Conclusion

That’s it!

I’ve described to you the problem of back-end long-running asynchronous tasks and various ways of handling them in the frontend application.

Websockets are the best way to go if you are struggling with this problem, but if the user doesn’t mind getting his application blocked (or maybe it is intended to block the app for the time being) for the time when the backend is performing its tasks then you can simply go with KISS principle and just make one synchronous request.

Polling is also an option if the developers don’t feel like implementing WebSockets and additional network movement is of no concern.

Thanks for reading! And I hope you liked the article 🙂

Artykuł Angular: How to manage back-end long-running asynchronous tasks pochodzi z serwisu Inero Software - Software Consulting.

One of our teams field of specialization is the use of artificial intelligence for modeling and optimizing complex transport models. From the practical point of view, the optimal planning of transport resources and supervision of their implementation is one of the key tasks in the area of ​​supply chain management.  In this type of solutions, using artificial intelligence and advanced computing IT systems can bring  observable benefits. One of the solutions this post refers to is the optimization of redistribution network of the supply chain (RCSN).

Pros, cons and uses

RCSN is an alternative to the centralized distribution networks (CDN) that consist of one central warehouse for the storage and distribution of goods. CDN is effective if we carry out large, repetitive orders to destinations that are close to each other. If our supply chain get’s more complicated we can add some a number of local warehouses to place the goods closer to final destination. While the CDN generally simplifies transport management, it does not allow to optimally distribute costs of supply for complicated logistic models. Though the RCSN is more complex and more expensive to manage compared to the classic versions of warehousing, with the support of a specified IT solutions it guarantees a stable level of services, maintaining the performance of order management and distribution. 

Use case

In this article, we will show how Inero Software team deals with the above-mentioned problems in an example use case. Let’s assume that we have a company with many branches and we need to exchange the necessary materials between them for proper functioning. To optimize costs and efficiency, we don’t always need to complete another large order from the supplier, but we exchange materials between nearby branches. It is a much better and faster solution, and one of the most important aspects is that it minimizes the workload. 

Let us assume, that in our showcase , we have 4 drivers and 40 company branches between, where each branch belongs to 1 of 4 groups( indicated by pin color in figure below). In the given use case, it was assumed that the goods may be stored and exchanged only between locations from the same group (a pin of the same color on the map), but the transport flow must be maximized between all locations. In order to optimize the total supply chain, it was assumed that the closest locations in a given group are the warehouses in the vincity of the particular driver’s home-base. This means that before the commodities are exchanged between individual points, the driver must pick up the goods from the defined warehouse and store them at the end of the daily route. 

In addition, when generating routes by the system, optimization algorithms takes under consideration following constraints: 

• each driver starts and finishes his/hers route at the warehouse. This means that the driver cannot leave any goods in the car for the night before/after the route;
• goods are intended to be transferred among one group and cannot not be stored in the local warehouse (destination) of other groups. However, commodities dedicated for different groups, can be transported by the same vehicle;
• every destination (location) can be considered as a local warehouse;
• the driver cannot exceed the driving time and daily mileage limit;

Moreover, some other specific limitations can be defined in the system, e.g. that the driver can only move in a restricted area, maximum 9 hours a day, can be defined. In this context the goal of the optimization is to maximize cargo flow between different branches of the company. 

The picture below shows an example of the result optimization of redistributing goods using our solutions.  

As you can see in the picture above, the system has generated a driving plan for each driver for each day of the week. Thanks to this, we can ensure the exchange of the necessary goods in a given area, even several times a week.  

As part of defining individual locations of the local warehouses, each of them was given a unique id in the range 10-49.  The illustration below shows the generated driver’s work plan divided into individual days. 

It can be seen that the simulation requirements were met. If we visit a certain group on a given day, we initially pick up the goods and finally store them in the same unit belonging to the same group.  

If the problem would require the exchange of goods between larger areas, e.g. from the western part of Poland to the northern part, etc., the implemented software could be extended with drivers’ meeting points and the exchange. Then, the cargo can be delivered depending on the demand to specific branches of the company. This process is based on the previously generated solution. The system’s algorithms determine which locations have been selected for drivers’ routes. On this basis, the route-based, the system finds the closest point on the map where drivers can potentially meet. If there are such places, they are added at certain times, (e.g. 12pm to 1pm, Monday) to the driver’s schedule. In the next stages, the system intelligently selects the remaining locations, maintaining continuity and increasing the area of exchange.

The figure below shows the location of meeting points on the Monday route for drivers’ routes (Szczecin – Gdańsk) and (Wrocław – Legionowo).   

Cargo swap points have been given a unique id to include them along the route. 

• (Szczecin – Gdańsk) – 100, 
• (Legionowo – Wrocław) – 101.

As you can see, meetings are held at designated times. Thanks to this operation, we exchange goods between larger areas, and in the next days we can distribute it to other locations. 

Solution

In our solutions, we use methods and techniques of artificial intelligence to model the problem of redistribution of goods and then optimize the commodities flow in distributed network. In situations where a large amount of calculations is required, various heuristic methods come to the rescue. They allow to minimize calculation costs and speeding up finding the optimal solution. Heuristic searches are suitable for complex problems. The artificial intelligence estimates quality of available solutions, and every iteration improves output result. In the case of a logistic redistribution network, every step of the optimization, extends the resulting node (i.e. in our case the route) with the node with the lowest value of the predefined evaluation function. 

In our solutions, for example, we use the greedy algorithm. The model at each step makes the optimal choice at the moment, based on the given evaluation function. In the case of transport problems, it will certainly be the number of kilometres imposed converted into costs compared to the current fuel price. The algorithm, by adding new customers along the route, makes the optimal decision, i.e. the cheapest one at the moment. 

The simplest form of the evaluation function can be defined as: 

cost = new_distance - current_distance

where:

new_distance – total distance to the new point from the driver’s location, 

current_distance – current distance, from the driver’s location to the actually last point. 

Summary

The use of IT systems supporting the supply chain redistribution network definitely allows for an optimized flow of goods. In addition, it can provide many additional analytical tools, such as: 

• order and invoice reports,
• archiving statistics,
• delivery time information system, 

and many others tailored to customer needs… 

Artykuł Redistribution supply chain network pochodzi z serwisu Inero Software - Software Consulting.