When Integration Server sends a JMS message using a connection from a cluster connection factory, the policy applied to the cluster connection factory determines the Broker (or Brokers in the case of a multisend best effort or multisend guaranteed policy) to which the message is sent. When a series of JMS messages are sent using the same connection factory, different Brokers might receive the messages. In some situations, you might want the same Broker to receive all of the messages in the series.

For example, suppose that Integration Server sends a group of three JMS messages using a cluster connection factory to which the “random” policy is applied. It might not matter which Broker in the Broker cluster receives the first JMS message, but you might want the same Broker to receive the two remaining messages. For example, you might want the JMS messages to be processed in the same order in which the messages were sent. Or, if the Brokers in the cluster have different receivers that can process the message, you might want the same receiver to process all of the messages.

You can instruct the Broker Server to route the messages to the same Broker (or Brokers in the case of a multisend best effort or multisend guaranteed policy) by overriding the cluster policy.

Overriding the policy consists of two basic tasks:

To accomplish both tasks, most built-in services that send and receive JMS messages (pub.jms*) include a parameter named JMS_WMClusterNodes. This parameter is a child of the JMSMessage/properties document and JMSReplyMessage/properties documents. The JMS_WMClusterNodes parameter can be in the input and/or output signatures of the services.