Show TOC

HintergrundImplementierung idempotenter Web-Services Dieses Dokument in der Navigationsstruktur finden

 

Alle synchronen Services, auf die folgende Kriterien zutreffen, sollten Sie als idempotent implementieren:

  • Der Service ändert die persistenten Geschäftsdaten in einem Anwendungssystem.

  • Die wiederholte erfolgreiche Ausführung ein und desselben Requests würde zu doppelten Geschäftsdaten führen oder Prozessinkonsistenzen mit sich bringen.

Weitere Informationen finden Sie unter Idempotente Web-Services.

Voraussetzungen

  • Service-Consumer, die sich mit idempotenten Web-Services verbinden, müssen das MessageHeader-Element und die Teilelement-UUID in den Request-Messages des Services verwenden.

    Die UUID-Werte müssen global erkennbar sein und dem Format entsprechen, das im RFC 4122 der IETF angegeben ist. Wenn Sie das Element beim Aufruf der Services nicht verwenden, verhalten sich die Services nicht idempotent. Sie können die UUID wie folgt generieren:

    • Beim Entwickeln von Consumern in Java verwenden Sie die Klasse java.util.UUID.

    • Beim Entwickeln von Consumern in ABAP verwenden Sie den Funktionsbaustein GUID_CREATE, gefolgt vom Methodenaufruf CL_GDT_CONVERSION=>GUID_OUTBOUND. Beachten Sie, das die intern in ABAP-Systemen verwendeten GUIDs nicht dem UUID-Format entsprechen.

    Weitere Informationen dazu finden Sie unter http://www.ietf.org/rfc/rfc4122.txt.

  • Vor dem Aufruf der idempotenten Services muss das zugrunde liegende Framework konfiguriert werden. Dazu gehört auch die Zeitdauer, die festlegt, wie lange das System Responses für bereits verarbeitete Service-Aufrufe behält.

    Weitere Informationen finden Sie im SAP-Hinweis 1097348.

Vorgehensweise

Service-Interfaces designen

  • Stellen Sie sicher, das der Datentyp für Eingangs- und Ausgangs-Messages der Service-Operation ein mit dem GDT BasicBusinessDocumentMessageHeader typisiertes MessageHeader-Element - bzw. eine seiner vordefinierten Projektionen mit dem UUID-Element - als erstes untergeordnetes Element des Wurzelelements enthält.

  • Das Element MessageHeader kann als optional (Häufigkeit 0..1) deklariert werden.

  • Wenn der Namensraum Ihrer Service-Operation eine Version des vollwertigen BusinessDocumentMessageHeader (oder eine Projektion davon) mit dem UUID-Element enthält und Sie synchrone und asynchrone Services mit derselben Signatur anbieten möchten, können Sie ebenfalls diesen GDT benutzen.

Idempotente Services implementieren

  1. Extrahieren Sie die UUID der Business Document Message aus dem Header der Business Document Message. Service-Consumer müssen idempotentes Verhalten explizit „anfordern“, indem sie einen nicht-leeren Wert für die Message-UUID angeben.

  2. Legen Sie eine Instanz der NW-Helper-Klasse für „idempotente Web-Services“ mit Hilfe der zugehörigen Factory-Klasse an. Dies kann fehlschlagen, wenn das Idempotenz-Framework noch nicht konfiguriert wurde. In diesem Fall löst das System die Ausnahme cx_soap_idp_fault aus.

  3. Rufen Sie die Methode der Helper-Klasse auf, um zu prüfen, ob der eingehende Request bereits verarbeitet wurde.

    Die Helper-Klasser erzeugt bereits zu diesem Zeitpunkt ein Enqueue für die UUID der Request-Message. Dadurch wird sichergestellt, dass nicht zwei Consumer die gleiche Request-Message-UUID verwenden und dass zwei rasch aufeinander folgende Aufrufe durch denselben Consumer entdeckt werden. Die Enqueue-Erstellung kann aus den folgenden zwei Gründen fehlschlagen:

    • Systemfehler, z.B. weil der Enqueue-Server nicht erreicht werden kann.

      Hierbei handelt es sich um eine unerwartete außergewöhnliche Situation, die als Ausnahme behandelt werden sollte.

    • Derselbe Request wurde bereits empfangen, aber bisher noch nicht vollständig verarbeitet.

      Daher steht eine gespeicherte Response zur Verfügung. Dieser Fall sollte nicht zu einer Ausnahme führen, aber es sollte ein zweiter Versuch zum Aufruf der Methode der Helper-Klasse erfolgen. Nur wenn dieser zweite Versuch ebenfalls scheitert, sollte eine Ausnahme ausgelöst werden.

  4. Lautet das Ergebnis „Ja“, rufen Sie die gespeicherte Response ab und geben Sie sie direkt an den Consumer zurück. Verarbeiten Sie den Request nicht weiter und überspringen Sie die nächsten Schritte bis zum letzten Schritt.

    Da die Response in der Zwischenzeit bereits gelöscht worden sein könnte, kann der Abruf fehlschlagen. Verarbeiten Sie in diesem Fall den Request nicht, indem Sie versuchen, eine neue Response zu generieren, sondern lösen Sie eine Ausnahme aus.

  5. Verarbeiten Sie den Request entsprechend der üblichen Implementierungsrichtlinien, d.h. SET UPDATE TASK LOCAL, Aufruf des Inbound-Mapping, BAdI für Vorverarbeitung, BAPI, BAdI für Nachverarbeitung, Outbound-Mapping.

    Stellen Sie sicher, dass CL_SOAP_COMMIT_ROLLBACK=>COMMIT() noch nicht aufgerufen wird.

  6. Wenn beide der folgenden Bedingungen erfüllt sind, speichern Sie die Response-„Message“ (mit der ABAP-Proxy-Struktur), indem Sie die Methode der NW-Helper-Klasse verwenden.

    • Es sind keine Anwendungsfehler aufgetreten (als Meldungen im Element Log der Ausgangs-Message erfasst).

    • Idempotenz wird vom Consumer angefordert.

  7. Wenn immer noch keine Fehler auftreten, rufen Sie die Methode CL_SOAP_COMMIT_ROLLBACK=>COMMIT() auf. Ansonsten rufen Sie die Methode CL_SOAP_COMMIT_ROLLBACK=>ROLLBACK() auf.

  8. Kümmern Sie sich um die Ausnahmenbehandlung.

  9. Beenden Sie die Methode.