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:
- Generate a value for the MQMD_MsgID property on the outbound message
-
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. - Send the message (initialize correlation with MQMD_CorrelID)
- 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.)