1. Technical IDs in APIs for Carrier Integration
Technical ID in Consumer API for Subcontracting
TechnicalID in consumer API for Subcontracting
Technical ID in Consumer API for Order Tracking
TechnicalID in consumer API for Tracking - Freight Order
Technical ID in Consumer API for Booking Confirmation
TechnicalID in consumer API for Booking Confirmation
Technical ID in Consumer API for Order Tracking - Freight Booking
TechnicalID in consumer API for Tracking - Freight Booking
Location ID in Consumer API for Order Tracking
Location ID in consumer API for Tracking
Technical ID in Consumer API for Order Tracking - Global Track and Trace Shipment
TechnicalID in consumer API for tracking - GTT
2. Exception occurred while creating or updating the location
Sometimes you see this error when a shipper initiates a tracking request. The error is not specific but does indicate a possible problem.
When a shipper initiates a tracking request, it is considered an A2A call and the system tries to update the location master data from TM into BNL. In this particular case, the shipper maintained a faulty UNLOCODE for the location. (3 characters as opposed to standard 5 characters).
So, if this error is seen, shippers should check the location master.
3. No matching stop found while reporting events
Carrier reports events via Tracking APIs and all the logs in BNL and CPI show it was successful. However, events are not seen reported against the Freight Order - Execution tab in TM.
On checking srt_moni you will notice some error logs:
Log in srt_moni
As the error indicates, the shipper would have configured mandatory stopIDs for one or more events. This configuration is available in:
4. AccessToken fetch error
One of the scenarios where this error is seen is when a Network Partner is involved and is responding to a Freight Booking confirmation via the API. You will notice that the API call itself gives a 200 OK and also gives a JSON response, but the error will be seen in Manage Integration Logs app as below.
Freight booking API has fields, documentRecipientParty, senderParty, and recipientParty. The values in these fields differ in the consumer and provider calls, that the Network Partner makes. The error occurs when there is a mismatch in the value sin those fields resulting in token issues. To understand the usage, refer this blog.
5. Attachments sent via APIs and application behavior.
General Attachments:
Attachments in Freight Order for Confirmation app
Event Attachments:
Attachments shown in Track Freight movement app
6. Timezones and event reporting
Scenario | UI/API | FC | GTT |
Location has timeZone and event reported without timeZone (API) | API | UTC reported time is converted to location Timezone | UTC reported time converted to users local timezone. |
Location has no timeZone and event reported without timezone (API) | API | Cannot create Locations without Timezone. | UTC reported time converted to users local timezone. |
Location has TimeZone & event reported with a different timeZone (API) | API | UTC reported time is converted to location Timezone | UTC reported time converted to users local timezone. |
Location has no TimeZone & event reported with a different timeZone (API) | API | Cannot create Locations without Timezone. | UTC reported time converted to users local timezone. |
Location has TimeZone & event reported with a different timeZone (UI) | UI | UTC reported time is converted to location Timezone | The time reported is considered to be for the timezone given and the user sees converted local Time |
Location has no TimeZone & event reported with a different timeZone (UI) | UI | Cannot create Locations without Timezone. | The time reported is considered to be for the timezone given and the user sees converted local Time |
Unplanned Events with timeZone | API | Converts it to the time based on the timeZone sent and shows that timezone as well in the UI. | UTC reported time converted to users local timezone. |
7. invalid_client, Bad Credentials error while reporting events via API
Sometimes when a carrier reports events the below error is seen. The credentials used are also correct.
Error in MIL app
This happens when the shipper is subscribed to FC but the carrier is reporting event with the technicalId suffixed with GTT or vice versa.
egs: "xri://sap.com/id: LBN#10010005000:BS_SAP:FreightBooking:65000000550:GTT".
To resolve this, the carrier has to make sure the right suffix is sent after discussing with the shipper.
8. FreightOrder with altKey does not exist error
While reporting events, carriers sometimes see this error in the MIL app. The call itself to report events will respond with a 200 OK.
This happens when the Order is not set to "Ready for Transportation Execution" by the shipper. To resolve this, ask the shipper to change the status of the Order, following which events can be reported.
9. JSON parse error: Cannot deserialize value of type com.sap.lbn.trackingservice.domain.input.generic.TransportationMode from String "04": not one of the values accepted for Enum class: [01, 03]
This error is seen in MIL(Manage Integration Logs) app when a carrier is trying to report events via API.
This is because the carrier is reporting the event to FC (Freight Collaboration) with transportMode as "04". As the error suggests, FC only supports reporting events for modes 01(Maritime) and 03(Road) only. However, GTT supports more modes in the reporting API.
10. Carrier Document references reported via tracking are not seen in TM
Carriers while reporting events via API might also want to send some document references, however, due to a limitation in the TM interface-TransportationEventBulkNotification_In these document references cannot be mapped and chance cannot be pushed to TM.
So, if a customer has a use case to receive document references while the order is in execution, they can consider sending an update to confirmation and pass the document references, so that it can be updated in TM against the order.
11. Location ID exists already while configuring Cloud Connector details
BNL allows shippers to configure the technical user and the Cloud Connector Location ID in the System Connections app. This configuration can be reused across tenants if it's within the same Global Account. However if the tenants belong to different Global Accounts, BNL recognizes that the configuration already exists with the same location ID or the User and throws this error.
If it's in the same GA, you don't need to add it again, but rather reuse the config. If its in a different GA, then due to the current limitation that the configuration is not seen in the dialog above, you will have to check if there is any tenant that uses this config and either remove it if unused or configure a different locationID.
12. FC and GTT both for Tracking
There are instances where a customer might use both Freight Collaboration and Global Track and Trace for Tracking depending on the capability of the carrier.
The use case could be that a few carriers prefer to manually report events via the Freight Orders for Reporting app in carrier portal and a few carriers integrate to report events via GTT.
When both are active, by default 2 consumer requests go out to the integrating carrier, one from FC and another from GTT (can be differentiated by the suffix to technicalId). To avoid this, the shipper can deactivate, /SCMTMS/CO_CPX_TORGNTRCKPR_OUT SOAP interface to avoid the FC consumer request from going out. However, they have to make sure the trackingRelevanceIndicator is active so that manual reporting in FC works.
13. Instance Authorization Check Failed in GTT while reporting events
This error is seen when a carrier is reporting events. The call itself would be successful, but the error could be seen in logs. This happens when the carrier LBN ID sent by the carrier does not match the serviceAgenLbnId maintained by the solution owner/shipper. In the particular case above, carrier is reporting at FU level and the FU did not have a serviceAgenLbnId maintained.
14. 108 Missing necessary connectivity configurations or CLOUD_CONNECTOR parameter not found in the Partner Directory for the partner ID (LBN ID)
You might be familiar that customers are recommended to move to Multi-Cloud integration platform. However, we also caution not to delete old, Neo configuration in System Connections app. This error is seen, if a document was exchanged while having Neo config and then the Neo Config was deleted and the Multi-Cloud config was retained. This issue will not be seen on Newly created document objects which are exchanged on the same integration platform config.
15. SOAP messages not generated for SAP TM to BNL scenarios
In some cases, after the setup, you may encounter that SOAP messages not are not getting trigerred and no logs are seen in srt_moni. In this case check for 2 customizations:
1. PPF setting for /SCMTMS/TOR - The right action profile should be maintained.
2. Also make sure the right settings for integration and output options are maintained here for the scenarios that are failing.
Note 1: Before applying any of the above suggestions, make sure to perform a test in your non-production environment as each scenario could be different.
Note 2: This blog will be updated regularly with more Tips & Tricks. If you are interested in receiving updates, make sure to subscribe and bookmark the blog.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
7 | |
5 | |
3 | |
2 | |
2 | |
2 | |
2 | |
2 | |
1 | |
1 |