Configuring global coordination of transactions (two-phase commit)
Globally coordinate message flow transactions with a transaction manager to ensure the data integrity of transactions.
Before you begin
Read Message flow transactions to understand how IBM® App Connect Enterprise handles transactions. Depending on the external resource managers that are accessed during the processing of 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.
The IBM MQ queue manager that is associated with the integration node performs the transaction manager role, which means that App Connect Enterprise requires access to IBM MQ when processing messages. For more information, see Interaction between IBM App Connect Enterprise and IBM 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.
About this task
If you have configured an integration node that specifies a local MQ queue manager, you can set up globally coordinated transactions for the message flows that are managed by the integration node. The specified queue manager then performs the transaction manager role.
The following external resources are able to participate in a globally-coordinated message flow transaction:
- IBM MQ queues and messages
- CICS®
- Databases
- JMS providers
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 IBM 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.
If the connection is lost to an IBM MQ resource when the message flow is running, automatic reconnection is delayed until the inflight transaction is complete; see Configuring MQ nodes for transactions.
- Static registration: The transaction manager involves all the resource managers in a transaction that are using static registration, even if a resource manager does not have a role to play in that transaction. Therefore all resource managers that use static registration must be available for the beginning of each globally coordinated transaction, even if they are not actively participating in that transaction, otherwise the transaction fails.
- Dynamic registration: Resource managers using dynamic registration must register with the transaction manager on a per transaction basis to get involved in a transaction (that is, if they are being updated as part of the globally coordinated transaction). A resource manager that uses dynamic registration does not need to be available for the beginning of each globally coordinated transaction.
Follow the instructions for the resource managers that are relevant in your environment and note whether they use static or dynamic registration:
Procedure
Results
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.