Commit-Handling

Kommt die Integration Engine zum Einsatz, werden Transaktionen wie folgt verarbeitet:

1. Die Anwendung schreibt Anwendungsdaten temporär in ihre Datenbanktabellen.
2. In der gleichen Transaktion wird die Integration Engine aufgerufen, um den Kommunikationspartnern durch eine Message die Änderungen mitzuteilen.

   Die Message wird temporär in die Datenbank der Integration Engine geschrieben. Aufgerufen wird die Integration Engine mit Quality-of-Service Exactly Once (entspricht dem tRFC ) oder Exactly Once In Order (entspricht dem qRFC ).

3. Die Anwendung beendet die Transaktion mit einem expliziten COMMIT WORK (oder ROLLBACK WORK im Fehlerfall).

   Dies bewirkt, dass alle temporären Daten (Applikationsdaten, aufgezeichnete Messages der Integration Engine) in der Datenbank festgeschrieben werden. Außerdem werden die Message-Daten für die Versendung und Bearbeitung durch die Integration Engine (asynchron entkoppelt) freigegeben. (Im Rollback-Fall werden alle temporären Datenbankeinträge verworfen).

Datenbank-Commit bei synchronem Aufruf

Synchrone Aufrufe der Integration Engine sind gekennzeichnet durch Quality-of-Service Best Effort.

Die Integration Engine verhält sich genauso wie die RFC-Kommunikation in einem SAP-System:

Wird während einer Transaktion ein synchroner RFC ausgeführt, führt das System Datenbank-Commits (DB_COMMIT) durch. Ein DB_COMMIT bewirkt, dass alle Daten, die bisher temporär in die Datenbank geschrieben wurden, endgültig gesichert werden (wie bei COMMIT WORK) und bei einem späteren ROLLBACK WORK nicht mehr zurückgesetzt werden können.

Transport von Transaktionsklammern beim asynchronen Aufruf

Asynchrone Aufrufe der Integration Engine sind gekennzeichnet durch Quality-of-Service Exactly Once (entspricht einem tRFC) oder Exactly Once In Order (entspricht einem qRFC).

Die Integration Engine verhält sich hier weitgehend wie die RFC-Kommunikation in einem SAP-System.

Wie beim tRFC bzw. qRFC werden temporäre Anwendungsdaten und Aufrufe der Integration Engine erst mit einem COMMIT WORK gemeinsam in der Datenbank festgeschrieben.

Im Gegensatz zum tRFC bzw. qRFC werden jedoch verschiedene Aufrufe der Integration Engine innerhalb einer Transaktion auch in verschiedenen Messages verschickt. Jeder Aufruf der Integration Engine erzeugt also eine eigene, unabhängige Message.

Die transaktionale Klammer über die einzelnen Aufrufe wird also nicht zum Ziel des Aufrufs transportiert. Im Gegensatz dazu werden bei tRFC und qRFC − wenn das Zielsystem der Aufrufe identisch ist − die Aufrufe, die innerhalb einer Transaktion erfolgt sind, auch in einer Transaktion beim Empfänger abgearbeitet.

1. Die Anwendung schreibt Anwendungsdaten in ihre Datenbanktabellen.
2. Aufruf 1 der Integration Engine

   (Exactly Once / Exactly Once In Order)

   Message M1 wird erzeugt

3. Aufruf 2 der Integration Engine

   (Exactly Once / Exactly Once In Order)

   Message M2 wird erzeugt

4. Die Anwendung beendet die Transaktion mit einem expliziten COMMIT WORK.

Das COMMIT WORK schreibt die Anwendungsdaten aus Schritt a und die Messages M1 und M2 in die lokale Datenbank. Zum Zeitpunkt der Ausführung bzw. des Versendens (asynchroner Aufruf) werden M1 und M2 jedoch immer unabhängig voneinander verschickt und im Zielsystem auch unabhängig voneinander verarbeitet (mit jeweils einem eigenen COMMIT WORK).

• Quality-of-Service Exactly Once

  M1 und M2 werden unabhängig voneinander und voll parallelisierbar von der sendenden Integration Engine verschickt. Im Zielsystem wird M1 mit einem COMMIT WORK verarbeitet. Unabhängig davon wird M2 mit einem eigenen COMMIT WORK verarbeitet. Die Verarbeitungsreihenfolge von M1 und M2 beim Empfänger kann nicht vorherbestimmt werden.

• Quality-of-Service Exactly Once In Order

  M1 wird von der sendenden Integration Engine verschickt. Erst nach erfolgreichem Persistieren der Message M1 (z.B. in der empfangenden Integration Engine) wird M2 vom Sender verschickt. Diese Reihenfolge wird einschließlich der Anwendungsaufrufe beibehalten.

  Die Message M1 wird im Zielsystem an die Anwendung übergeben und mit einem COMMIT WORK abgeschlossen.

  Tritt bei M1 in der Anwendung ein Fehler auf, wird die Abarbeitung weiterer Messages (M2 und alle nachfolgenden Messages in der betreffenden Queue) blockiert. Nach erfolgreicher Festschreibung von M1, wird M2 an die Anwendung übergeben und mit einem eigenen COMMIT WORK festgeschrieben.

Transaktionen und synchrone Kommunikation über die Integration Engine

Synchroner Aufruf der Integration Engine innerhalb einer Transaktion

Aus den oben dargestellten Prinzipien ist das Verhalten von synchronen Aufrufen der Integration Engine (Quality-of-Service Best Effort) innerhalb von Transaktionen klar definiert. Das Verhalten der Integration Engine entspricht genau dem bekannten Verhalten bei Verwendung synchroner RFCs innerhalb von Transaktionen. Das heißt, unter Umständen werden Inkonsistenzen erzeugt.

1. Die Anwendung schreibt Anwendungsdaten in ihre Datenbanktabellen.
2. Die Integration Engine wird mit Best Effortaufgerufen.

   Die Message M1 wird erzeugt und synchron versandt, das heißt, es wird auf Antwort gewartet.

3. Die Anwendung beendet die Transaktion mit einem expliziten COMMIT WORK (oder ROLLBACK WORK im Fehlerfall).

Durch den impliziten DB_COMMIT (wie unter Datenbank-Commit bei synchronem Aufruf beschrieben) werden bereits nach Schritt b die Anwendungsdaten aus Schritt a fest in die Datenbank hineingeschrieben.

Im Falle eines Scheiterns des synchronen Aufrufs über die Integration Engine (also bei einem Return mit Anwendungs- oder Systemfehler), können die Anwendungsdaten aus Schritt a nicht mehr mit ROLLBACK WORK zurückgerollt werden. Folglich werden Inkonsistenzen erzeugt.

Synchroner Aufruf der Integration Engine mit Aktionen beim Empfänger

Wenn innerhalb eines synchronen Aufrufs der Integration Engine beim Empfänger schreibende oder ändernde Aktionen ausgeführt werden, können Inkonsistenzen entstehen.

Synchrone Aufrufe (sowohl RFCs als auch Aufrufe der Integration Engine) geben keine Garantie über die Einmaligkeit des Schreib- oder Änderungsprozesses (Datenbank-Inserts oder -Updates). Sollte der synchrone Aufruf keine Antwort erhalten (etwa wegen eines Kommunikationsfehlers), weiß der Aufrufer nicht, ob die Aktion beim Empfänger erfolgreich abgeschlossen wurde oder nicht.

Ein nochmaliger Aufruf wird (im Erfolgsfall) die Änderung auf der Datenbank in jedem Fall noch einmal durchführen. Damit ergeben sich aber unter Umständen DUPREC-Fehler (Duplicate Record) - also Versuche, einen Datenbanksatz mit identischem Schlüssel ein zweites Mal zu schreiben - und damit Systemabbrüche (RABAX), oder Inkonsistenzen und Datenschiefstände.