I suspect that many developers, especially ones starting with BizTalk, see mostly BizTalk through orchestrations and see much less the messaging aspects of it.
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 when I can promote properties through the schema or even use distinguished fields for my orchestrations?" (well, it's not an exact quote - but that was the meaning, trust me...)
The first thing to remember, not necessarily related specifically to this issue, is that you don't always have an orchestration.
It is easy to forget, especially for someone who has been focused on them for a while, that BizTalk is very useful indeed without a single orchestration in sight.
Personally I did many projects that barely used them, and still gained great benefits from BizTalk Server.
There are many reasons to use orchestrations, but quite a few why not to as well. I guess that the obvious thumb rule is that unless you actually need a workflow, there's little to gain from 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.
I can think of a few more reasons, but the bottom line is that in many cases you do need (or want to, or should) 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