Configuring JMS and SOAP nodes to support globally coordinated transactions

To include message flow nodes that use JMS transport, such as the JMS and SOAP nodes, in globally coordinated transactions, you must complete additional configuration.

Before you begin

Review Configuring JMS and SOAP nodes for local transactions to understand what properties you must set on a SOAP or JMS node to use globally coordinated transactions.
Note: Global (XA) transaction coordination for nodes that use JMS transport is supported only if the message flow that contains the nodes is deployed to an integration node that has a dedicated queue manager; the integration node cannot share a queue manager with other integration nodes.

About this task

If you require global transaction coordination, choose a JMS provider that conforms to the Java™ Message Service Specification version 1.1 or 2.0, and that supports the JMS XAResource API through the JMS session.

If you specify your own JMS provider by using the JMS Providers policy, set the XA is supported property of the policy to true to indicate that the selected JMS provider supports XA coordinated transactions. If you set this property to true, and the selected JMS provider does not support XA transactions, an exception is raised. If you set this property to false, but the Transaction mode property on the node is set to Yes and the Coordinated Transaction message flow property is selected, an exception is raised.

If the message designer specified a non-XA-compliant provider, only the non-transactional mode is supported. In this case, you must set the Transaction mode property to None for all JMS and SOAP nodes that use JMS transport.

On distributed systems, an IBM® MQ queue manager provides the coordinated transaction support, which means that IBM App Connect Enterprise must have access to IBM MQ when it is processing the messages in the flow. For more information about using IBM MQ with IBM App Connect Enterprise, see Installing IBM MQ.

Procedure

To configure the message flow nodes, complete the following steps:

  1. In the IBM App Connect Enterprise Toolkit, switch to the Integration Development perspective.
  2. In the BAR file properties, set the Coordinated Transaction message flow property value to yes.
  3. In the Message Flow editor, set the Transaction mode property to Yes for each node that uses JMS transport that is required in the XA coordinated transaction.
  4. Create a Queue Connection Factory, and use either the default name, recoverXAQCF, or supply your own name.
    For more information about creating JNDI administered objects, see JNDI administered objects.
  5. There are two modes for enlisting an XAResource with the transaction coordinator:
    1. Static enlistment, which means that the XAResource is called to perform a start transaction when any message flow in the same Integration Bus starts a global coordinated transaction.
    2. Dynamic enlistment where the JMS node registers an interest in joining a global transaction when it has work to perform.

    Before deployment on distributed systems, you must set up a stanza for each JMS provider that you want to use. For Windows, the JMS provider switch file is called DynJMSSwitch.dll. For all other operating systems, the JMS provider switch file is called libDynJMSSwitch.so.

    Follow the steps in the appropriate topic for the operating system, or systems, that your enterprise uses:

What to do next

The JMS provider might supply additional JAR files that are required for transactional support; for more information, see the documentation that is supplied with the JMS provider. For example, on distributed systems, the IBM MQ JMS provider supplies an extra JAR file, com.ibm.mqetclient.jar.

You must add any additional JAR files to the shared_classes directory:

  • Linux platformOn Linux and UNIX: var/mqsi/shared-classes.
  • Windows platformOn Windows: C:\ProgramData\IBM\MQSI\shared-classes.

For more information, see the section about making the JMS provider client available to the JMS nodes in JMSInput node.