How to correlate EMS messages in a request response scenario

Table of Contents

• Case 1
• Case 2
• Case 3
• Document References
• Troubleshooting
• Information to be sent to TIBCO Support

Case 1

Consider the scenario where you are using a JMS Queue Requestor which sends a request and waits for a reply. Additionally, you have a corresponding process (say a JMSQueue Receiver) that receives these requests and sends back replies (Reply To JMS Message).

The JMS request/reply activity uses temporary destinations to ensure that reply messages are received only by the process instance that sent the request. While sending each request the JMS Queue Requestor creates a temporary queue for the reply. It then sends the temporary reply queue name along with the request message. The temporary queue name is unique for each process instance.

If the replyToQueue queue (static) is specified then all replies will be sent to the same queue and there will be no guarantee that the correct reply will be received by the process instance that sent the request.

You can use an expression for the replyToQueue to create different replyToDestinations for each request.

Case 2

In Case1, if you need to use constant destinations for all replies and you do not want to use temporary destinations, then instead of using JMSQueueRequestor you need to do the following procedure:

1. use a pair of "JMSQueueSender" and "Wait for JMSQueueMessage" activities

2. map the messageID of the JMSSender as the event key of the "Wait for JMS" activity

3. use the JMSCorrelationID header of the input message as the Candidate Event Key

Case 3

In a multi-engine environment, where you have multiple "Wait for JMS Message" activities listening on the same queue for reply messages, you should consider using GetJMSQueue Message.

In a multi-engine environment, with multiple ?Wait For? activities listening on the same queue, it is likely that the first requestor will be waiting for a reply it will never receive as the second requestor has already consumed the reply message. Since the candidate event key does not match the incoming message?s event key the message is discarded. In this case, the first requestor who sent out the request will never receive the reply.

This is the default behavior of ?Wait For? activities. When using ?Wait For? JMS message activities, a listener consumes all messages from the queue at engine startup and stores them in process memory. In the case of multiple ?Wait For? activities listening on the same queue, if one listener has already consumed the message, the other listener on the same queue will never receive the message.

The correct design would be to use the ?Get JMS Message? activity instead of the ?Wait For JMS? activity. You can set the "selector" property of the "Get JMS Queue Message" activity to use the following XPath to correlate the request message with its reply message.

 concat("JMSCorrelationID = '"        ,$JMS-Queue-ender/pfx:aEmptyOutputClass/pfx:MessageID,"'")

When using a message selector, the EMS server does the filtering of the message based on the selector and determines if the message can be delivered to the particular "GetJMSQueue Message" activity.

Whereas with the ?Wait for JMS" activity, the message is sent to the queue as soon as it arrives on the queue and the filtering is done at the job level where the Candidate Event key is matched with the incoming message?s event key.

Document References

For details, please refer to the following TIBCO ActiveMatrix BusinessWorks? documentation:

Palette Reference --> Chapter 9 JMS Palette

Troubleshooting

• If the correct replies are not received, review the process design.

You can connect to tibemsadmin tool and check for the number of receivers on the queue by using

 Show queue

You can enable tracing for message IDs and correlation IDs in the tibemsd.conf

 track_message_ids = enabled track_correlation_ids = enabled 

• Additionally, you can turn on detailed tracing for both EMS server and client as follows

  1. set server log_trace=DEFAULT,+PRODCONS,+MSG

  2. set server client_trace=enabled

  3. Addprop queue trace=body (* For both the request and reply queues.)

Then check the messages that are sent by the server and received by the client.

Information to be sent to TIBCO Support

1. Confirm the Admin/TRA/BW/EMS versions with hotfixes, if any.

2. Please send the multi-file project and the deployed .ear file.

3. EMS configuration files.

4. Other output of EMS admin commands as and when requested by TIBCO Support.