Advanced Shipping and Receiving – Go-live support insights in bgRFC based EWM-TM integration

[MJachmann]

Introduction

With the Advanced Shipping and Receiving (Adv. SR) functionality the integration of  SAP S/4HANA Supply Chain for Transportation Management and SAP S/4HANA Supply Chain for Extended Warehouse Management is refactored, compared to the direct integration of SAP TM Freight Order to the SAP EWM Transportation Unit (see also the blog entry of Jörg Michaelis).

While in the integration scenario of TM Freight Order and EWM Transportation Unit the webservice interface “TransportationOrderLoadingAppointmentNotification” is used, for Adv. SR a direct integration of the EWM warehouse order documents and the TM Freight Unit is implemented. During the updates of the document's situations can occur in which an asynchronous processing of updates is necessary (for example the TM documents are locked exclusively by another process).
For these asynchronous updates TM facilitates the Background RFC (bgRFC) technology in combination with the TM trigger concept (for further details to the bgRFC concept, please refer to SAP Notes: “2930217 – bgRFC Concept and High Level Process in SAP Transportation Management”, “2526415 - Updated trigger concept using bgRFC processing” and “3125518 - bgRFC maintenance in the context of SAP Transportation Management”. For more general questions regarding the bgRFC configuration refer to SAP note “2309399 - How to use SBGRFCCONF effectively?”).

In SAP Transportation Management the trigger concept and the usage of bgRFC technology for asynchronous processes are used since TM 9.5 / S/4HANA 1709 (compare SAP note 2641251).
Both is not exclusive for the Advanced Shipping and Receiving processes. Non the less, during the past Go-Lives with the Adv. SR processes and the close integration of the TM documents to its predecessor documents in LE and EWM, the trigger processing has been more in focus (for more details on monitoring the bgRFC units in Transportation Management see the SCN blog Analyse bgRFC Units created by SAP TM application.).

As the understanding of the trigger concept and the processing of the triggers is now of more importance for the operations monitoring, I want to share some of the insights our CoE team has gathered in the past Go-Lives which we supported in this blog.

Disclaimer: The described concept is of the status in the S/4HANA 2022 release. Changes to the concept or the implementation might apply in subsequent releases.

BGRFC update concept in Adv. SR

During the process execution of the Advanced Shipping and Receiving in- or outbound process the TM Freight Unit has to be kept in synch with its predecessor documents. Depending on the integration scenario and process state this can be the MM/SD order documents, LE deliveries or EWM in-/outbound delivery order documents. If applicable and necessary, these updates are processed asynchronously. For these asynchronous updates TM utilizes bgRFC units which refer to specific TM triggers. Along the process execution different TM triggers are used for different update scenarios. This might be explained in more detail in another blog post.

All the different triggers which are used in the Adv. SR processes are stateless, i.e., the triggers themselves do not carry any information which change to the source document created the trigger for the update of the target document. Thus during the processing of the trigger the application will derive the updates from the predecessor document.

The picture below shows a detailed example to explain the concept: In the loading of a EWM Outbound Delivery Order (ODO) contains four Handling Units (HU). The Outbound Delivery Order refers to one Freight Unit in which the HUs are reflected as Package Items.
In the example the Freight Unit is locked exclusively by an End User and thus the loading information cannot be updated in the Freight Unit by the EWM loading process immediately. The loading process of each HU will create one bgRFC trigger, which will be reprocessed periodically using the bgRFC framework. The time between each reprocessing is derived by a S/4HANA TM specific application logic.

At the point of time when the first of the four triggers is being processed, the source document – the EWM ODO – already contains all the changes which lead to the creation of the bgRFC units. Thus once the first trigger is processed, the other three triggers are obsolete as the update to the Freight Unit is not derived from the trigger context (-> stateless 😉), but from the source document directly.

To that reason the application added some logic to identify situations in which the triggers are obsolete and then shortcuts the processing of the BGRFC units, to avoid overhead in the processing. The following picture shell illustrate that behavior:

When monitoring BGRFC interfaces for ASR processes it can be observed that a higher number of triggers queue up for one TM document – for example due to locked Freight Unit – and then suddenly all triggers are gone. That is exactly the situation described above that the first trigger brings all relevant updates to the TM Freight Unit und thus the processing of the subsequent triggers is not applying any changes and thus consumes significantly less time.

Some technical details on the update process

Regarding the above described process some questions might come up, like:

• Where are the TM Triggers defined?
• How is the delay time between the reprocessing of the bgRFC units calculated?
• How does the application determine when a trigger is obsolete?

Regarding the definition of the relevant TM Triggers we have to take a look at the BOPF object /SCMTMS/LINC. This object has been introduced with the Adv. SR processes. The “Logistics Integration Controller” object contains business logic for the integration of the TM Freight Unit to its predecessor documents.
Each Action on the ROOT node of the /SCMTMS/LINC object corresponds to one of the triggers used in the Adv. SR processes.

As described at the beginning for one TM document multiple triggers of the same type can exist for the same S/4HANA TM document in parallel. During creation of the BGRFC unit also an instance on the ACTIVITY node of the /SCMTMS/LINC object is created.
Via the root node information of the document ID (BTD_ID) and the document type code (BTD_TCO) the Activity is linked to the predecessor document. The activity itself contains the information for which trigger type it has been created via the TRIGGER_ID field. The processing status indicates if the relevant change is scheduled (value “S”) or already processed (value “P”).

To identify which document type code is referring to which document type the attribute “C_TBD_TCO” of constants interface /SCMTMS/IF_COMMON_C can be checked, as shown in the screenshot below on the example of the EWM ODO, which has the document type code “496”.

In the above provided example of the loading process the relevant BOPF action is “SET_TOR_STATUS”. Within the implementation it is checked if for the particular trigger a scheduled activity exists.

The screenshots show that in case no scheduled activity node can be found, the processing logic of the BOPF action is not executed.
After successful processing of the LINC action, also the activity node is updated.

Thus, after successful processing the status of the relevant node instances on the activity node of the LINC object will be updated from “S – Scheduled” to “P – Processed”. When the next trigger is processed and no open activity for this trigger type is found, the trigger will be processed without applying the entire application logic.

BGRFC Wait Times

In the beginning of the blog, it has been mentioned that the time between the reprocessing of a bgRFC unit in S/4HANA TM is derived by an application specific logic. The application specific logic is based on the retries of the individual BGRFC unit. The logic is implemented in class /SCMTMS/CL_TRIG_HELPER. 

Besides the wait time also the maximum number of retries per bgRFC unit is handled in the application specific logic. The default retry count is set via the member variable of class /SCMTMS/CL_TRIG_HELPER and is defaulted as 256 retries.

The bgRFC units in S/4HANA TM are processed for 2 days with an implemented cool down mechanism so that units which could not be processed successfully will have increasing delays between reprocessing.

Summary

The provided example should give a brief explanation how in the Advanced Shipping and Receiving processes the stateless updates between EWM and TM are processed using the bgRFC concept.
The example briefly explains the application specific calculation of the reprocessing wait times for the bgRFC units in Transportation Management.

Having worked through go-lives of interfaces which used sequenced messages that had to be processed exactly once and in the right order to ensure a consistent document status along the document chain, I found the stateless trigger concept quiet handy since I did not need to care in which sequence the messages needed to be processed.
Furthermore in the Adv. SR. process a single failed bgRFC unit does not block the entire queue, so that a unit which for example failed due to a temporary inconsistency does not necessarily block the entire communication between EWM and TM for the affected documents.
At the same time when I first worked with this concept in scenarios with many updates happening in a short period of time I needed a moment to get used to the idea that it does not matter which trigger was created by which change or in which sequence the trigger needed to be processed.

I hope the provided example helped you to understand the advantage of the stateless trigger concept, the calculation of the wait time between the reprocessing of the bgRFC units and the mechanisms implemented in the application to avoid unnecessary trigger processing.

Learn more about SAP Premium Engagement and how a global team of experts can help you to get the most out of your SAP solutions.

If you already are a Premium Engagement customer, contact your Technical Quality Manager (TQM) to discuss how Premium Engagement services can help you with a custom-tailored and efficient service portfolio to make your project a success!

#CoE EMEA SCM1