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.

  1. You must configure the message flow node properties in your message flow to set the required level of participation in transactions.
  2. 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

  1. Open the message flow that you want to configure.
  2. 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. 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. The default behavior in the message flow is for actions to be taken out of sync point.

    Some nodes have extra 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 that are taken by each node, see the relevant node reference topic. Review the node description, its properties, and the tabs on which the properties are set, because the resulting behavior is not identical across all input node types. Alternatively, you can read how to configure the following specific node types:
  3. 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 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 how database updates are committed or rolled back.

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:

  1. Add the message flow to a BAR file.
  2. Select the Manage and Configure tab below the BAR file editor view, and select the message flow.
    The configurable properties for the message flow in the BAR file 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.

    z/OS platformOn 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.

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.