How to properly correlate EMS messages in TIBCO
3 days wasted trying to solve a TIBCO issue with EMS messages.
Heres the scenario:
Utilizing a TIBCO service with a “JMS Queue Requestor” that communicated with a backoffice java service (spring, jboss rules). The TIBCO service published messages to a specific ems queue.. MYSERVICE.REQUEST and would listen for responses to queue MYSERVICE.RESPONSE. The backend service would pick up messages from the MYSERVICE.REQUEST queue and write the response back to MYSERVICE.RESPONSE. Fairly standard flow here.
We started making use of a static reply queue and adding correlation_id on the JMS request msg so that random temporary queues would not be created (easier for debugging) for the response. Suddenly we received random occurrences where the message response no longer matched the associated request. I was able to easily recreate this problem in a development environment by creating a perl program that made several simultaneous requests to our service on different threads. With as few a 2 threads errors started occuring all the time.
After some time going through our custom java code I ended up utilizing GEMS to monitor the EMS queues incoming/outgoing responses. All looked fine here… so that pointed back at TIBCO. Thus leading me to eventually stumble across the solution in the TIBCO support forums. The solution is posted below but I find it Interesting that BW Designer interface allows you to create this scenario in the first place. Seems like a bug to me…. This ‘feature’ could easily cost a business many days and could be a critical failure point if it made its way into production systems.. imagine a financial application where messages were getting mixed up. Surely there can be more controls to prevent this scenario with the development tools.
** This highlights an important point to all you IT decision makers out there. Don’t just buy into the marketing/sales pitch when investigating software alternatives… Get valid references and speak to people using the product to get their true feedback on the product.
How to correlate EMS messages in a request response scenario
Case1
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) which receives these requests and sends back replies (Reply To JMS Message).
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 temp queue for the reply. It then sends the temp 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.
Case2
In Case1, if you need to use constant destinations for all replies and you do not want to use temporary destinations, then proceed with the following. Instead of using JMSQueueRequestor you can use the pair of JMSQueueSender and Wait for JMSQueueMessage Activities and then map the messageID of the JMSSender as the event key of the Wait for JMS activity and use the JMSCorrelationID header of the input message as the Candidate Event Key.
