Transaktionen für die asynchrone Empfängerrichtung

Der Adapter ist Teil der LUW des Adapter-Framework Messaging-Service. Dadurch entsteht folgendes Problem: Das externe Adapterprotokoll verwendet seine eigene lokale Transaktion, die von der Adapter-Framework Datenbanktransaktion entkoppelt ist.

Dieses Problem kann nur mit einer echten two-phase Commit globalen Transaktion gelöst werden, die zurzeit nicht zur Verfügung steht.

Stattdessen wird der MessageIDMapper verwendet. Zusätzlich zum ID-Mapping von XI-Message-Protokoll zum externen Protokoll wird ein Pending-Status für die gerade bearbeitete XI-Message in einer eigenen Transaktion persistiert.

Die Verarbeitungsreihenfolge sollte folgende Schritte enthalten:

1. Überprüfung, ob die Message-ID bereits im MessageIDMapper gespeichert ist.

   Ist sie vorhanden, ist die XI-Message bereits erfolgreich bearbeitet. Der Adapter kehrt ohne Fehler zurück. Das Adapter-Framework kann die Message als erfolgreich versendet kennzeichnen.

2. Überprüfung, ob die XI-Message-ID im Pending-Status im MessageIDMapper gespeichert ist.

   Ist sie gespeichert, schreiben Sie eine ausführliche Error-Message in das Adapter-Framework Audit-Log und werfen Sie eine Exception.

   In diesem Fall ist unklar, ob die XI-Message bereits an das externe System geschickt wurde oder nicht. Der Administrator muss prüfen, ob die Message schon im externen System verbucht ist.

   Abhängig von dieser Prüfung sollte es möglich sein, den Kommunikationskanal entsprechend umzukonfigurieren, dass beim nächsten Sendeversuch der Message diese entweder verarbeitet wird oder aber als Duplikat ignoriert wird.

   Ein Beispiel für eine möglichen Adapterkonfiguration finden Sie unter: JMS-Empfänger-Adapter konfigurieren , dort unter XI-Einstellungen definieren, Behandlung hängenden Messages

3. Versand der Message an das externe System
4. Commit des Sendeprozesses, falls vom externen System ein transaktionales Konzept offen gelegt wird
5. Anlegen eines Mappings mit dem MessageIDMapper zwischen der externen Message-ID und der XI-Message-ID für die neue zu sendende Message. Das ID-Mapping wird in einer eigenen LUW sofort ausgeführt.

   Der Parameter transactional in der Methode createIDMap() muss die Ausprägung false haben.

6. Entfernen Sie die IDMap im Status Pending in einer eigenen LUW.

   Der Parameter transactional in der Methode remove() muss die Ausprägung false haben.

7. Der Adapter-Framework Messaging-Service führt ein Commit der LUW aus.