Q: re: context properties on messages typed as XmlDocument

Hi,

I’m working on a solution for a customer and came across an interesting challenge. Let me start by providing a general description of our solution:

We have a series of event records that are delivered to us wrapped in an envelope. This constitutes a batch. Our receive pipeline splits the batch into its constituent records. We have a monitor orchestration that receives all records from a given batch by correlating on the BatchId. The monitor orchestration’s main purpose to is authorize the batch, submit the records back into the messagebox, and then wait for each \”worker\” orchestration to send a completion notification. Once all completion notifications have been received, the monitor orchestration flags the batch as complete and exits. It is important to mention that the batch monitor can’t know the specific type of messages that it receives from the batch. It’s only purpose is to authorize and monitor the completion of a batch.

Originally we wanted our worker orchestrations to have a port that would receive messages of a specific type (lets just call them WidgetA and WidgetB for now.) In order to make sure that the batch monitor receives the messages first, we created a filter on the receive shape of each worker that checks for an authorization flag. This stops the workers from picking up the messages at the same time as the batch monitor.

While working on the first version we came across a snag. As mentioned, in order for the worker orchestrations to pick up the records, the monitor orchestration has to set a promoted property on each record it receives, before submitting them to the message box. In the batch monitor orchestration, in order to set that specific promoted property, we have to create a new XmlDocument instance and assign the received message to it. Then we copy all the context properties (*) and finally set our \”authorization flag\” property to ‘true’.

The problem that we discovered was that doing this:

xmlDoc2 = xmlDocInput;
xmlDoc2(*) = xmlDocInput(*);
xmlDoc2(Routing.IsAuthorized) = true;

does not copy the BTS.MessageType property from the original input message. After giving it some thought this makes sense as BizTalk considers an XmlDocument to be untyped. Since the engine initializes the read-only MessageType property, xmlDoc2 doesn’t have a Message Type after the message assignment completes. Therefore, MessageType can’t be copied using (*) or direct assignment because it is read-only. The problem this creates though is that once the batch monitor submits the \”altered\” xmlDoc2 instance to the message box, we get a subscription error. This is due to the worker orchestration’s receive port being bound to a specific message type.

Since we couldn’t figure out a way around this, we ended up creating a multi-part message. The \”body\” part defines a Routing structure which contains a property \”ItemMessageType\”. Even though the batch monitor receives batch items as XmlDocuments, the original input message contains a valid BTS.MessageType (which was assigned by the XmlDasm in the pipeline.) The message type is copied into the our Routing.ItemMessageType property. The worker orchestrations were modified to receive our multipart message and the corresponding receive shapes modified to filter on Routing.ItemMessageType = \”specific message type\”.

The end result is that we have worker orchestrations with receive ports that receive messages of type RoutingType, instead of WidgetA or WidgetB. The orchestrations ensure that they receive their specific message types by applying a filter to the receive shape (i.e. Routing.ItemMessageType == \”http://schemas/WidgetA#WidgetA And Routing.IsAuthorized == true)

(continued below)