- SAP Managed Tags:
In addition to my previous blog posts Integration Flow Design Guidelines for Exactly Once Scenarios and SAP Cloud Integration Supporting further Exactly Once Scenarios where I describe how to setup Exactly Once delivery on the Cloud Integration capability of SAP Integration Suite, I would like to point you to the latest integration flow design guidelines that we have published adding some more use cases in the area of Exactly Once delivery. Actually, we received feedback from customers struggling to setup Exactly Once delivery for scenarios where IDoc messages are sent from Cloud Integration to their SAP backend systems.
The IDoc runtime as such is idempotent, i.e., it can identify and ignore duplicate messages, if the following prerequisites are met:
The IDoc receiver adapter on Cloud Integration expects the unique ID in the header SapMessageId and adds its value in the node ARCKEY of the IDoc control header. If the header SapMessageId is empty, the IDoc receiver adapter creates a new ID. In case of a retry, a new ID will be created again leading to duplicates. So, you need to ensure that the header SapMessageId is set within your integration flow with an ID which remains the same for each message retry before calling the IDoc receiver adapter.
Let's take a look at the following simple example.
Here, we assume that the sender is able to restart messages and passes a unique ID to the integration flow. In the sample integration flow, we use SOAP with SAP RM protocol at the sender side which passes the header SapMessageIdEx to the integration flow. When restarting the message, we ensure that SapMessageIdEx remains the same.
Now, in a content modifier step we simply assign the value of SapMessageIdEx to the header SapMessageId. As said, the IDoc adapter now doesn't create a new ID, it uses at the end the value of the header SapMessageIdEx. This ensures proper duplicate handling at the IDoc receiver.
You find this scenario described at IDoc Receiver Handles Duplicates.
In total, we have added 6 new guidelines:
For an overview, check out Quality of Service Exactly Once.
Furthermore, we have added the Special Use Cases: SAP RM vs XI vs IDoc documentation where you can see at a glance which configuration steps are required to guarantee Exactly Once delivery for special use cases where the receiver protocol supports idempotency focusing on SAP RM, XI, and IDoc.
The IDoc runtime as such is idempotent, i.e., it can identify and ignore duplicate messages, if the following prerequisites are met:
- The IDoc content type has to be Application/x-sap.doc
- You pass a unique ID to the receiver system that keeps the same for each message retry
The IDoc receiver adapter on Cloud Integration expects the unique ID in the header SapMessageId and adds its value in the node ARCKEY of the IDoc control header. If the header SapMessageId is empty, the IDoc receiver adapter creates a new ID. In case of a retry, a new ID will be created again leading to duplicates. So, you need to ensure that the header SapMessageId is set within your integration flow with an ID which remains the same for each message retry before calling the IDoc receiver adapter.
Let's take a look at the following simple example.
Here, we assume that the sender is able to restart messages and passes a unique ID to the integration flow. In the sample integration flow, we use SOAP with SAP RM protocol at the sender side which passes the header SapMessageIdEx to the integration flow. When restarting the message, we ensure that SapMessageIdEx remains the same.
Now, in a content modifier step we simply assign the value of SapMessageIdEx to the header SapMessageId. As said, the IDoc adapter now doesn't create a new ID, it uses at the end the value of the header SapMessageIdEx. This ensures proper duplicate handling at the IDoc receiver.
You find this scenario described at IDoc Receiver Handles Duplicates.
In total, we have added 6 new guidelines:
- EO for IDoc receiver in case sender can restart based on unique ID in header
- EO for IDoc receiver in case sender can restart based on unique ID in payload
- EO for IDoc receiver in case sender can not restart
- EO for XI receiver in case sender can restart based on unique ID in header
- EO for XI receiver in case sender can restart based on unique ID in payload
- EO for XI receiver in case sender can not restart
For an overview, check out Quality of Service Exactly Once.
Furthermore, we have added the Special Use Cases: SAP RM vs XI vs IDoc documentation where you can see at a glance which configuration steps are required to guarantee Exactly Once delivery for special use cases where the receiver protocol supports idempotency focusing on SAP RM, XI, and IDoc.
1 Comment
