What is  Idempotent in Integration

A Reliable message transfer is a need in any Business scenario. There must be a guarantee that any message sent to the receiver, to modify any object state, should be processed exactly once (EO). To avoid inconsistencies in the sender or recipient system, the operations are implemented as idempotent.

Idempotency helps ensure data consistency and integrity, where messages or operations might be retried, causing duplicate messages, due to network glitches, system failures, or any other issues. It helps to maintain data consistency and integrity in complex integration scenarios.

Here’s how idempotency may be implemented in the context of SAP Cloud Integration (CI):

Unique Request ID or Message Deduplication: This ensures that messages are unique. SAP Cloud Integration provides a mechanism for deduplicating incoming messages. This means that if a message with the same unique identifier is received more than once, only the first occurrence will be processed, and subsequent occurrences will be ignored.

Atomicity: Integration flows should be designed in such a way that the process is atomic. That means that either the message gets processed successfully and leaves no side effect in case of failure or is executed multiple times.

Transaction: In some of the scenarios, the iFlows might be designed using transactional processing to ensure idempotency. That is, if a transaction fails, it can be rolled back. And the same transaction can be retried without causing duplicate data or unintended changes.

Idempotent APIs: The idempotency feature of APIs can be leveraged by SAP Cloud Integration to integrate with external systems. Idempotent APIs are designed in such a way that the when same API request is made multiple times, it has the same effect as making it once. This can be important for ensuring data consistency.

Idempotency Cases in Integration

The Idempotent Process Call is useful for designing exactly-once or at-most-once in the integration flow. For example, if a receiver system (e.g. third-party system) is unable to handle the duplicate messages properly, in that case, you can call the receiver system from within an Idempotent Process Call.

A receiver with idempotent capabilities can safely fetch and process the identical message multiple times, ensuring that the same changes are not executed redundantly.

There are the following use cases when the sender supports message retry:

Idempotency Cases

#1 Implementing Idempotent Process Call in SAP Cloud Integration

• The Idempotent Process Call detects if a message ID has already been successfully processed and stores the status of the successful process in the Idempotent repository.
• If there is duplicate execution with the same message ID (for example if there’s a retry by the sender system), the called subprocess can either be skipped or the message is marked as a duplicate. You can then decide how to handle the duplicate in the subprocess.

Example :

Process Purchase Orders from the sender system wherein OrderNo is used as a unique identifier.

In case we attempt to process the same message with the same Order Number on a subsequent, the message will not undergo processing.

• Set_Header : The property OrderNo is set using XPath expression
• Idempotent Process Call: OrderNo, using a unique key, will be stored in the Idempotent repository for duplicate checks.
• Router : DuplicateCheck:   OrderNo (Unique identifier) is compared with the value in the idempotent repository

Case#1 (Branch False): New Entry

Checks the OrderNo from the input payload in the idempotent repository; If does not exist then the Order will get processed and sent to the target system

Case#2 (Branch True): Duplicate Entry

Checks the OrderNo from the input payload in the idempotent repository. In case an OrderNo already exists, an alert with OrderNo is sent and ensures that the order not be processed further

Reference: https://help.sap.com/docs/cloud-integration/sap-cloud-integration/idempotent-process-call-handles-duplicates

#2 Handling Duplicate using Idempotent Process Call with Alternative Response

In this scenario, Cloud Integration initiates the creation of a purchase order synchronously and waits for the confirmation response from the receiver system when the purchase order has been successfully delivered. If the identical request is made subsequently, the purchase order should not be sent to the receiver system. Instead of this, an alternative response is to be generated and sent.

• The Get order content modifier step stores the purchase order number from the sender payload
• The Idempotent Process Callstep sends the message to the local integration process using idempotent conditions “Skip Process Call for Duplicates” -> Deselected
• The duplicate Order verification is based on the unique order number. Since the response is changed, the idempotent process call isn’t skipped in case of duplicates are encountered.

Case#1: New Entry

“No” branch : The message is sent to the receiver using the Request Reply step.  In the Default message body content modifier step, Cloud Integration defines the body of the response.

Case#2: Duplicate Entry

“Yes” branch:  The body in case of duplicate content modifier defines the body of the response for duplicate message.

Reference: https://help.sap.com/docs/cloud-integration/sap-cloud-integration/idempotent-process-call-handles-duplicates-with-alternative-response

Idempotent API

Idempotent API can be used to check and delete the idempotent repository. The API can be found on api.sap.com

https://api.sap.com/api/MessageProcessingLogs/resource/Idempotent_Repository