Show TOC

Transactions for the Asynchronous Receiver DirectionLocate this document in the navigation structure

The adapter is part of the LUW of the Adapter Framework messaging service. This causes the following problem: The external adapter protocol uses its own local transaction, which is separate from the Adapter Framework database transaction.

This problem can only be solved with a real two-phase commit global transaction, which is currently not available.

The MessageIDMapper is used instead. In addition to the ID mapping from the XI message protocol to the external protocol, a pending status is persisted for the XI message just processed, in a separate transaction.

The processing sequence must contain the following steps:

  1. Check whether the message ID is already saved in the MessageIDMapper.

    If so, the XI message is already successfully processed. The adapter returns without error. The Adapter Framework can flag the message as successfully sent.

  2. Check whether the XI message ID is saved with pending status in the
    MessageIDMapper
    .

    If so, write a detailed error message to the Adapter Framework audit log and throw an exception.

    In this case it is unclear whether the XI message has already been sent to the external system or not. The administrator must check whether the message has already arrived in the external system.

    Based on this check, it should be possible to reconfigure the communication channel so that the message is either processed or recognized as a duplicate and ignored the next time an attempt is made to send it.

    For an example of a possible adapter configuration, see Configuring the Receiver JMS Adapter , under Defining XI Settings; Handling Pending Messages.

  3. Send the message to the external system
  4. Commit the send process if the external system has a transactional concept.
  5. Use the MessageIDMapperto create a mapping between the external message ID and the XI message ID for the new message to be sent. The ID mapping is executed immediately in a separate LUW.

    The transactional parameter in the createIDMap() method must have the value false.

  6. Remove the IDMap with pending status in a separate LUW.

    The transactional parameter in the remove() method must have the value false.

  7. The Adapter Framework messaging service executes a commit of the LUW.