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).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.
Below example gives you brief idea of Request-Reply mechanism, for this create two processes one for Request and another process for Response.
Request Process:
Response Process:
Run both the processes and check...
Case2:
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:
- use a pair of "JMSQueueSender" and "Wait for JMSQueueMessage" activities
- map the messageID of the JMSSender as the event key of the "Wait for JMS" activity
- use the JMSCorrelationID header of the input message as the Candidate Event Key
- If you run the process then the control or process stops at wait for JMS Queue message , means it waits until it receives a message with the correlation id as Message Id of JMS sender.
- So for the completion of this process you need to run a JMS Producer with Correlation ID as Message ID of that particular message and check ....
- Have fun!!!!
