Which System Exception?

I'm almost embarrassed to post this one, but it send me chasing windmills for a couple of hours, so if I can save that from any other unfortunate person it served a purpose I guess -

I have a call from one orchestration to another.

In the calling orchestration I wanted  to catch any exception that would occur on the called orchestration (or anywhere else down the line) and so I swiftly wrapped the call in a non-transactional scope and added an exception handler.

Being the keyboard-fan that I am (BizTalk is completely unfriendly to us keyboard types, but still...) when the type selector opened I did what I always do - I types the name of the class I wanted (System.Exception) and pressed enter.

The problem was that I did not type the class name ('Exception') but the full name ('System.Exception') and that got me System.SystemException class as the selected type, only that I did not realise that at the time.  apparently the type selector ignores special characters being keyed in?!

It was much later that I realised exceptions that were thrown in my called orchestration were not being caught in the calling one and even then it took me a good couple of hours to realise what was the reason (I simply did not look carefully enough at the exception type - System.SystemException just looks like System.Exception when you (well - I) glance at it!

Three take ways for me -

1. Pay more attention when doing even the most trivial tasks. (trivial, isn't it?)
2. Consider being less zealous about using the keyboard when doing BizTalk development
3. But seriously - consider always having a general exception handler to catch whatever exceptions were not caught by other handlers. I should have been mostly covered by catching System.Exception (although BizTalk, unlike C# or VB.net does support exceptions that do not inherit from System.Exception, see Charles Young post on the subject), but this could have helped at least identify the problem.

Is Michael right?

Michael Stephenson has suggested here that in his opinion the pipeline as a component is obsolete.

While something told me as I was reading this I could not agree with him 100%, I simply could not put my finger on the reason, I could not come up with a good enough argument against it; in fact - I still can't - which probably means he is right, but I have thought of the following two points -

The first one is not a justification, but a possible explanation of how things came about - as far as I understand it pipelines have always meant to be created at design time, then "compiled" and deployed; in 2004 there wasn't a straight forward way of using per-port configuration of pipelines, but soon enough the information that this can be done, and how to do so, became public and some developers (not all, obviously) have started using this method.

It was only in BizTalk 2006 that the ability to configure a pipeline was exposed in the UI; I guess that this points out that it was not the planned use initially (and also that MS definitely "listens" to the community, or market - call it as you wish)

It is worth noting that Michael does not stop at the pipeline component's configuration, but suggest the entire pipeline, i.e. - which components exist in the pipeline and in what order - should be configurable; this is taking the per-port configuration to another level, but it does make sense.

The second point I have in mind is that there's one benefit of having the pipeline as an artifact of sort, and that is re-use (and I'm guessing this was at least one of the considerations by MS, when making the decision to make the pipeline a compiled component) and in my experience I do find pipelines fairly highly reusable artifacts.

But this last point is not a very strong counter-argument (not that I intended it as such), just expanding on Michael's opinion and suggesting that the latter should be provided similar to ports, which are completely configurable through binding files, but are re-usable.

If we could create a pipeline in the admin console as an entity on it's own right (or through bindings) and then select it in ports, we could have the best of both worlds, mostly.

There would only be one thing I can think of that we would be missing out on, and that is the rich design environment we get when creating the pipelines in the pipeline designer - and I'm not talking necessary about the drag-and-drop way of adding components, I could not care less about that if I'm honest, but the rich property editor which is not currently supported in the generic per-port-pipeline-configuration.

Again - I'm sure this can be handled in the same way that adapter settings are handled in ports, given enough attention.

So - Michael - I am officially supporting your idea - where do I vote?

BizTalk Performance Optimisation Guide

Microsoft has announced the publication of the new "Performance Optiomisation Guide" written by Ewan Fairweather and Rob Steel.
I would expect this one to do wonders for some of us out there trying to give a little bit more "juice" to our BizTalk impelementation - grab it here.

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.