Idempotency

Background information

Features

This function is available with SAP NetWeaver 2004s SP09 and ECC-SE 600 SP03.

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). For example, if a new purchase order is to be created via a service invocation it is not acceptable to either have no purchase order created, or to have one or more duplicates created. In the case of asynchronous services, the XI 3.0 protocol guarantees reliability. However, in synchronous communication there is no intrinsic mechanism to guarantee that a sent message arrives at the recipient, or that a request is processed exactly once by the recipient. A message may be lost, or may arrive several times, due to network problems. Even if a request reaches the provider, the response may be lost during network transport, in which case the consumer might assume that its request did not arrive and would resend it.

To avoid inconsistencies in the provider or consumer system, the relevant SAP Enterprise Services are implemented as idempotent. If an idempotent service receives exactly the same request message multiple times within a limited time frame, it will process it only once and return the original response. The restriction to a limited time frame is necessary to avoid overloading the database, as the system must store the original response message within the specified time frame.

Prerequisites

There are two prerequisites for employing services as idempotent services:

1. Service consumers must use the MessageHeader element and its sub-element UUID in the services’ request messages.
   The UUID values must be globally recognizable and satisfy the format that is specified in IETF RFC 4122 ( http://www.ietf.org/rfc/rfc4122.txt ). If you do not use the element when you call the services, the services do not behave in an idempotent manner. When developing consumers using Java, UUIDs can easily be generated using the class java.util.UUID. When developing consumers in ABAP, use function module GUID_CREATE followed by the method call CL_GDT_CONVERSION=>GUID_OUTBOUND. Note: The GUIDs used internally in ABAP systems do not satisfy the UUID format.
   
2. Before calling the idempotent services, the underlying framework has to be configured, including the time frame for which the system keeps responses for already processed service calls.
   See Cross-Application Components -> Processes and Tools for Enterprise Applications -> Enterprise Services -> General Settings for Enterprise Services -> Define Settings for Idempotent Services in the SAP Reference IMG.

If these prerequisites are met, a consumer can safely re-send request messages.

Note

It is important that this resend decision is incorporated in the consumer application's logic, using the appropriate consumer application code and model (or, if resend is already supported by the underlying framework, by using appropriate parameterization of the call to the framework when issuing the first service call). The decision should not be left to the consumer application’s end user. Consider the result if the end user waits for too long or decides not to retry, but the first request was executed by the service provider and only the response was lost: returning to the UI (or process) step that triggered the sending of the original request, thereby allowing an end user to manually re-trigger the communication, is not an appropriate approach. Such a re-triggering must lead to a new request, with a new request message UUID.