Configuring transactionality for message flows
Process messages in either local or global transactions, by setting message flow node properties that determine how the resources that they represent participate within the transaction.
Before you begin
- Ensure that you understand how the integration node handles transactions, and the difference between local and globally coordinated transactions; see Message flow transactions.
- Create a message flow by following the instructions in Creating a message flow.
About this task
How individual message flow nodes, and the message flow itself, participate in transactions depends on the way you design and develop the message flow, and the level of additional configuration you perform.
- You must configure the message flow node properties in your message flow to set the required level of participation in transactions.
- If you want the updates that are made by the message flow to be globally
coordinated by an external transaction manager (WebSphere® MQ), you must configure the message flow
properties.
To use global transactions, IBM® Integration Bus must have access to WebSphere MQ. For more information about using WebSphere MQ with IBM Integration Bus, see Enhanced flexibility in interactions with WebSphere MQ.
You can configure the message flow nodes in your message flow to determine how the work taken by each node participates in the message flow transaction. Most nodes for which transactionality is relevant have one or more properties that you can configure to dictate behavior. Therefore, you can decide for each individual message flow node whether it participates in the message flow transaction, or operates independently. Typically, these properties include an option of Automatic, so that subsequent nodes in the flow assume the characteristics set by the input node.
Message flow nodes that support transports that cannot participate in transactions might have other properties to determine what the integration node does when a message flow failure occurs. For example, the FileInput node has a set of Retry properties that you can set to determine failure behavior.
A few message flow nodes that interact with external resources do not provide properties; typically, these nodes are included in the message flow transactions. However, some exceptions exist. Check the relevant node topic and review the node properties for each node that you include in your flow to ensure that you understand what action is taken.
If you configure a node not to participate in the message flow transaction, the actions that it takes are committed, or rolled back, when the node exits. No further action is taken when the message flow itself completes.
To configure message flow behavior for transactions by setting node properties:
Procedure
After you have configured your message flow, you must add it to a BAR file before you can deploy it. When you add it to a BAR file, the message flow is compiled, and more properties are available for configuration.
On distributed systems, use the Coordinated Transaction property to configure for globally coordinated transactions. By default, this property is cleared (not selected), which means the message flow is using local transactions, and the integration node commits or rolls back the message flow transaction. If you select this property, the transaction is globally coordinated; the input node calls the external transaction manager WebSphere MQ for commit and rollback processing. This property is ignored when the message flow is deployed to an integration node that is running on a z/OS® system. For more information, see the Coordinating transactions section in the topic Message flow transactions.
To configure message flow properties:
What to do next
When message flow design and development is complete, you can deploy the BAR file to the integration node or integration nodes on which you want the message flow to run.
If you are configuring your message flows for globally coordinated transactions, additional configuration is required. You, or your system administrator, must ensure that your integration node environment, the transaction manager, and the participating resource managers are all correctly configured to support coordinated transactions, before you run the message flow. For more information on what might be required, see Configuring global coordination of transactions (two-phase commit).
If the integration node environment, the transaction manager, and the external resource managers are not correctly configured for global coordination, the message flow will run, but transactions will not be globally coordinated.