Abstract: I’ve been dealing with context properties, and I’ve discovered a couple of very useful tricks for promoting and routing.
As you’ll probably know, there are two types of properties in the context of a message: properties based on field values (MessageDataPropertyBase) and properties not based on fields (MessageContextPropertyBased). I’ll call the first ones Message Properties and the other ones Context Properties.
Message Properties based on message fields are automatically written and promoted into message context by BizTalk.
Context Properties not based on message fields can be assigned inside an orchestration using the expression Message(Property) = “value”;
One of the most interesting stuff about Context Properties is that are not tied to a concrete schema, so they can be used regardless the message type. A sample of a system context property is FILE.ReceivedFilename.
the problem of promoting context properties:
When you create a context property, not based on a message field, and you assign a value inside an orchestration, it is written, but not promoted. What does it means? it means that you cannot route the message based on this property.
Some days ago I had the situation where needed exactly this: content based routing based on a custom context property that had a value calculated inside an orchestration.
In my case, the pipeline solution is not an option, since I’m routing between orchestrations via Direct Port Binding. Also, coding a custom component to promote a property seems to complex for me…
Somebody told me a good trick to promote context properties inside an orchestration, easy and direct:
Create a CorrelationSet based on the property.
Even if you are not going to use it, when you initialize a CorrelationSet, the Orchestration engine makes the promotion of the properties involved, since correlation is just an special kind of routing.
So now I have some dummy CorrelationSets, that I call <Property>Promote_CorrelationSet
nice and easy! 🙂