Integration Server 10.15 | JMS Client Development Guide | Working with Cluster Policies | Overriding the Cluster Policy when Sending JMS Messages | How to Override the Cluster Policy when Sending a JMS Message
 
How to Override the Cluster Policy when Sending a JMS Message
You can instruct Broker Server to override the policy applied to a cluster connection factory only when the following conditions are met:
*JMS messages are sent using a JMS connection alias that uses a cluster connection factory.
*JMS messages are sent using the same cluster connection factory. Note that multiple JMS connection aliases can use the same cluster connection factory.
*The cluster connection factory configuration allows the policy to be overridden. (In My webMethods Server, the Cluster Policy Override option is selected for the cluster connection factory.)
The following steps describe how to build a service that overrides a cluster policy to specify that the same Broker (or Brokers in the case of a multisend policy) processes a series of JMS messages.
Note:
When overriding the policy for a series of JMS messages, the messages do not need to be sent within the same flow service. Information about the Broker that received the initial message needs to be captured after the initial message is sent and then used when sending subsequent messages. This can be done across multiple services as long as each sending service uses the same cluster connection factory. For the sake of simplicity, the following steps explain how to send the messages in a single flow service.
1. Create the flow service that will send the JMS messages.
2. Insert a service to send the first JMS message.
Send the JMS message by invoking the pub.jms:send or pub.jms:sendAndWait service. For more information about sending JMS messages, see Sending and Receiving JMS Messages.
If you use the pub.jms:sendAndWait service to perform an asynchronous request-reply, you also need to invoke pub.jms:waitForReply to retrieve the reply message.
3. In the pipeline, add a new String variable to Pipeline Out.
4. Map the value of the JMS_WMClusterNodes output parameter to a new String variable in the pipeline.
If you sent the message using...
Then map this to the new String...
pub.jms:send
The value of the service output parameter JMSMessage/properties/JMS_WMClusterNodes produced by the pub.jms:send service
pub.jms:sendAndWait (synchronous)
The value of the JMSMessageReply/properties/JMS_WMClusterNodes output parameter produced by the pub.jms:sendAndWait service
pub.jms:sendAndWait (asynchronous)
The value of the JMSMessageReply/properties/JMS_WMClusterNodes output parameter produced by the pub.jms:waitForReply service
Do not edit the contents of the JMS_WMClusterNodes output parameter.
5. Insert a service to send the next JMS message.
Send the JMS message by invoking the pub.jms:send or pub.jms:sendAndWait service.
6. Map the value of the String field added in step 3 to the JMSMessage/properties/JMS_WMClusterNodes input parameter for the service invoked in step 5.
7. Repeat steps 4–6 for each JMS message that you want to be received by the same Broker (or Brokers).
Notes:
*Make sure to code the service to handle any ISRuntimeExceptions thrown as a result of a Broker Server exception for invalid data or as the result of unavailable Brokers. For more information, see Exceptions when Overriding Cluster Policies.
*When overriding a multisend guaranteed policy and using a connection transaction type of NO_TRANSACTION, if one of the Brokers is not available while Integration Server is sending the message, Integration Server does not retry sending the message with a different combination of Brokers. Instead, Integration Server throws an ISRuntimeException.