Yossi Dahan [BizTalk]


Sunday, July 23, 2006

Developing pipeline components to promote properties

A friend asked me today a question that highlighted this once again so I thought, although quite a few posts have been written on the subject, it might be worth mentioning it again.

The question was asked after he looked at this sample and was quite simple really - "Why do I need to worry about developing complicated custom pipeline components to manipulate promoted properties when I can promote properties through the schema or even use distinguished fields in my orchestration?" (well, it's not an exact quote - but that was the meaning, trust me..)

The first thing to remember, generally with BizTalk, not limited to this issue alone, is that you don't always have an orchestration.

It is easy to forget sometimes, especially if you've been doing a lot of orchestration development, that BizTalk is very useful even without any orchestration in sight. personally I did many projects that barely used them.

There are many reasons to use orchestration, but many others why not to, I guess that the obvious rule of thumb is that unless you actually need a workflow, you should question yourself whether you actually need an orchestration.

Which brings up the first point - sometimes all you have to go with is the pipeline, in which case distinguished fields are not useful.

The second point for promoting properties in a custom pipeline component is when you don't
actually want to have a schema for the incoming message (a lot has been written on this, so I'll leave it as a statement only here) or indeed when the incoming message is not xml (and is not parsed to one); in both these cases you will need to have custom logic to determine what to promote, and how to promote it.

Same applies when the rules for promotion are not simple, for instance if they are conditional, or if you need to promote a single instance of a repeating element etc. such cases are not supported by the property promotion declaration in a schema.

Of course you're still limited to promoting a single value to a single promoted property, but you have much more freedom as to how you get this value through custom code.

So - the bottom line is that in many cases you do need to write custom pipeline components to promote information to the message context.

A warning here - while very efficient and effective, custom pipeline components should be written with care - mainly you must ensure they are taking a streaming approach rather the


  • Nice article.
    As drilling further down on the subject , i found out that if i want to add custom properties to the context , i need to build&deploy a property schema for the custom properties as described here :

    Is there a way to achieve this goal with out all the fuss of building a property schema ?


    By Anonymous Anonymous, at 24/07/2006, 11:10  

  • The property schema provides BizTalk a definition of the properties you are going to write and/or promote to the message's context.

    This is needed for BizTalk's runtime operations but is also useful in design time for instance when you want to use custom context properties to set subscriptions (on orchestrations or send ports) as it will help populate a nice combo box for you to choose from.

    This is nothing new though, and is just the same when you are promoting properties in the orchestration - you still need a property schema.

    The only difference is that in the orchestration Visual Studio will kindly offer to generate one for you. generally you should visit the generated one and fix at least namespace given anyway, so this is not much of a shortcut.

    By Blogger Yossi Dahan, at 24/07/2006, 11:53  

Post a comment

<< Home