Optimizing TM-EWM & TM-GTS integration by leveraging FEH resolution strategies

[saravanakumar_subbiah]

This blog primarily focuses on optimally resolving integration & locking related issues typically found in the TM-EWM & TM-GTS integration space. As a part of this blog, I am sharing my personal experience on managing these issues typically found during SAP TM implementations.

 1.Problem Statement - Business object locking issues in SAP TM:

Integration with other supply chain execution modules such as SAP EWM (Loading/Unloading Appointment synchronization, Warehouse billing & Transit warehousing) and SAP GTS (Compliance and Customs) has been a key feature of SAP TM over the recent years. However, with the introduction of latest functionalities like Advanced Shipping & Receiving (ASR), We have started seeing situations where the TM freight unit/freight order object is simultaneously accessed by both bgRFC units (Which carries the updates from EWM) and XML document (Which carries compliance related updates from GTS). As a result, business object locking occurs which leads to data/status inconsistency.

Typically, the failed bgRFC units are automatically reprocessed by the scheduler and in case of failed XMLs, they can be reprocessed by one of the below the three methods:

1.Manual reprocessing by an end user

2.Automatic reprocessing by standard reports (Can be scheduled as batch jobs)

3.Forward error handling (FEH) resolution strategy (Error and conflict handler must be enabled)

Locking issues can also occur in the TU based TM-EWM integration method as well where in certain cases, the update for the freight order from EWM can fail since the freight order object is locked by another process within TM.

These situations can be streamlined by setting up FEH strategies which would ideally ensure that XML messages are reprocessed within specific time intervals when object locking occurs in TM.

2.Solution - Usage of FEH resolution strategy for smart reprocessing of XML messages:

Prerequisite: Error and conflict handler functionality must be enabled in the corresponding S/4 system to use the FEH strategies.

This can be activated from SPRO->Cross-Application Components -> General Application Functions -> Error and Conflict Handler -> Activate Error and Conflict Handler

As a next step, the FEH strategies can be setup from the below SPRO path:

SPRO->Cross-Application Components -> General Application Functions -> Error and Conflict Handler -> Define Resolution Strategy

In the initial screen, the value CA-SOA-ESM-SCM-SCE (which encompasses all TM related FEH strategies) must be updated in the component field.

Next, we proceed with defining the nodes for business process and the corresponding error categories.

2.1.Top-level node definition:

Typically, the FEH strategies must be defined in the following hierarchy:

Depending upon the project requirements, “N” number of business process specific nodes (covering multiple interfaces) can be defined under the top-level node. Error nodes are then linked with the business process nodes. In the above example two business process specific nodes have been defined under the top-level node.

Ideally, the control parameter for reprocessing each failed XML messages through the FEH strategies are defined under the “Target” section of the top-level node. This attribute is then copied onto all business process nodes defined under the top-level node.

• Here parameters such as the number of reprocessing attempts to be made, Frequency, Residence period etc. are defined.
• When both “Transient” & “Persistent” check box is enabled, the system would create an order entry in PPO2 once the maximum number of reprocessing attempts are completed. (If an order entry in PP02 is not required, only the "Target" checkbox must be selected) 
• Values must be defined within the target section after discussions with the project business team. Several factors such as data volume, system resource capacity, archiving capability etc. must be assessed before finalizing the values. The overall process must be thoroughly tested in the lower environments before moved to production via a transport.

 2.2.Business process specific node definition:

Beneath the top-level node, we define business process specific node along with a sub node for the corresponding error category:

Each TM interface in S/4 HANA has a business process name linked to it and these values must be defined under the “Selected Node” section.

 Example:

Interface	Business process name
TransportationOrderLoadingAppointmentNotification_In	TORLDAPNTF
TradeComplianceCheckSUITEConfirmation_In	CPC_CNF

2.3.Error category node definition:

A sub-node is created under the business process node where the corresponding error category is defined.

Typically, the value PRE.TEE.LRE is used as the error category for common issues seen in SAP TM.

Thus, the top-level node, business process node and error node are hierarchically linked together.

 3.FEH resolution strategies in action:

Once the FEH strategies are configured within the S/4 system, reprocessing of any failed XML messages that meet the defined criteria are taken care of automatically without any manual intervention or batch jobs.

In the above image, An XML message which was not linked with any of the FEH strategy typically fails as soon as it encounters locking issues. These XMLs typically move to “Transferred to External System” or “Application Error” or “System Error” status in SRT_MONI/SXMB_MONI transaction.

On contrary, XML messages linked to the FEH strategies were automatically reprocessed successfully.

4.Conclusion:

Integration related challenges are almost inevitable with the surge in cross module collaboration within SAP over the recent years. Hence utilization of standard tools, frameworks and strategies is essential to harmonize seamless execution of the business processes across ERP, TMS, WMS and GTS