Hello everyone,

I am using BizTalk 2004 and have an orchestration published as a web
service.  The request-response port has two operations (call them Op1
and Op2).  I initialize a correlation in the orchestration, then I
have a listen object that has 3 branches; one branch each is listening
on Op1 and Op2 to follow the correlation, and the 3rd branch is a
timeout. The problem is that all calls to the web service activate the
Op1 branch of the listen shape, even if the call is made to the Op2
method in the web service.

I have confirmed that the correct method is being called in the web
service proxy.  I look in the BTSSubscriptionViewer and see that the
evaluation criteria for both listen shape subscriptions is identical
other than the MethodName in each subscription.  I put breakpoints in
the orchestration and call the Op2 method of the webservice.  When I
break out, the MethodName in the context is indeed Op2, and all the
subscription criteria seen in the subscription viewer is present in
the context.  Yet, all it will ever do is execute the branch for Op1.

Any ideas?

[ Post a follow-up to this message ]

Is the criteria for OP1 being met as well as OP2 or does OP1 actually have
"MethodName = OP1" in the subscription? One trick which I like to do is to
create a dummy sendport, create a filter on it which will catch all
messages from your webservice, enlist (don't start) the sendport, then run
your test. Now when the message gets sent you can check all of the
properties that were on the message by looking in HAT at the suspended
instance of the sendport. Hopefully this will give you some insight into
why it is being routed to OP1. I am not sure of the semantics, but if it
gets routed to both OP1 and OP2, you might just be getting it always sent
to OP1 because we just pick one internally. I am really not sure about that
point, though. I would try my debugging tip above and see what the context
of the suspended message tells you.

HTH
Lee

This posting is provided "AS IS" with no warranties, and confers no rights.

EBusiness Server Team
--------------------[vbcol=seagreen] 
23:12:29 GMT)[vbcol=seagreen] 
cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed00.s
ul.t-online.de!t-online.de!fr.ip.ndsoftware.net!proxad.net!postnews2.google.
com!not-for-mail[vbcol=seagreen] 

[ Post a follow-up to this message ]

Thanks for your reply,

I did what you suggested to verify that the context had the correct
MethodName property in the context of the message.  It is indeed the
correct method name in the context, and it does match what is listed
as the subscription criteria as shown in the subscription viewer.  The
message is not being delivered to any receive object in the listen
object other than the very first receive object.  The receive object
in the first branch is connected to the OP1 method on the receive
port, branch 2 is connected to OP2.  Everything is always delivered to
the first branch.  I even tried swapping the connections and the
message is still delivered to the first branch of the listen object.

I don't know if this helps, but the messages are multipart types.  The
orchestration in question is published as a web service.  Creating two
receive-send ports of the same type and connecting them to different
branches does work, but this is not ideal since it will create two web
services containing a single, identical method call.  It would be
easier to allow services integrating with this orchestration to make a
call to multiple, distinctly named methods on a single web service.



leegr@microsoft.com (Lee Graber [MSFT]) wrote in message news:<reEJ$iXXEHA.2408@cpmsftng
xa10.phx.gbl>...[vbcol=seagreen]
> Is the criteria for OP1 being met as well as OP2 or does OP1 actually have
> "MethodName = OP1" in the subscription? One trick which I like to do is to
> create a dummy sendport, create a filter on it which will catch all
> messages from your webservice, enlist (don't start) the sendport, then run
> your test. Now when the message gets sent you can check all of the
> properties that were on the message by looking in HAT at the suspended
> instance of the sendport. Hopefully this will give you some insight into
> why it is being routed to OP1. I am not sure of the semantics, but if it
> gets routed to both OP1 and OP2, you might just be getting it always sent
> to OP1 because we just pick one internally. I am really not sure about tha
t
> point, though. I would try my debugging tip above and see what the context
> of the suspended message tells you.
>
> HTH
> Lee
>
> This posting is provided "AS IS" with no warranties, and confers no rights
.
>
> EBusiness Server Team
> -------------------- 
>  23:12:29 GMT) 
> cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed00
.s
> ul.t-online.de!t-online.de!fr.ip.ndsoftware.net!proxad.net!postnews2.googl
e.
> com!not-for-mail 

[ Post a follow-up to this message ]