Imagine the following scenario: you have a number of orchestrations in your BizTalk solution that are all activated by a certain messagetype. And there is one special orchestration that, using some procedure, generates those messages. The idea is that this special orchestration writes the generated message to the messagebox and that way the associated orchestration will be started. Sounds easy, right?
Alas, not everything in life is easy... Here, the problem is your generated messages are untyped, that is, the message type in your orchestration is System.Xml.XmlDocument. When you write this message to the messagebox using a Direct send port, it has no promoted properties which are needed for the routing, so you will end up with a 'Routing Failure' error.
The only property we really need to promote is BTS.MessageType. And here's the problem: within an orchestration you can promote almost every property... except BTS.MessageType, which is read-only! Grrrr.....
You can work around this by writing the message to some file location and then have a receive location using the XMLReceive pipeline. Fine, but obviously we don't want that. We want to fix this in our own orchestration! Can we do this? To quote Mr. Obama: Yes, we can!
In the work-around we use the XMLReceive pipeline. That pipeline promotes the properties, including BTS.MessageType! And BizTalk allows you to invoke a pipeline from within an orchestration! So let's do this!
Alas there is one minor problem here. Invoking a pipeline from within an orchestration's shape forces you to use Atomic scope. Which we don't want, do we? We can avoid this by not invoking the pipeline directly from the orchestration's shape but by using the following class-method:
You will need to add references to Microsoft.BizTalk.DefaultPipelines, Microsoft.BizTalk.Pipeline, Microsoft.XLANGs.BaseTypes, Microsoft.XLANGs.Engine and Microsoft.XLANGs.Pipeline to your project. The dll's can all be found in your Microsoft BizTalk Server 2010 folder.
So now we can use this method in our orchestration: create a variable xdoc of type System.Xml.XmlDocument, create a message msgUntyped of the same type, create a Construct Message shape, and use a Message Assignment shape. In that last one, use the following code:
And the message has promoted properties!
Now there's one last trick... if you send this message using a Direct send port, it will still drop the promoted properties. Why? Beats me! Probably the guys at Microsoft figured that a message of type System.Xml.XmlDocument doesn't need properties. So how can we avoid that?
Create a correlation set, based on a correlation type with Correlation Properties 'BTS.MessageType'. On the send shape in your orchestration, use this correlation set as the Initializing Correlation Set. That way, you force BizTalk to maintain the promoted properties for that message.
And there you go! That's what we need to do to go from untyped message to typed message in the messagebox.