|
Home > Archive > BizTalk Server Orchestration > August 2005 > "sequential convoy" on "different ports"
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 |
"sequential convoy" on "different ports"
|
|
| XstevebX@Xinetdev.comX 2005-08-15, 5:51 pm |
| Is it in any way possible to correlate in an orchestration (non uniform
heterogeneous sequential) using two different ports? It works fine using an
original message and follow up message that correlate on a MessageID (GUID)
when they come into the same port, in this case bound to a directory. But it
is desired that I do the same with two different ports for tracking purposes.
Another reason could be because the origination message is a file drop and
the response is via a web service.
Thank you.
SteveB (vsf)
| |
| Scott Colestock 2005-08-15, 5:51 pm |
| Have you considered having your orchestration subscribe by type -- rather
than by physical port?
(i.e. your orchestration can use direct binding - and subscribe directly to
the message box.)
That way, you can have a single logical port in your orchestration.
Scott Colestock
www.traceofthought.net
"XstevebX@Xinetdev.comX" <XstevebX@Xinetdev.comX@discussions.microsoft.com>
wrote in message news:D17CFF68-927A-447E-B1CB-BE9C638DE8F0@microsoft.com...
> Is it in any way possible to correlate in an orchestration (non uniform
> heterogeneous sequential) using two different ports? It works fine using
> an
> original message and follow up message that correlate on a MessageID
> (GUID)
> when they come into the same port, in this case bound to a directory. But
> it
> is desired that I do the same with two different ports for tracking
> purposes.
> Another reason could be because the origination message is a file drop and
> the response is via a web service.
>
> Thank you.
>
> SteveB (vsf)
| |
| Jason Agostoni 2005-08-16, 7:50 am |
| Steve ... you can "break" the convoy but using a Send shape followed by
your subsequent receive shape. The send, in theory, should be used to
notify the sender that your orchestration is ready to receive but in
practice you could just have it go to a black hole.
I have used this to "trick" BizTalk into thinking I am no longer doing
a sequential convoy and, thus, circumventing the rules. I generally do
not use this exactly like you are describing but instead as a means for
implementing a non-uniform sequential convoy using Call Orchestration
shapes. The pattern is: I have an activate receive in the main
orchestration, I pass that message into a Call Orchestration shape, I
have the sub-orchestration use a dummy send shape to "break" the
convoy, I receive the subsequent message and return something (as an
outbound parameter) to the calling orchestration.
Seems to work great everytime. Credit goes to Paul for helping me
figure this out to solve another problem I was having!
Jason Agostoni
Associate .Net Architect
CEI (www.ceiamerica.com)
http://jason.agostoni.net
| |
| Steven Barden 2005-08-16, 5:57 pm |
| I had not. In fact this is why I asked. Thank you very much for your help! I
am using your deploy enviromnet, version 2.52. I am giving a demonstration to
others as well. Thank you for all of your work.
sb
"Scott Colestock" wrote:
> Have you considered having your orchestration subscribe by type -- rather
> than by physical port?
> (i.e. your orchestration can use direct binding - and subscribe directly to
> the message box.)
>
> That way, you can have a single logical port in your orchestration.
>
> Scott Colestock
> www.traceofthought.net
>
>
>
>
> "XstevebX@Xinetdev.comX" <XstevebX@Xinetdev.comX@discussions.microsoft.com>
> wrote in message news:D17CFF68-927A-447E-B1CB-BE9C638DE8F0@microsoft.com...
>
>
>
| |
| Steven Barden 2005-08-16, 5:57 pm |
| Jason, thank you for your help! I think the concept was begining to
formulate, but your help has answered not only many direct questions, but a
few related to concepts as well.
Thank you again.
sb
"Jason Agostoni" wrote:
> Steve ... you can "break" the convoy but using a Send shape followed by
> your subsequent receive shape. The send, in theory, should be used to
> notify the sender that your orchestration is ready to receive but in
> practice you could just have it go to a black hole.
>
> I have used this to "trick" BizTalk into thinking I am no longer doing
> a sequential convoy and, thus, circumventing the rules. I generally do
> not use this exactly like you are describing but instead as a means for
> implementing a non-uniform sequential convoy using Call Orchestration
> shapes. The pattern is: I have an activate receive in the main
> orchestration, I pass that message into a Call Orchestration shape, I
> have the sub-orchestration use a dummy send shape to "break" the
> convoy, I receive the subsequent message and return something (as an
> outbound parameter) to the calling orchestration.
>
> Seems to work great everytime. Credit goes to Paul for helping me
> figure this out to solve another problem I was having!
>
> Jason Agostoni
> Associate .Net Architect
> CEI (www.ceiamerica.com)
> http://jason.agostoni.net
>
>
|
|
|
|
|