Idempotente Web-Services 
Wenn Systeme asynchron miteinander kommunizieren, kann die SAP-Message-Exchange-Infrastruktur Reliable Messaging sicherstellen, einschließlich garantierte Zustellung und Exactly-Once-Ausführung jeder Message. Dies gilt unabhängig davon, ob der Message-Austausch über SAP Process Integration als Broker mit dem Protokoll XI 3.0 erfolgt oder über den WS-RM-Standard realisiert wird.
Bei der synchronen Kommunikation, bei der Services direkt über ein einfaches Web-Services-Protokoll aufgerufen werden, gibt es keine Garantie, dass jede vom Consumer gesendete Request-Message auch tatsächlich genau ein Mal beim Provider ankommt. Folgende Probleme können auftreten:
Nicht zugestellter Request.
Eine Message kann bei Netzwerkproblemen verloren gehen oder mehrmals ankommen.
Nicht zugestellte Response.
Selbst wenn die Request-Message beim Provider ankommt, kann die Response-Message beim Netzwerktransport verloren gehen. Ein Consumer, der nach angemessener Zeit keine Response erhält, geht davon aus, dass der Request nicht angekommen ist und schickt ihn erneut.
Bei vielen Services ist es äußerst wichtig, dass sie genau ein Mal erfolgreich ausgeführt werden, wenn sie angefordert wurden. Wenn beispielsweise eine neue Bestellung über einen Service-Aufruf angelegt werden soll, ist es nicht tolerierbar, dass gar keine Bestellung angelegt wird oder dass wegen der wiederholten Verarbeitung eines einzelnen Requests zwei oder mehr Duplikate entstehen. In der Regel sollten alle Services, die den persistenten Zustand einer Anwendung ändern, die Exactly-Once-Ausführung unterstützen. Alle Request-Confirmation-Services zählen zu dieser Kategorie. Für diese Services ist ein Mechanismus erforderlich, der gewährleistet, dass ein Service erfolgreich genau ein Mal ausgeführt wird, wenn er von einem Consumer angefordert wird.
SAP NetWeaver bietet ein Framework an, mit dem die Exactly-Once-Ausführung für Services garantiert werden kann. Web-Services, die dieses Framework nutzen, werden als „idempotent“ bezeichnet. Das Framework leistet Folgendes:
Es speichert eine Message, die als Response für einen eingehenden Service-Aufruf erstellt wurde, bevor die Response tatsächlich an den Consumer geschickt wird.
Die Service-Response wird anhand der Request-Message-ID identifiziert. Bei jedem eingehenden Request kann der Provider feststellen, ob dieser Request bereits verarbeitet wurde, indem er prüft, ob eine Response für die Request-ID hinterlegt wurde. Wenn dies der Fall ist, kann das Framework die zuvor erstellte Response direkt zurückgeben, ohne den Request erneut zu verarbeiten.
Wenn ein idempotenter Service eine Request-Message mehrfach innerhalb eines bestimmten Zeitrahmens erhält, so verarbeitet er die Message nur ein Mal und gibt die ursprüngliche Response zurück. Das Framework stellt sicher, dass der Response-Speicher gesperrt wird. Es löscht außerdem die gespeicherten Responses nach einem bestimmten Zeitraum, um die unnötige Anhäufung von Daten in der Datenbank zu verhindern.
Wenn die Ausführung eines Request-Confirmation-Services fehlschlägt, kann der Service erneut ausgeführt werden. Der erste Ausführungsversuch war eventuell wegen eines temporären Problems nicht erfolgreich (z.B. wegen eines Sperrkonflikts), und eine erneute Ausführung kann erfolgreich sein.
Hinweis
Ziel des Exactly-Once-Ansatzes ist es, falsche Geschäftsprozesse und -daten zu vermeiden und nicht, die Performance zu verbessern. Query-Response-Services, die nur zum Lesen oder Auffinden von Daten dienen, sollten daher die Exactly-Once-Ausführung nicht unterstützen.
Hinweise für Service-Consumer
Es wird angenommen, dass das von der Web-Service-Consumer-Anwendung verwendete Framework eine bestimmte Zeit lang auf eine Response wartet und nach Ablauf dieser Zeit die Consumer-Anwendung informiert. Unabhängig davon, ob dies mit einer Ausnahme oder einem anderen Mechanismus implementiert ist, erhält die Consumer-Anwendung wieder die Kontrolle. Auf diese Weise kann die Consumer-Anwendung entscheiden, einen erneuten Sendeversuch für genau dieselbe Request-Message zu starten und somit die „Wartezeit“ zu verlängern.
Wichtig ist, dass diese Entscheidung für einen erneuten Sendeversuch in die Logik der Consumer-Anwendung mit entsprechendem Quelltext und Modell eingebaut ist. Wird ein wiederholter Sendeversuch bereits vom zugrunde liegenden Framework unterstützt, muss die Entscheidung durch entsprechende Parametrisierung des Aufrufs an das Framwork implementiert werden, wenn der (erste) Service-Aufruf ausgegeben wird.
Die Entscheidung darf nicht dem Anwender überlassen werden. Es kommt zu Problemen, wenn der Benutzer zu lange wartet oder keinen Wiederholungsversuch startet und gleichzeitig der erste Request vom Service-Provider ausgeführt wurde und nur die Response verloren ging. Es ist nicht der richtige Ansatz, einfach nur zum Benutzungsoberflächenschritt (bzw. Prozessschritt) zurückzukehren, der den ursprünglichen Request gesendet hat, und es damit dem Anwender zu ermöglichen, die Kommunikation erneut manuell anzustoßen. Solch ein erneutes Anstoßen muss zu einem neuen Request mit neuer Request-Message-UUID führen.
Beachten Sie, dass ein erneutes Senden von Messages auch durch Netzwerkfehler oder Fehler der Infrastrukturkomponenten verursacht werden kann.