|
Home > Archive > BizTalk Server General > September 2005 > Issue with MQSeries correlation in BTS 2004 using MQSeries adapter
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Issue with MQSeries correlation in BTS 2004 using MQSeries adapter
|
|
| Travis 2005-09-06, 6:02 pm |
| Background:
We’re developing an integration solution that employs BTS 2004 (+SP1)
talking to a host via MQSeries. We’re also using the MQSeries adapter (2.0)
provided by Microsoft to enable the MQSeries integration.
I’m trying to get a prototype orchestration (that was developed by someone
else no longer around) to work, and have so far failed to get it working
end-to-end. This prototype has allegedly been completely working in the past
– but I’m sceptical of this. Anyway….
The orchestration is invoked by a web service, a message is then put on an
MQSeries queue. The orchestration must then wait for a response on another
queue and then send a response message back to the web service.
BizTalk is installed on a developer box running XP SP1 and MQSeries is
installed on a Win2003 server.
Problem:
I’ve gotten it to the point of sending the message to MQSeries, the adapter
then appears to pick up the response message on the other queue, but the
response does not get correlated into the orchestration. An error along the
lines of “Could not find a matching subscription for the message” appeared in
the event log. Bizarrely, this error only appeared a few times, but the
problem still remains.
We’ve tried both the correlation techniques mentioned in the MQSeries
adapter documentation with no success.
Setting MQMD_MsgId and MQMD_CorrelationId to the same value
We initialize the above properties
T001MsgCorrelated(MQSeries.MQMD_MsgId) =
" 1112131415161718192021222324252627282930
31323334";
T001MsgCorrelated(MQSeries.MQMD_CorrelId) =
" 1112131415161718192021222324252627282930
31323334";
We send a message to the MQ Adapter (via a one-way port), the correlation
set is initialized during this operation.
The orchestration then waits at a receive shape for the response, using the
correlation set defined above as a “following correlation set”.
The correlation set in question simply has MQSeries.MQMD_CorrelId defined.
The message never gets correlated.
Using the MQSeries.BizTalk_CorrelationId context property
We initialize the above field…
T001MsgCorrelated(MQSeries.BizTalk_CorrelationID) = "";
We then send a message to the MQ Adapter (via a send-receive port) and
successfully get back the correlation message. Typical contents of message
are…
<MQS-Response><MessageID> 414D5120574342495A54443031202020BAD81C43
20003001</MessageID><CorrelationID> 0000000000000000000000000000000000000000
00000000</CorrelationID></MQS-Response>
The correlation set was original initialized as part of the request on the
send-receive port. However this did not make sense to me as I would have
thought the values would have been populated on the receive leg. I tried
setting it on the receive leg but then got the following error "in a
sequential convoy receive the ports must be identical". I also tried writing
the correlation response to a log file and initializing the correlation set
this way.
The orchestration then waits at a receive shape for the response, using the
correlation set defined above as a “following correlation set”.
The correlation set simply has MQSeries.BizTalk_CorrelationID defined.
Again, the message never gets correlated.
Potential issues that may be complicating the scenario:
* The orchestration uses multi-part messages
* We’re sending and receiving flat file messages on the MQSeries queues
(using custom pipelines with the flat file assembler/disassembler to achieve
this)
Any ideas as to what we’re not doing or doing wrong? Simple, easy solutions
are preferred :-)
-Travis
| |
| Scott Colestock 2005-09-06, 6:02 pm |
| Your first technique below should work...have you used the subscription
viewer to see what subscriptions are active at the point you are waiting for
the response message? You might get some clues as to what is going wrong by
looking at all the predicates.
As a fall-back, is there a business level identifier in both the request and
response you could correlate on instead? (This has the virtue of
disconnecting your orchestration from transport details.)
Scott Colestock
www.traceofthought.net
"Travis" <Travis@discussions.microsoft.com> wrote in message
news:DC97A0DD-BD19-4EFB-A4BA-2D2350165907@microsoft.com...
> Background:
>
> We're developing an integration solution that employs BTS 2004 (+SP1)
> talking to a host via MQSeries. We're also using the MQSeries adapter
> (2.0)
> provided by Microsoft to enable the MQSeries integration.
>
> I'm trying to get a prototype orchestration (that was developed by someone
> else no longer around) to work, and have so far failed to get it working
> end-to-end. This prototype has allegedly been completely working in the
> past
> - but I'm sceptical of this. Anyway..
>
> The orchestration is invoked by a web service, a message is then put on an
> MQSeries queue. The orchestration must then wait for a response on
> another
> queue and then send a response message back to the web service.
>
> BizTalk is installed on a developer box running XP SP1 and MQSeries is
> installed on a Win2003 server.
>
> Problem:
>
> I've gotten it to the point of sending the message to MQSeries, the
> adapter
> then appears to pick up the response message on the other queue, but the
> response does not get correlated into the orchestration. An error along
> the
> lines of "Could not find a matching subscription for the message" appeared
> in
> the event log. Bizarrely, this error only appeared a few times, but the
> problem still remains.
>
> We've tried both the correlation techniques mentioned in the MQSeries
> adapter documentation with no success.
>
> Setting MQMD_MsgId and MQMD_CorrelationId to the same value
> We initialize the above properties
> T001MsgCorrelated(MQSeries.MQMD_MsgId) =
> " 1112131415161718192021222324252627282930
31323334";
>
> T001MsgCorrelated(MQSeries.MQMD_CorrelId) =
> " 1112131415161718192021222324252627282930
31323334";
>
> We send a message to the MQ Adapter (via a one-way port), the correlation
> set is initialized during this operation.
>
> The orchestration then waits at a receive shape for the response, using
> the
> correlation set defined above as a "following correlation set".
>
> The correlation set in question simply has MQSeries.MQMD_CorrelId defined.
> The message never gets correlated.
>
> Using the MQSeries.BizTalk_CorrelationId context property
>
> We initialize the above field.
> T001MsgCorrelated(MQSeries.BizTalk_CorrelationID) = "";
>
> We then send a message to the MQ Adapter (via a send-receive port) and
> successfully get back the correlation message. Typical contents of
> message
> are.
>
> <MQS-Response><MessageID> 414D5120574342495A54443031202020BAD81C43
20003001</MessageID><CorrelationID> 0000000000000000000000000000000000000000
00000000</CorrelationID></MQS-Response>
>
> The correlation set was original initialized as part of the request on the
> send-receive port. However this did not make sense to me as I would have
> thought the values would have been populated on the receive leg. I tried
> setting it on the receive leg but then got the following error "in a
> sequential convoy receive the ports must be identical". I also tried
> writing
> the correlation response to a log file and initializing the correlation
> set
> this way.
>
> The orchestration then waits at a receive shape for the response, using
> the
> correlation set defined above as a "following correlation set".
>
> The correlation set simply has MQSeries.BizTalk_CorrelationID defined.
> Again, the message never gets correlated.
>
> Potential issues that may be complicating the scenario:
> * The orchestration uses multi-part messages
> * We're sending and receiving flat file messages on the MQSeries queues
> (using custom pipelines with the flat file assembler/disassembler to
> achieve
> this)
>
> Any ideas as to what we're not doing or doing wrong? Simple, easy
> solutions
> are preferred :-)
>
>
> -Travis
>
| |
|
| have you set the report-Id in the MQMD?
value:
0 means reply CorrelationID = request MessageID
64 means CorrelationID does not change
128 means MessageID does not change
192 means reply MessageID = request MessageID and Reply CorrelationID =
Request CorrelationID
I think a switch has been made and because of the switch the correlationID
is set to zero.
good luck,
Leon
"Travis" wrote:
> Background:
>
> We’re developing an integration solution that employs BTS 2004 (+SP1)
> talking to a host via MQSeries. We’re also using the MQSeries adapter (2.0)
> provided by Microsoft to enable the MQSeries integration.
>
> I’m trying to get a prototype orchestration (that was developed by someone
> else no longer around) to work, and have so far failed to get it working
> end-to-end. This prototype has allegedly been completely working in the past
> – but I’m sceptical of this. Anyway….
>
> The orchestration is invoked by a web service, a message is then put on an
> MQSeries queue. The orchestration must then wait for a response on another
> queue and then send a response message back to the web service.
>
> BizTalk is installed on a developer box running XP SP1 and MQSeries is
> installed on a Win2003 server.
>
> Problem:
>
> I’ve gotten it to the point of sending the message to MQSeries, the adapter
> then appears to pick up the response message on the other queue, but the
> response does not get correlated into the orchestration. An error along the
> lines of “Could not find a matching subscription for the message” appeared in
> the event log. Bizarrely, this error only appeared a few times, but the
> problem still remains.
>
> We’ve tried both the correlation techniques mentioned in the MQSeries
> adapter documentation with no success.
>
> Setting MQMD_MsgId and MQMD_CorrelationId to the same value
> We initialize the above properties
> T001MsgCorrelated(MQSeries.MQMD_MsgId) =
> " 1112131415161718192021222324252627282930
31323334";
>
> T001MsgCorrelated(MQSeries.MQMD_CorrelId) =
> " 1112131415161718192021222324252627282930
31323334";
>
> We send a message to the MQ Adapter (via a one-way port), the correlation
> set is initialized during this operation.
>
> The orchestration then waits at a receive shape for the response, using the
> correlation set defined above as a “following correlation set”.
>
> The correlation set in question simply has MQSeries.MQMD_CorrelId defined.
> The message never gets correlated.
>
> Using the MQSeries.BizTalk_CorrelationId context property
>
> We initialize the above field…
> T001MsgCorrelated(MQSeries.BizTalk_CorrelationID) = "";
>
> We then send a message to the MQ Adapter (via a send-receive port) and
> successfully get back the correlation message. Typical contents of message
> are…
>
> <MQS-Response><MessageID> 414D5120574342495A54443031202020BAD81C43
20003001</MessageID><CorrelationID> 0000000000000000000000000000000000000000
00000000</CorrelationID></MQS-Response>
>
> The correlation set was original initialized as part of the request on the
> send-receive port. However this did not make sense to me as I would have
> thought the values would have been populated on the receive leg. I tried
> setting it on the receive leg but then got the following error "in a
> sequential convoy receive the ports must be identical". I also tried writing
> the correlation response to a log file and initializing the correlation set
> this way.
>
> The orchestration then waits at a receive shape for the response, using the
> correlation set defined above as a “following correlation set”.
>
> The correlation set simply has MQSeries.BizTalk_CorrelationID defined.
> Again, the message never gets correlated.
>
> Potential issues that may be complicating the scenario:
> * The orchestration uses multi-part messages
> * We’re sending and receiving flat file messages on the MQSeries queues
> (using custom pipelines with the flat file assembler/disassembler to achieve
> this)
>
> Any ideas as to what we’re not doing or doing wrong? Simple, easy solutions
> are preferred :-)
>
>
> -Travis
>
|
|
|
|
|