Imagine the project where most of the routing happens between orchestrations. I.e. routing is mostly between the MessageBox and orchestration with direct endpoints.
Imagine also the most of the messages are with the same Message type.
Usually in this case messages got the special node only for the routing. For example, the field can be the “Originator” or “Recipient” or “From” or “To”.
What wrong is with this approach, it creates the dependency between the message and the message processing. Message “knows” something about Originator or Recipient.
So what we can do with it? How can we “colorize” the same message to route it to the different places without changing the message itself?
One of the decisions is to use the message context.
BizTalk uses the promoted properties for routing.
There are two kinds of the properties: the content properties and the context properties. The content property
extracts its value from inside the message, it is a value of the element or attribute. [See MSDN
] The context property
gets its value from the message environment. It can be the port name that receive this message, it can be the message Id, created by the BizTalk. Context properties look like the headers in the SOAP message. Actually they are not the headers but behave like headers. The context properties are the good match for our case.
First, we don’t have to change the message itself to set or change the routing property. The context is stored outside the message body.
The main purpose of the context properties is working on behalf of the BizTalk internals. But we can read, create and change them. Just do not interfere with BizTalk internals on this way.
| posted on Sunday, February 27, 2011 4:26 PM