Idempotency

In business scenarios, reliable message transfer is required. It must be guaranteed that a message sent to the receiver to modify an object state is processed exactly once (EO). To avoid inconsistencies in the sender or recipient system, the relevant operations are implemented as idempotent.

Asynchronous Operations

The XI 3.0 or WS-RM protocol guarantees reliability. No specific guideline is needed for the implementation of these operations.

Synchronous Operations

There is no mechanism to guarantee that a request is processed exactly once by the recipient. If an idempotent service operation receives exactly the same request message multiple times within a limited timeframe, it will process it only once and return the corresponding response.

Example Example

A purchase order is to be created. If a message arrives several times, the concept prevents one or more duplicates from being created.

End of the example.

Note Note

You can define this timeframe using transaction WSIDPADMIN.

For more information, see SAP Note 1097348.

End of the note.

To be able to deal with messages that were sent multiple times, the recipient’s application must incorporate the appropriate code and model.

To safely resend request messages, the following prerequisite must be met:

Service consumers must use the MessageHeader element and its subelement UUID in the operation’s request messages. The UUID values must be globally recognizable and satisfy the format that is specified in Internet Engineering Task Force (IETF) RFC 4122. The system classifies service calls with the same message header UUIDs as identical.

The procedure for the development of consumer services depends on the developing platform used:

Java: You can use the class java.util.UUID to generate UUIDs.
ABAP: You can use the corresponding methods of the class CL_SYSTEM_UUID, followed by the method GUID_OUTBOUND of the class CL_GDT_CONVERSION.