Running the API and editing the solution in the interface
We recommend the following use case:
-
The solution is sent via the API from the source system.
-
A business user logs in to the RouteQ interface and then views or edits the solution.
-
If the solution was edited, the user exports the resulting solution to the RouteQ internal system. The link between the edited solution and the source solution is saved automatically. To get the edited solution later, you can use the /children request with the ID of the original task. By not editing the solution, the user confirms that they're content with the obtained solution.
-
The final solution is downloadable regularly via the API.
Note
The final solution is optimized again after manual adjustments. Treat it the same way you treat other API tasks for route optimization: wait until the task is completed.
Child tasks
You can link route planning runs to each other by task_id
. As a result, the parent task will be uplinked by one or more child tasks. This way you can get the list of linked tasks from the parent solution ID, and continue working with any of child task.
A child task can have multiple other child tasks (in other words, be a parent task itself).
Child tasks can represent edited versions of the original result. Besides changes made by the logistician at their discretion, the solution is adjusted during additional planning. If the new optimization runs are linked to the original task, you can upload the updated routes to the source system using the parent ID.
Another use case is to compare different solutions for the same task. You can request a list of child task_id
by the ID of the parent planning. This way, you can compare the indicators for different versions and select the best-suited option. Solution metrics are available in the result.metrics
field of the API response.
How it works
Alert
Parent and child tasks must be received from the same API key.
The link is established using the query parameter parent_task_id
that passes the ID of the parent solution when the routing task is added. (This ID is returned by the service after the parent task is created.)
The list of child tasks includes the task_id
of the linked solutions and the time they were run (added_at
). You can get this array by the parent_task_id
and then download the results you want to work with next.
Example
Routes built during the first planning:
API request (JSON) ⋅ API response
The result was adjusted by the logistician (one order was handed over to a less loaded courier). A new solution has been created:
API request (JSON) ⋅ API response
When you send a query with the edited solution in the query's parent_task_id
parameter, indicate the source planning ID so that the second task becomes a child of the first task.
The list of child tasks contains information about the edited solution:
[
{
"task_id": "bd593556-342668cc-db3bcdfe-c98d112c",
"added_at": 1632906716.03281
}
]