Can we utilize the JMSCorrelationID to correlate a request response message using the JMS Request Response activity with a static response queue?

Products	Versions
TIBCO ActiveMatrix BusinessWorks	-
Not Applicable	-

Description

Resolution:

Scenario:

1). User wants to use JMSQueueRequester activity.

2). User wants to use static queues.

3). User wants to make use of JMSCorrelationID.

As per the JMS specification, the QueueRequester constructor is given a QueueSession and a destination queue. It creates a Temporary Queue for the responses and provides a request method that sends the request message and waits for its reply. It is well documented in both JMS and BW documents that requester logic uses temporary destinations. However, it is also mentioned in the JMS specification that, "This is a basic request/reply abstraction that should be sufficient for most uses. JMS providers and clients can create more sophisticated versions". For more details, refer to the JMS specification.

Abstract

= = = = =

1). User can use built-in JMS Queue requester activity with its default setting, that is, without specifying a replyTo queue and letting the activity receive replies on temporary destinations. It is an important characteristic of temporary destinations that they support only local use where only the client connection that has created a temporary destination can consume messages from it. Therefore, no client other than those who have created it can pick messages from that destination. Refer to thee EMS documentation for more details. The design goal of the JMS queue requester is to implement synchronous request-reply mode which makes JMSCorrelationID useless in this scenario. With temporary destinations, by default, request messages already have a one-to-one relationship with response messages.

2). Users can create their own requester logic using a Send JMS message (to send requests) and use a Get JMS message activity (to a receive reply). This approach uses static destinations for reply and by making use of a selector. The Get JMS activity picks only messages among all available messages which evaluates the selector.

3). If a user still wants to use static queues as replyTo destinations in a JMS Request reply activity, they should consider the notes given in our documents. The BW 6.x User guide specifically points to these notes.

- "This activity uses temporary destinations to ensure that reply messages are received only by the process that sent the request. However, the user has the ability to use preexisting JMS destinations".

- "If more than one job has the same replyToDestination (for example, you specify a constant in this field), then the correct reply may not be received by each job. Make certain that you specify an expression in this field that assigns a different replyToDestination to each process instance".

Since a JMS request reply activity does not have an option for a selector, what is the purpose of providing JMSCorrleationID field in input tab? The JMSCorrleationID field can be set by a producer client when they send messages to an EMS server. Here a producer client means both a requester and response side application as they are both treated as producer clients for the EMS server. Below are the details of JMSCorrleationID from the EMS User Guide.

- "This ID can be used to link messages, such as linking a response message to a request message. Entering a value in this field is optional".

Confusion may arise because of the word "link" above. We expect there is or has to be an internal mechanism in a request reply activity which filters messages based on JMSCorrleationID specified in a request and response message. JMS request reply activity cannot have provision of filters based on JMSCorrleationID or any other header / property due to internal product design. If the selector option is made available it can have an inverse impact. We suggest using a combination of Send JMS message and Get /Wait JMS message activity which provides selector options.

Note that JMSCorrleationID is not for filtering out messages but is for correlating messages when tracking the request and response. When you have parallel execution of multiple process instances, how should you track the request and response messages? Here is where JMSCorrleationID comes into the picture. You can set JMSCorrleationID for the request message. When the request message is received on the receiver side, map JMSCorrleationID from the receiver activity to the Reply To JMS message activity's JMSCorrleationID field and send a response. The requester can fetch that JMSCorrleationID again for tracking. When logging this work flow for more than one running instance, JMSCorrleationID will help track the request response flow.

It is not mandatory that only the JMSCorrleationID should be used for filtering in activities which support selector options. You can create your own JMS message properties and apply selectors on them. In other words, JMSCorrleationID is not for filtering out the messages but is added as a header which you can use to correlate the request and response message.

BW and EMS supports the JMS specification, therefore while creating a JMS message, the JMSCorrleationID header has to be there and cannot be removed that from the input tab of request reply activity. Since that field is optional, you can either use it or keep it blank.

In short, JMSCorrleationID is not for filtering out messages but is for correlating messages when tracking of the request and response, just like any other JMS header property (optional) available as per the JMS Specification. Its depends on the client's implementation whether to use it for correlation or not. In BW JMS Request/Reply activity, we are not utilizing the request response correlation using the selector + JMSCorrleationID, because it can have an adverse impact.

Points to be noted:

1). If you want to achieve request-response use case with JMS request reply activity, use it with its default nature, i.e., with temporary destinations. BW will ensure to deliver the correct response to the requester.

2). If you want to use static queues in a request reply activity, ensure that the queue be unique across multiple process instances.

3). While receiving a response, if you want to filter out the messages based on some value (it could be JMSCorrleationID or JMS properties), use a combination of JMS queue sender and wait / get JMS queue messages and make use of the selector option.

See the attached (Filename: requesterApplication.zip) for reference.

Issue/Introduction

Can we utilize the JMSCorrelationID to correlate a request response message using the JMS Request Response activity with a static response queue?

Attachments

Can we utilize the JMSCorrelationID to correlate a request response message using the JMS Request Response activity with a static response queue? get_app

Welcome to "KB Articles"