Configuring MQ nodes for transactions

When you define an MQInput, MQGet, MQOutput, or MQReply node, the options that you select for the properties define behavior for the transaction.

Before you begin

Review Configuring transactionality for message flows to understand what configuration is required for transactionality.

About this task

You can use WebSphere® MQ resources in either local or globally coordinated transactions:
  • For local transactions, you can have multiple queue managers participating in a message flow. Connections to queue managers can be local, client, or both. On z/OS®, you can use local connections only.
  • For globally coordinated transactions on distributed systems, you must specify a local queue manager on the integration node. This queue manager is the global transaction manager, and no other WebSphere MQ resources can be used in the message flow. On z/OS, all queue managers are globally coordinated. For more information about configuring for globally coordinated transactions, see Configuring global coordination of transactions (two-phase commit).

    If the connection is lost to the queue manager that was specified on the integration node in a globally-coordinated transaction, the integration node enters a standby state until the queue manager becomes available again. If the integration node was configured by using an MQ Service, then the integration node is stopped.

If a connection to a queue manager is lost, and that connection is enlisted in a transaction, automatic reconnection is delayed until the inflight transaction is complete. Other queue managers that are required, but are not part of the transaction, reconnect automatically without delay. A completed transaction can include the following cases:
  • The unavailable MQ resource was not required and was not used, because exception handling was defined in the message flow, so the inflight transaction was successful and committed.
  • The unavailable MQ resource was required, and the message flow cannot succeed without it, so the inflight transaction was rolled back.

Review how to set the properties for MQ nodes to determine how they participate in transactions.

Configuring transactions for MQInput and MQGet nodes

Procedure

  • The option that you select for the Transaction Mode property defines whether the message is read under sync point:
    • If you set the property to Yes (the default option): if a transaction is not already inflight, the node starts a transaction.
    • If you set the property to No, the node does not start a transaction.
    • If you set the property to Automatic: if a transaction is not already inflight, and the message is specified in WebSphere MQ as persistent, then the node starts a new transaction.

    All nodes that are subsequent in the message flow use the Transaction mode property that is set on the MQInput or MQGet node as their default transaction mode.

  • If you set the Browse Only property for an MQInput or MQGet node, the value that is set for the Transaction mode property is ignored. However, when the Transaction mode property of the output node is set to Automatic, any messages that are propagated later to that output node in the same instance of the message flow use the Transaction mode value set on the input node.
    The Browse Only property for an MQGet node is on the Request tab.

Configuring transactions for MQOutput and MQReply nodes

Procedure

The option that you select for the Transaction Mode property defines whether the message is written under sync point:
  • If you set the property to Automatic, the node participates in a transaction. If there is no inflight transaction, processed messages are committed immediately.
  • If you set the property to Yes, the node participates in the transaction currently inflight. If there is no transaction, then a new transaction is started for this node, and all other nodes that are connected to its output terminal.
  • If you set the property to No, an inflight message is immediately committed.

What to do next

To use MQ nodes in global transactions, follow the steps in Configuring global coordination of transactions (two-phase commit).

To understand when you might want to use a globally coordinated transaction for your message flow, see the Coordinating transactions section in the topic Message flow transactions.