Yossi Dahan [BizTalk]


Monday, June 18, 2007

When is a subscription created for a correlation set passed as a parameter?

Ben Cops has asked a great question in a newsgroup last week in a thread I was involved with -

If you initialise a correlation set and then pass it as a parameter to an
async started orchestration where it is followed, when does the subscription
come into scope? When the correlation is initialised, or when the
orchestration containing the "follow" starts?

Initially, my instinct told me the subscription will be created when the correlation set is initialised; my instinct was wrong. (only that now that I know the answer I find it difficult to trace back my initial line of thought)

I think it was generally around the fact that I was confused to think (let's say - due to a momentary lapse of reason) that the subscription will be created as soon as the correlation set is initialised, and that received messages will get queued to be processed by the yet to be started orchestration.

The fact I've missed at that point, as Ben has kindly pointed out, is that the instance subscription that gets created is built of the correlation set properties and values (no problem there), but also with the message type defined in the receive shape following the correlation.

In this case, as the orchestration that will follow the initialised correlation set has not been loaded yet, BizTalk does not know what message type will be used, not to mention it cannot possibly know any details about the instance that is supposed to receive such message when it arrives, and so the subscription cannot be created at this point.

Only when the started orchestration gets called, the recevied message type is known and the subscription gets created (even before the receive shape is execute).

To prove this I've created a small sample (and before you ask - no - I did not upload it) built around two small orchestrations:

orchestration #1 starts with a received message (to trigger it), it then sends it out while initalising a correlation set, and then carries on to start orchestration #2 using a start shape passing the intialised correlation set as a parameter.

orchestration #2 has an expression shape followed by a receive shape configured to follow the correlation set received as an orchestration parameter.

I've put breakpoints in orchestration #1 on the send shape and start orchestration shape and in orchestration #2 on the expression shape.

I've executed the process and at the first breakpoint (the initalising send shape), I checked in the admin console to see that, as expected, the subscription was not (yet) created (as the correlation set was not yet initialised).

At the second breakpoint (the start orchestration shape) the correlation set was already initialised, but I still could not see the subscription in the admin console.

Only after the start shape executed when I was parked in the expression shape of orchestration #2 (before the receive shape), I could see the subscription in the query.

So - all I can say is - apologies for misleading you Ben and thanks for a great question.



  • Is this behaviour the same if you do a Call Orchestration instead of a Start? Because in my test I have a Delay in the main orch before the call, and the subscription is already there...

    By Blogger João Pedro "jota" Martins , at 02/06/2011, 15:32  

  • I didn't check Jota, but from your description it looks like it is.
    I am guessing that with a call orchestration being synchronous BizTalk is happier to 'look ahead' to find the type?

    By Blogger Yossi Dahan, at 02/06/2011, 16:45  

Post a Comment

<< Home