Yossi Dahan [BizTalk]

Google
 

Monday, February 25, 2008

Wish list: "End" shape.

Often orchestrations have conditions that, when met, mean the orchestration should stop executing.

In .net code a developer could simply put a “return” keyword in the function to stop the execution and return to the caller; unfortunately there is no equivalent in orchestration development.

The only “clean” way to end an orchestration currently is to reach the built-in, fixed, red shape at the bottom of the orchestration designer.
This often means that decision shapes exist all over the orchestration with branches that have to drop all the way to the bottom. In large orchestrations this can be hard to follow up on.

It could have been made much nicer by allowing a developer to add as many “end” (or “return”) shapes as needed in various places in the process. Decisions, of course, will still exist, but their scope will be much smaller.

An alternative that exists currently is to use the terminate shape, but I find it to be a bit artificial – my view is that termination of processes may be relevant in exceptional scenarios, as part of error handling, etc. but not when the orchestration ends correctly (albeit before reaching the end of the schedule). The main problem with the terminate shape possibly is that the orchestration gets a “terminated” state and not “completed” which will make it difficult to report in HAT (and otherwise)

Labels: , ,

2 Comments:

  • In proper structured programming theory, all functions are suppose to adhere to a single entry and single exit (SESE) paradigm. This is to ensure consistency.

    This is also recommended because in normal C++ syntax multiple returns can be hard to find larger functions. BizTalk is different because the HAT and stop sign allow the programmer see where the code would exit.

    However, while SESE can be sacrificed for benefits like code compactness in embedded devices, mulitple end shapes may sacrifice code quality for programmer convenience.

    Further, the terminate shape allows an expression to state why the orchestration terminates while the end shape does not.

    By Anonymous Anonymous, at 26/02/2008, 01:30  

  • Great comment and a very good point! thank you.

    I take your point, and did not think of that, but I have to admit - defensive or not - I am still not convinced it applies to a BizTalk orchestration.

    For starters, an orchestration model is not exactly equivalent to a function. you can "return" at any point (and infact in multiple points) by publishing a message to the message box.

    The designer is a (very) visual, and although orchestration can get fairly large, there are only a handful of shapes one can use, and so spotting a red circle amongst them is hardly difficult.

    On the other hand - following up on 20 lines that drop to the end to realise the variuos possible conditions in which we wish to end the process is even more confusing.

    The code generated may well still follow SESE, but can mask it away from me.

    And Last - with regards to suspend and terminate shape - they already don't follow that principle...and I want my orchestration to show as complete (as it did) and not terminated or suspended which, to me at last, suggest some exceptional case (and sharing them between "problems" and good cases will make monitoring more difficult.

    Hope that makes sense

    By Blogger Yossi Dahan, at 27/02/2008, 22:41  

Post a Comment

<< Home