Request/Delayed Retrieve Workflow

The Publish/Retrieve Workflow traces containers through three distinct processes. The first process publishes container requests to the provider system, ensuring that the provider is aware of which containers need tracking. This step initiates the retrieval process and logs the request details in the database. The second process is a scheduled retrieval mechanism that runs every given time, curretly it is setup though configurations to run every 30 minutes. This process queries the database for container requests that have been pending for at least 30 minutes, groups them by customer, and then retrieves the latest status from the provider system. By structuring the retrieval process this way, the system ensures efficient data fetching and avoids unnecessary repeated queries. The third process handles the response from the provider system. Retrieved data is normalized and processed to ensure consistency. If container information is successfully retrieved, it is marked as traced successfully and the TMS application receives the results through the registered Web-Hook, If a container is Not Found, it is automatically re-published for another attempt in the next scheduled cycle. This iterative approach ensures all container requests are processed effectively until a definitive result is obtained.

Currently, GPA is the only provider that works this way, but there might be others in the future.

The following sections document the providers that use the Request/Delayed Retrieve Workflow:

Contents:

• GPA