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.
There are two prerequisites for employing services as idempotent services:
If these prerequisites are met, a consumer can safely re-send request messages.
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.