Asynchrone Messages 

Verwendung

Das Adapter-Framework stellt ein transaktionales Konzept zur Verfügung, das eine sichere Lösung für Quality-of-Service Exactly Once für den Message-Fluss aus Senderrichtung und eine nahezu sichere Lösung für den Message-Fluss in Empfängerrichtung liefert. Das Konzept verwendet dazu verteilte Transaktionen (XAResources).

Eine asynchrone Message besitzt immer Quality-of-Service Exactly Once oder Exactly Once In Order. Nähere Informationen hierzu finden Sie unter: Bestandteile der XI-Message

Voraussetzungen

Für asynchrone Messages darf ein Adapter:

·        In Empfänger-/Outbound-Richtung keine Response-Message verschicken

·        In Sender-/Inbound-Richtung keine Response-Message erwarten.

Folgende Voraussetzung besteht für die Empfänger-/Outbound Richtung:

·        Der Adapter muss bekannt geben, welche Arten von Acknowledgment-Messages er nicht unterstützt.

·        Der Adapter muss veranlassen, dass die unterstützten Acknowledgment-Messages asynchron oder synchron zum Integration Server zurückgeschickt werden. 

Momentan werden für die Sender-/Inbound-Richtung Acknowledgment-Messages nicht unterstützt. Prüfen Sie SAP-Hinweis 766332 bezüglich späterer Änderungen.

Um eine Exactly Once-Auslieferung zu implementieren, sollte der Adapter folgende Services verwenden:

MessageIDMapper

Mit diesem Service können sie eine externe Message-ID auf eine XI-Message-ID mappen. Das Mapping wird in der Datenbank gespeichert und kann in derselben LUW (Logical Unit of Work) wie der Adapter-Framework Messaging-Service ausgeführt werden. Siehe auch: Message-ID Erzeugung, Persistenz und Mapping

Das Adapter-Framework erwartet zwingend, dass der Adapter eine externe Message-ID zur Verfügung stellt. Entweder kann die Message-ID des externen Protokolls verwendet werden, oder es werden Message-IDs durch Algorithmen (z.B. Hash) erzeugt.

Ein Beispiel für eine ID eines externen Protokolls ist die JMS-Message-ID

Sie wird aus folgenden Elementen erzeugt: Dateiname, Dateiverzeichnis und Änderungszeit.

TransactionManager

Der SAP J2EE Server stellt die Funktionen des Paketes javax.transaction zur Verfügung. Der TransactionManager wird dazu verwendet, um LUWs zu kontrollieren.

Weitere Informationen hierzu finden Sie im Internet unter: java.sun.com/j2ee/transactions.

Funktionsumfang

Die Message-Verarbeitung sieht in Sender- und Empfängerrichtung unterschiedliche Schritte vor:

·        Transaktionen im asynchronen Sender-/Inbound-Message-Fluss

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

Erzeugung von Acknowledgment-Messages in Sender-/Outbound-Richtung

Ihr Adapter muss die Klasse Connection verwenden, wenn für asynchrone Messages das Zurücksenden von Acknowledgment-Messages veranlasst werden soll. Die Klasse stellt Methoden für die Erzeugung von Acknowledgment-Messages zur Verfügung

Methoden der Klasse Connection

Name	Verwendung
ackNotSupported	Der Adapter muss hier pro Message angeben, welche Acknowledgment-Typen er nicht unterstützt. Im Beispieladapter sind dies die Application-Acknowledgment-Typen. Diese Methode sollte erst am Ende der Message-Bearbeitung aufgerufen werden, nachdem sichergestellt ist, dass keine Exceptions mehr auftreten können, da dann automatisch Error-Delivery-Acknowledgments vom Adapter-Framework gesendet werden. Öffnen Sie hierzu CCIInteraction.java und suchen Sie nach der Zeichenkette CS_ACKNS.
deliveryAck	Das Delivery-Acknowledgment zeigt an, ob eine Message erfolgreich an den letzten Knoten (den Endpunkt) in der Kommunikationskette an die dortige Message-Schicht ausgeliefert wurde. Im Beispieladapter wird angenommen, dass dies der Fall ist, sobald die Datei mit der Message erfolgreich im Dateisystem geschrieben worden ist. Öffnen Sie hierzu CCIInteraction.java und suchen Sie nach der Zeichenkette CS_ACKDEL.
deliveryErrorAck	Wenn eine Message nicht an den Endpunkt ausgeliefert werden kann und der Adapter kann diesen Zustand mit Hilfe des angebunden externen Protokolls erkennen, dann kann er asynchron ein Error-Delivery-Acknowledgment zurücksenden. Wird noch innerhalb der Message-Bearbeitung eine Java-Exception ausgelöst, so sendet das Adapter-Framework automatisch (sofern dies von XI angefordert wurde) ein Error-Delivery-Acknowledgment mit einem aus der Exception gewonnenen Fehlertext zurück. Der Adapter darf in diesem Fall nicht explizit deliveryErrorAck() aufrufen. Daher ist im Beispieladapter kein explizites Setzen des Error-Ddelivery- Acknowledgments enthalten.
applicationAck	Das Application-Acknowledgment zeigt an, ob eine Message erfolgreich von der Anwendung im Endpunkt bearbeitet wird. Da der Beispieladapter dies nicht erkennen kann, unterstützt er diesen Typ nicht und deklariert dies mit der Methode ackNotSupported.
applicationErrorAck	Analog zu Application-Acknowledgment, jedoch für den Fehlerfall

Um ein Objekt der Klasse Connection zu instanziieren, gehen Sie analog zur MessageFactory vor. Dies wird im Beispieladapter in der XIMessageFactoryImpl-Klasse gezeigt.

Öffnen Sie hierzu XIMessageFactoryImpl.java und suchen Sie nach der Zeichenkette CS_MSGFCT.

Die Connection-Klasse bietet neben den Acknowledgment-Methoden noch weitere Methoden an. Diese dürfen jedoch von einer Adapter-Framework-konformen Adapterimplementierung nicht genutzt werden.