This bit of documentation explains that when you want to send a message out over the MQSeries adapter and receive a correlated response, the typical pattern is to:

1. Generate a value for the MQMD_MsgID property on the outbound message
2. Set the MQMD_CorrelID property on the outbound message to that same generated value, so that your “Send” shape can initialize a correlation that refers to the same property that will be present on the message you receive.
3. Send the message (initialize correlation with MQMD_CorrelID)
4. Receive the response (follow correlation with MQMD_CorrelID)

This assume that the destination system is following the usual pattern of setting the correlation identifier on the reply message equal to the message identifier on the request message.

Great.  Except when you don’t have the luxury of specifying the MQMD_CorrelID message on the outbound message to a value of your liking.  This occurs when you’re using a CICS bridge, or anything else that requires you to set the MQMD_CorrelID property to IBM.WMQ.MQC.MQCI_NEW_SESSION (signifying a new session interaction…)

In this case…you might be attempted to use the other pattern suggested here.  In this case, you engage in a solicit-response interaction with the adapter – where you send your request message and receive an immediate reply that contains a message with BizTalk_CorrelationID populated as a context property.  The message ID has also been generated for you.  You are then supposed to do a “dummy send” to initialize a correlation based on the BizTalk_CorrelationID property (sigh), and then follow that correlation with another receive shape that is the actual transaction response. 

To see this in action, see SDK\Samples\AdaptersUsage\MQSeriesAdapter\MQSCorrelationSetOrchestration under your BizTalk installation, or see the orchestration here.

Unfortunately, this design lends itself to a race condition.  The response coming back can occur prior to your correlation being initialized by the “dummy send”, resulting in a routing failure.  (This isn’t hypothetical – I just spent some time helping someone debug this issue.)

To work around this, you could try to do content-level correlation instead (i.e. use a promoted property in your request and response content.)