Globally coordinate message flow transactions with a transaction manager to ensure the data integrity of transactions.
Read Message flow transactions to understand how the integration node handles transactions. Depending on the external resource managers that the integration node accesses during the processing of its deployed message flows, you must complete the appropriate resource-dependent set of tasks to ensure that all resources are configured correctly. For example, you might have to create and configure databases, following the tasks in Working with databases.
On distributed systems, the WebSphere® MQ queue manager that is associated with the integration node performs the transaction manager role, which means that IBM® Integration Bus requires access to WebSphere MQ when processing messages. For more information, see Enhanced flexibility in interactions with WebSphere MQ.
You, or your message flow developer, must also ensure that the message flows deployed to the integration node are set up to support coordination. The tasks for configuring the message flows correctly are described in Configuring transactionality for message flows.
The following external resources are able to participate in a globally coordinated message flow transaction:
On distributed platforms, the default behavior of the integration node is to manage all message flow transactions by using local transactions (a one-phase commit approach). In many contexts this approach is sufficient, but if your business requires assured data integrity and consistency (for example, for audit reasons, or for financial transactions), you can configure the integration node with a local WebSphere MQ queue manager to manage the message flow transactions as globally coordinated (a two-phase commit approach), by using the XA protocol standard. To globally coordinate transactions, there must be a queue manager specified on the integration node, and that queue manager performs the transaction manager role. The queue manager that is specified on the integration node is used as a globally coordinated resource. Other queue managers cannot participate in the message flow transaction.
On z/OS®, all transactions
are globally coordinated by Resource Recovery Service (RRS), therefore
the instructions in this topic do not apply. However, you must ensure
that RRS is available; see Resource Recovery Service planning on z/OS. If you are connecting to CICS, you must also set the egXAForRecovery property
in a configurable service; see CICSConnection configurable service.
If the connection is lost to a WebSphere MQ resource when the message flow is running, automatic reconnection is delayed until the inflight transaction is complete; see Configuring MQ nodes for transactions.
Follow the instructions for the resource managers that are relevant in your environment and note whether they use static or dynamic registration:
You must complete all of the steps, because if your resources are not correctly configured for global coordination the message flow will run, but transactions will not be globally coordinated.