Yossi Dahan [BizTalk]


Sunday, July 06, 2008

Where is that orchestration?

I like visual designers. what I don't like is visual designers that try to protect developers from themselves; they always seem to go just one or two steps too far.

I find myself (and others, I believe) complain fairly frequently about the orchestration designer not letting us do this or that...and while in many cases it all makes sense (you really can't, or shouldn't be doing that), being over protected can cause a lot of confusion and waste precious time. here as example of something that happened to me a couple of weeks ago -

I was configuring a start shape in one of my processes, and when I tried to select the orchestration I wanted to start, it simply did not appear on the list of available orchestrations.

It took me a while - I rebuilt the assembly with the started orchestration and refreshed the assembly with the starting one - twice, but could not get it to appear. I've tried everything - including resorting to restarting visual studio -but could not see my process.

Only when I checked carefully the parameters requested by the started orchestration did I spot the problem - the orchestration had a 'ref' parameter.

Apparently orchestrations that have out or ref (I suspect they are pretty much the same in BizTalk) parameters do not appear on the list of processes in a start orchestration shape.

This makes sense really, as the start shape is asynchronous there's no way to use ref/out parameters with it. I just think a better design decision would have been to flag such selection as an error (at design and compile time) and not simply hide the irrelevant orchestrations.

This way it is immediately clear why I can't select the orchestration I planned to, I don't have to figure all of this out every time.

Labels: , ,


  • Hi Yossi,

    There's a difference between ref and out parameters - here's an excerpt of the relevant documentation:

    "When you use a reference parameter, no copy is made. The memory location that contains the data is shared between the calling program and the orchestration, and the contents of this memory location can be modified by the orchestration. Such a modification means that the value of the parameter is changed not only in the orchestration, but also in the calling program.

    An out parameter is similar to a reference parameter, but the orchestration cannot assume that it contains valid data when passed in; rather, the calling program expects the orchestration to assign a value to this parameter."

    The complete article is here:


    By Anonymous Erik Westermann, at 08/07/2008, 15:13  

  • Thanks Erik for clarifying that - I completely agree.
    The interesting point, if my experience is correct, is that in practice - in BizTalk, there does not seem to be any difference in the implementation of them, and the wording - specifically in the sentence "but the orchestration cannot ASSUME that it contains valid data when passed in" - suggests just that.

    My mistake was that I was under the impression that .net would insist that when passing out parameters to a method, nullable types are infact null. I vaguely remember seeing such a compile time error, but when checking this today I did not get such error.
    This means that this is, unlike what I thought, consistent with .net, but still I wonder - is this just a "convention" then? I could still pass in a value through an out param to my called orchestration/function...

    By Blogger Yossi Dahan, at 08/07/2008, 16:03  

  • "I could still pass in a value through an out param to my called orchestration/function"...

    You actually can pass a value and I believe BTS complains if you don't initialize the out parameter's message. This seems counter-intuitive but makes sense since we’re saying that an orchestration produces a particular message so, by definition, the message cannot be empty/null. It’s sort of like intending to leave a voice mail message and not making the call in the first place :) So you first have to make the call and send a message and BTS sends that same type of message back via the out parameter.

    BizTalk’s strict approach to differentiating between out and ref types is good under the circumstances since BTS effectively considers out and ref types as different types. Perhaps it is taking things a little too far, but I suspect that the difference between the two is that they are messaging engine performance hints (since everything passes through the MessageBox and is asynchronous [even if BTS tricks us into thinking that it is not]). So if BTS sees an out parameter, the messaging engine likely does not have to do a bunch of stuff and likely does more with ref parameters.

    BTS encourages a contract-first approach, so following that during design and development helps avoid a problem like the one you ran into.

    Live and learn, I suppose :)

    By Anonymous Erik Westermann, at 08/07/2008, 21:10  

Post a Comment

<< Home