Oracle BPEL Request-Reply JMS bridge

Scenario:
The system needs to be integrated asynchronously with other system using JMS Queues. The BPEL system will send a message in one queue (Q1). The other system will listen to Q1, processes the message and push the result in other queue (Q2). The BPEL instance should wait once it pushes message in Q1 and should continue when the reply for this message appears in Q2.

To satisfy this scenario, i followed these steps

I created one BPEL with SOAP service and JMS of type request-reply

In the BPEL, i have not added much business logic, just the assign operations

To check the behavior, I did below steps

1. I invoked the SOAP service. 
2. It created one instance in the BPEL. It also pushed one message in request queue (Q1).
3. I repeated this for 2 more times. This created total 3 instances in BPEL and 3 messages in Q1. 
4. Now I opened the Q1 in wewblogic and copied the message created by instance #2 and pushed that message in Q2. 

Expected Result:

The instance #2 should be completed and other instances #1 and #3 should be in running state.

Actual result: 

I see the instance got created in BPEL with failed status with error "Cannot complete callback since unable to retrieve SourceURI/Wire from Correlation store. Either Instance Tracking is disabled or no corresponding Request succeeded prior to this callback" and all 3 instances are still in running state.

I found the the reason behind error, which was easy to find. It was failing because it was not finding any listening instance as the correlation ID was not matching. I was not setting any correlation ID so by default JMS adapter was using message ID as correlation ID. To validate the understanding I pushed one message in Q2 with message ID of instance 3. (this message id was copied from Q1). 

Check the details in below screen shots

Message from Q1






New Message in Q2

After this the respective instance got completed.

The message ID is generated on the fly and it is a random value. So this value can;t be predicted. To make it predictable, I thought of using a unique value from the payload and set it in the correlation ID specifically through BPEL. As it is a part of message, it will be present in queue and the program reading it and pushing a message in Q2 will also have it so that it can be set in Q2 message too.
To set the value of correlation ID in Q1, i made the changes in BPEL as below.

This way we will be sure about correlation ID. This value can be seen in Corr ID in message queue Q1.