IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

Configuring transactionality for message flows

A message flow runs in a single transaction, which is started when data is received by an input node, and can be committed or rolled back when all processing has completed.

Before you start:

Ensure that you have completed the following tasks.

To ensure that you understand how the broker handles transactions, read Message flow transactions.
Create a message flow by following the instructions in Creating a message flow.

How individual 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:

Configure the node properties in your message flow to set the required level of participation in transactions.
If you want the updates made by the message flow to be globally coordinated by an external transaction manager, configure the message flow properties.

When you have finished message flow design and development, you can deploy the BAR file to the broker or brokers on which you want the message flow to run. However, if you have configured your message flows for globally coordinated transactions, additional configuration might be required. You, or your system administrator, must ensure that your broker environment, the transaction manager, and the participating resource managers are all correctly configured to support coordinated transactions, before you run the message flow. For details of what might be required, see Configuring global coordination of transactions (two-phase commit).

If the broker environment, the transaction manager, and the external resource managers are not correctly configured for global coordination, the message flow transactions will not be globally coordinated.

Configuring node properties

You can configure the 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 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.

Nodes that support transports that cannot participate in transactions might have other properties to determine what the broker 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 nodes that interact with external resources do not provide properties; typically, these nodes are included in the message flow transactions, but some exceptions exist; you must check the section that describes properties and how to set them, 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 flow itself completes.

To configure message flow behavior by setting node properties:

Open the message flow that you want to configure.
Set the Transaction mode property for the input nodes in this message flow. The value that you set determines the behavior of the input node, and sets the default behavior for the rest of the message flow. Typically, you can choose the value Yes or No;
- Yes means that the input node completes its own operation under sync point, and the default behavior in the message flow is for actions to be taken under sync point.
- No means that the input node completes its own operation out of sync point, and the default behavior in the message flow is for actions to be taken out of sync point.
Some nodes have additional or alternative values; for example, you can set the property on the MQInput node to Automatic, which means that the node gets the message under sync point if the message is persistent, and out of sync point if it is non-persistent.

For details of the specific options for and actions taken by each node, see the relevant node description; the properties, the tabs they are defined on, and the resulting behavior are not identical across all input nodes.
If your message flow includes nodes that interact with external resources, including output, request, and reply nodes, you can set a transaction property on most of these nodes.
Set the property only if you want to change the behavior of the individual node from the default behavior for the message flow, which you set on the input node. The value that you set on this node has no effect on subsequent nodes in the message flow. If the node does not have a transactional property, its behavior is governed by the default behavior for the message flow, which you set in the input node.

If your message flow is updating a database from multiple nodes in a single message flow, read the conceptual information about message flow transactions to understand the possible interactions.
1. Set the Transaction property for each node, if supported.
2. Set the properties that define how errors are handled, if supported. For example, for nodes like the Compute node that can access databases, set the Treat warnings as errors and Throw exception on database error properties to define how that node handles database warnings and errors. Whether you select these properties, and how you connect the failure terminals of the nodes, also affect the way in which database updates are committed or rolled back.

Configuring message flow properties

When 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 additional properties are available for configuration.

The most important property concerned with transactions on distributed systems is Coordinated Transaction. By default, this property is cleared (not selected), which means the message flow is partially coordinated and the broker commits or rolls back the message flow transaction. If you select this property, 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 a broker that is running on a z/OS® system.

To configure message flow properties:

Add the message flow to a broker archive.
Select the Manage and Configure tab below the broker archive editor view, and select the message flow. The configurable properties for the message flow in the broker archive are displayed in the Properties view.
Select coordinatedTransaction to configure the message flow as globally coordinated; when you set this property, the external transaction manager (WebSphere MQ) coordinates the transaction with all the resource managers that you have defined to the queue manager.

On z/OS, transactions are always globally coordinated. The setting of the coordinatedTransaction property for a message flow is ignored. Coordination is provided by the transaction manager RRS.

ac00390_.htm |

Last updated Friday, 21 July 2017