Transaktionen im asynchronen Empfänger-/Outbound-Message-Fluss 

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 wir der MessageIDMapper verwendet. Die Verarbeitungsreihenfolge sollte folgende Schritte enthalten:

...

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

       2.      Versand der Message an das externe System

       3.      Commit des Sendeprozesses, falls vom externen System ein transaktionales Konzept offen gelegt wird

       4.      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 als eine verschachtelte LUW sofort ausgeführt.

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

Obwohl diese Vorgehensweise eine fast sichere Exactly Once-Auslieferung garantiert, gibt es eine kleine Lücke, die doppelte Einträge, jedoch keine Datenverluste erzeugen kann. Falls der Server zwischen dem Commit des Sendeprozesses und der Anlage des Mappings heruntergefahren wird, dann wird die XI-Message zweimal verschickt. Der Adapter sollte daher Mechanismen vorsehen, die solche Situationen erkennen können oder die Anwendung in die Lage versetzen, später doppelte Einträge zu erkennen.

Der JMS-Adapter setzt die JMS CorrelationId auf die XI-Message-ID, so dass der JMS-Client doppelte Einträge erkennen kann.

Beispiel

Die einzelnen Schritte sind im Beispiel enthalten:

…

   public void sendMessage(Message message, IGUID xmbmsgid) throws Exception {

...

   String qos = (String) parameter.get(WorkerImpl.ATT_XIQualityOfService.name);

 

   // Step 1: First check whether this message was already received in case of EO(IO)

   if ( (qos.equalsIgnoreCase("ExactlyOnceInOrder")) ||

        (qos.equalsIgnoreCase("ExactlyOnce")) ) {

      if (messageIDMapper.getMappedId(xmbmsgid.toHexString()) != null) {

         //Just ignore the message, commit it if necessary and return

         return;

      }

   }

   // set correlation ID for duplicate detection

   message.setJMSCorrelationID(xmbmsgid.toString());

 

   // Step 2: Send JMS message. The JMS correlation ID can be used by the receiving

   // JMS application to detect the very rare XI duplicates (see below)

   try {

      externalSender.send(message);

   }

   catch (Exception e) {  // An exception causes the XI AF MS to rollback this message

      ...

      throw e;

   }

   // Step 3: Commit external protocol

   externalSession.commit();

      

 

   // Step 4: Save message ID mapping for duplicate recognition

   //Important: Use hex string XI message ID representation for PMI logging (inside mapper)

   messageIDMapper.createIDMap(xmbmsgid.toHexString(), jmsmsgid, System.currentTimeMillis() + 1000*3600*24);

 

   ...

 

   // Step 5: Return without exception = commit in XI AF MS

   TRACE.exiting(SIGNATURE);  

}

…