To include nodes that use JMS transport, such as the JMS and SOAP nodes, in globally coordinated transactions, you must complete additional configuration.
If you require global (XA) 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 using the JMSProviders configurable service, set the jmsProviderXASupport attribute 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, a WebSphere® MQ queue manager provides the coordinated transaction support, which means that IBM® Integration Bus must have access to WebSphere MQ when it is processing the messages in the flow. For more information about using WebSphere MQ with IBM Integration Bus, see Installing WebSphere MQ. On z/OS®, the external transaction manager is Resource Recovery Services (RRS).
To configure the nodes:
You must add any additional JAR files to the integration node shared_classes directory:
For more information, see the section about making the JMS provider client available to the JMS nodes in JMSInput node.
Optional: To secure the JMS connection factory, the JNDI bindings, or both, see Securing JMS connections and JNDI lookups.