Interface-Pattern 

Sie weisen jedem Service-Interface ein Interface-Pattern zu, dass die Art der auszuführenden Kommunikation beschreibt. Bevor die Interface-Pattern zustandslos (XI 3.0 kompatibel), zustandslos, zustandsbehaftet und TU&C/C beschrieben werden, sollen die zwei Begriffe zustandslos und zustandsbehaftet geklärt werden:

·        Zustandslose Kommunikation bedeutet, dass von der Messaging-Laufzeit kein Speichern eines Zustandes beim Provider unterstützt wird, sobald die Messaging-Laufzeit den Message-Austausch erfolgreich abgeschlossen hat.

·        Zustandsbehaftete Kommunikation bedeutet, dass von der Messaging-Laufzeit ein Speichern eines Zustandes beim Provider unterstützt wird, sobald die Messaging-Laufzeit den den Message-Austausch erfolgreich abgeschlossen hat.

Dabei ist wichtig anzumerken, dass die Messaging-Laufzeit einen solchen Vorgang explizit unterstützen kann oder nicht. Unterstützt die Messaging-Laufzeit zustandsbehaftete Kommunikation, kann der Anwendungsprogrammierer entsprechende Methoden der Messaging-Laufzeit nutzen.

Zudem bezieht sich bei den Interface-Patterns eines Service-Interface diese Begriffe auf den Zustand beim Provider und nicht auf den Zustand auf dem Integration Server (im Falle einer erweiterten Kommunikation). Sie können also auch bei Auswahl eines zustandslosen Interface-Pattern die Kommunikation über den Integration Server um die Ausführung eines zustandsbehafteten Integrationsprozesses erweitern, der die Korrelation von Messages erlaubt. Weitere Informationen: Integrationsprozesse.

Zustandslose Kommunikation (XI 3.0 kompatibel)

Mit diesem Interface-Pattern können Sie alle bis SAP NetWeaver 2004s vorhandenen Protokolle am Backend, die auf Basis von Message-Interfaces entwickelt wurden, weiterhin nutzen. Message-Interfaces aus dem Integration Repository von SAP NetWeaver 2004s werden nach Service-Interfaces im Enterprise Services Repository migriert und bekommen dabei dieses Interface-Pattern zugewiesen. Das Interface-Pattern erlaubt nur eine Operation.

Die folgende Tabelle gibt einen Überblick über die Programmiermodelle, die Sie mit diesem Interface-Pattern implizit auswählen. Da die Entwicklung von Service-Interfaces ausgeht, gilt die Tabelle nur für den Outside-In-Ansatz.

Unterstützte Modi abhängig von Backend und Art der Kommunikation

Backend (SAP NetWeaver 2007)	Point-to-Point	Erweiterte Kommunikation über den Integration Server
AS-ABAP	Synchrone Kommunikation über die Web-Service-Laufzeit mit Hilfe des Programmiermodells von SAP NetWeaver 2004s. Es wird empfohlen, für Neuentwicklungen das Interface-Pattern zustandslos zu verwenden.	Synchrone und asynchrone Kommunikation über XI-Laufzeit und dem XI-Adapter mit Hilfe des Programmiermodells von SAP NetWeaver 2004s.
AS-Java	Wurde zu SAP NetWeaver 2004s nicht unterstützt. Nutzen Sie das Interface-Pattern zustandslos.	Synchrone und asynchrone Kommunikation über die Java-Proxy-Laufzeit (JPR) und dem XI-Adapter mit Hilfe des Programmiermodells von SAP NetWeaver 2004s.

Zu SAP NetWeaver 2004s wurden Point-to-Point-Szenarien ausschließlich mit Hilfe der Web-Service-Laufzeit realisiert und erweiterte Szenarien (Integration Server) über die XI-Laufzeit und den XI-Adapter. Ab SAP NetWeaver 2007 unterstützt der Integration Server den Message-Austausch mit der Web-Service-Laufzeit über den Web-Service-Adapter. Der nächste Abschnitt beschreibt die zugehörigen Interface-Patterns.

Weitere Interface-Pattern der Web-Service-Laufzeit

Bei Auswahl der folgenden Interface-Pattern entscheiden Sie sich für eine Kommunikation unter Verwendung der Web-Service-Laufzeit:

●      Zustandslos

Die Web-Service-Laufzeit unterstützt bei diesem Interface-Pattern sowohl eine Point-to-Point-Kommunikation über Web services als auch eine Kommunikation über den Integration Server mit Hilfe des Web-Service-Adapters.

●      Zustandsbehaftet

Hintereinander ausgeführte Aufrufe können auf einen Zustand beim Provider aufbauen. Dieses Interface-Pattern wird nur für einige spezielle technischen Szenarien benötigt. Eine gemeinsame Verbuchung von Daten beim Empfänger ist nicht gewährleistet.

Dieses Interface-Pattern können Sie nicht bei einer erweiterten Kommunikation über den Integration Server verwenden. Es wird nur synchrone zustandsbehaftete Kommunikation unterstützt.

●      TU&C/C

Interface-Pattern, das auf den vorhandenen Protokollen zur synchronen und asynchronen Kommunikation aufsetzt und systemübergreifende ROLLBACKs ermöglicht (siehe unten). Das Interface-Pattern unterstützt sowohl eine Point-to-Point-Kommunikation über Web services als auch eine Kommunikation über den Integration Server mit Hilfe des Web-Service-Adapters.

Das gewählte Interface-Pattern bestimmt, wie ein Anwendungsentwickler die Kommunikation am Backend programmiert. Wenn Sie das Interface-Pattern ändern, muss auch das Anwendungsprogramm am Backend geändert werden. Das gilt sowohl bei einem Wechsel von dem Interface-Pattern zustandslos (XI 3.0 kompatibel) zu zustandslos, als auch bei einem beliebigen anderen Wechsel.

Tentative Update & Confirm / Compensate (TU&C/C)

Für systemübergreifende Verbuchungen arbeiten Sie bevorzugt mit asynchroner Kommunikation, weil der Quality-of-Service Exactly-Once(-In-Order) (EOIO) die einmalige Ablieferung einer Message (bei EOIO in der richtigen Reihenfolge) garantiert, auch nach einem Systemabsturz.

Wenn die Fortführung einer Transaktion allerdings von den Ergebnissen eines Service-Aufrufs abhängt, können Sie nur mit einem synchronen Aufruf arbeiten. Aufrufe innerhalb einer Komponente sind in solchen Fällen unproblematisch, denn wenn der aufgerufene Service Änderungen im System verbucht, sind diese Verbuchungen Teil der aufrufenden Transaktion. Der Aufrufer bestimmt für die gesamte Transaktion, ob das System die Änderungen auf die Datenbank schreibt (COMMIT) oder nicht (ROLLBACK). Für systemübergreifende Service-Aufrufe gibt es keinen solchen Automatismus. Die Konsistenz der Daten kann statt dessen über das TU&C/C-Protokoll sichergestellt werden.

Das TU&C/C-Protokoll stellt sicher, dass trotz synchroner Aufrufe Daten beim Empfänger konsistent verbucht werden können. Der grundsätzliche Ablauf ist der folgende:

1. Der Consumer ruft über eine synchrone Tentative-Update-Operation einen Service beim Provider auf, um Daten zu aktualisieren. Wie der Name der Operation schon sagt, verbucht der Provider die Daten allerdings noch nicht. Statt dessen merkt sich der Provider die Änderungen. Ein Kennzeichen zeigt an, dass die Daten noch verbucht werden müssen.
2. Es sind weitere Aufrufe von synchronen Tentative-Update-Operationen möglich. Über die Übermittlung der zugehörigen Transaktions-ID, kann der Provider die gesammelten Änderungen einer Transaktion zuordnen.

Eine Anwendung, die das TU&C/C-Protokoll nutzt, muss die Transaktions-ID selbst übergeben. Anwendungsentwickler müssen daher für die Transaktions-ID ein Feld bei der Modellierung des Datentyps modellieren, der für den Message-Typ für die Kommunikation eingesetzt wird.

3. Abschließend ruft der Consumer eine asynchrone Compensate-Operation oder eine asynchrone Confirm-Operation auf:

○       Mit der Compensate-Operation erklärt der Consumer alle vorherigen Tentative-Update-Operationen einer Transaktion als ungültig. Der Provider verbucht sie nicht und kann die vorläufigen Einträge löschen.

○       Mit der Confirm-Operation erklärt der Consumer, dass alle vorherigen Tentative-Update-Operationen einer Transaktion verbucht werden sollen. Der Provider schreibt somit die Daten auf die Datenbank.

Dieser Mechanismus setzt auf der garantierten Verarbeitung von asynchronen Messages auf und funktioniert nur unter folgenden Voraussetzungen, die oft auch als Vertrag zwischen dem Consumer und dem Provider bezeichnet werden:

●      Das Consumer-System sendet entweder eine Confirm-Message oder eine Compensate-Message sobald die laufende Transaktion endet, und zwar nicht nur auf Grund eines expliziten COMMIT oder ROLLBACK, sondern auch wenn die Transaktion auf Grund eines Systemfehlers abgebrochen wurde.

●      Das Provider-System stellt sicher, dass die vorübergehenden Änderungen der Tentative-Update-Operationen auf die Datenbank geschrieben werden, sobald eine Confirm-Message empfangen wird und dass sie verworfen werden, sobald eine Compensate-Message empfangen wird, und zwar unabhängig von einem Ausfall des Provider-Systems oder ähnlichen Fehlern. Diese Garantie gilt auch für Änderungen, die der Provider zusätzlich zu den Änderungen der Tentative-Update-Messages vorläufig gesichert hatte.

Der Provider ignoriert die Compensate-Message, wenn noch keine Tentative-Update-Message empfangen worden ist.

Die Messaging-Laufzeit stellt sicher, dass die Compensate-Message in allen Fehler- und Abbruch-Situationen gesendet wird. Sie registriert zu diesem Zweck eine Compensate-Message vor dem ersten Aufruf einer Tentative-Update-Operation. Stürzt das System ab, kann das System diese Message bei einem Wiederaufsetzen finden und verschicken. Endet die Transaktion erfolgreich, ersetzt das System die Compensate-Message durch eine Confirm-Message, um den Provider zu informieren.

Auf Grund der notwendigen Abstimmung zwischen Consumer und Provider eignet sich das TU&C/C-Protokoll nur für Szenarien innerhalb einer Systemlandschaft und nicht für unternehmensübergreifende Szenarien wie etwa einer Kommunikation mit anonymen Benutzern über das Internet.