Yossi Dahan [BizTalk]

Google
 

Friday, March 24, 2006

Pipeline components settings in ports

I've been using quite a lot recently the much improved ability to reconfigure pipeline components settings at the port level.


And just in case someone still finds it new, here is something you don't want to miss -


When you create a pipeline in the pipeline designer, you set values the the various propreties of any components you use. That’s pretty usual


However - you can actually change these settings for a specific port after the pipeline has been deployed (in "Admin mode").

In BizTalk 2004 you could do this by programmatically setting a configuration XML to replace the deployed settings, this usually required writing some code or script to do so. (in fact - Jon Flanders has one right here)


In BizTalk 2006 this has become much easier - in the port, right next to the combo box that lets you select the pipeline (which has been improved by its own right and now displays the short name first") you will find a nice little magic button.


Clicking on this button magically opens a property editor that allows you to change every single property of every pipeline component you have in the selected pipeline. Magnificent!




One thing you'd notice if you go there is that the property bag has a little bit different feel to the one you get in the pipeline designer.


First of all - The names of the properties are the names given to they keys in the key-value pairs of the component's property bag (as opposed to the names of the class properties which are used in the designer) .


Secondly - any special instructions added to the property such as category, or even specific designer selection (such as file browse or the schema selector used mainly by the disassembler components) are be ignored.


I suspect this is because it is using the property bag directly and not the pipeline component class to interact with the configuration.


So - pay attention next time your naming a property when writing it to the property bag and when validating the information received from the property bag - don't rely on any property designer logic.


Another point I'd like to make is that, although this is an extremely useful feature, especially for development and test but possibly also in debug mode, I personally don't like to rely on it when designing a solution.


In my opinion it may cause confusion when coming back to the solution to add (or fix) logic as it is not immediately clear what settings get executed. If you don't remember to check whether any properties have been overridden in the port level (maybe by another party member, or the BizTalk admin) you might end up looking at the pipeline designer and not understand why it behaves differently then expected.


A second point to remember is that if you a single pipeline, used for different usages, you will not easily be able to distinguish between then when looking in HAT, and, from the same principle, you will not be able to configure different tracking options, as this is one pipeline.


So - in my opinion - if the settings are different by design, towards the stabilization phase pipelines should be separated.

0 Comments:

Post a Comment

<< Home