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:
If so, the XI message is already successfully processed. The adapter returns without error. The Adapter Framework can flag the message as successfully sent.
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.
The transactional parameter in the createIDMap() method must have the value false.
The transactional parameter in the remove() method must have the value false.