When an interactive routing/rating/scheduling (RR&S) or routing/rating (R&R) request fails, a row will be generated in the Routing/Rating/Scheduling Message Log table for each route that was considered. This table will be referenced when the user triggers the Message Log operation. Data in this table is transient. Data will not be recorded in this table when a background RR&S or R&R request fails.
The output structures for the following APIs include a Rating Request ID:
When the ReturnRoutingMessageLogFlag from the Load, Trip or Shipment Rating API is True, or the ReturnDiagnosticsFlag from processRateQuotation is True, and rating fails, the Rating Request ID will be returned. The RoutingMessageLog in the output structures for these APIs simply contains a high level summary message, for example, “No Valid Lanes.”
With the returned Rating Request ID, integration is expected to use the findEntity API to get entries from the Routing/Rating/Scheduling Message Log table and use the processRoutingMessageDetailsDelete API to delete the message log entries when they are no longer required (more on this below). The Routing/Rating/Scheduling Message Log table structure will not be included in the API output to avoid negative performance resulting from large output message sizes. A significant amount of data could be returned when a large number of lanes exist. If the message log is not required, the ReturnRoutingMessageLogFlag or ReturnDiagnosticsFlag should be False.
The Routing/Rating/Scheduling Message Log table will contain the applicable message text rather than a code. This message will be captured in the requesting user’s language. Dates and numbers will be embedded as parameters in the message in the table. When rendered on the UI, these will be formatted using the requesting user’s date and number format. For messages generated by APIs, date/time format, and number format will use the defaults from the International Components for Unicode (ICU).
The Routing/Rating/Scheduling Message Log table will not be persisted permanently since any type of change (for example, tariff, shipping location, carrier, customer profile, the applicable entity) may invalidate the information.
The message log data will be purged by Transportation Manager automatically when one of these events occurs:
For rating and rate quotation API calls, since Transportation Manager will have no control or visibility as to when the rating request session “ends”, integration will be expected to use the new processRoutingMessageDetailsDelete API to delete the message log entries when they are no longer required. In the alternative, a system background job will clean up the old entries from the Routing/Rating/Scheduling Message Log table at a time interval specified in the server configuration tables. The default duration (in seconds) to retain diagnostic messages in the database before they are purged is 1800 seconds (30 minutes). Override is available using Server Configuration.