How to survive the XmlDisassembler

22 April 2011

The XmlDisassembler pipeline component in BizTalk Server basically does three things:

  1. promoting properties (including the message type)
  2. validating incoming documents (if turned on)
  3. disassemble batches into body messages

Sometimes situations can occur where you want to process an envelope message but you don’t want to have it disassembled into separate body messages.

For example when receiving a message that contains a lot of data in the header of the envelope that is needed in the body of a message further on in the process. You then ideally want to use a map to copy over this header data into another message. If the port receiving this message uses the XmlDisassembler component the envelope will be processed and the header information is “gone”.

You can of course promote everything in the header to the context but that leads to a lot of data in the context. Besides that a considerable amount of code (distinguished fields and xpath statements in expression shapes) is needed to get the context properties into the message later on.

Another and, in my view, more elegant way to do this is by setting the value of a special property to true on the context of the envelope message before it is processed by the XmlDisassembler. The property is called ‘PromotePropertiesOnly’ and resides in the ‘http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties’ namespace.

A very simple pipeline component can be used to do this:

public IBaseMessage Execute(IPipelineContext pContext, IBaseMessage pInMsg)
{
pInMsg.Context.Promote("PromotePropertiesOnly",
"http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties", true);

return pInMsg;
}

After setting this property will still have the functionality of the XmlDisassembler (like property promotion, setting the message type, etc.) but the debatching is skipped.

The property is available and can be used in all versions of BizTalk Server (2004, 2006 (R2), 2009 and 2010).


Was promoted

15 June 2009

Ever wanted to know in a send pipeline if a property was promoted before? The BizTalk API comes with an object called ‘ContextPropertyType’ which you can use for this purpose.

I have a very simple schema and corresponding instance:

waspromoted_schema

waspromoted_schema_instance

Above message travels through BizTalk using the following path:

receive port -> orchestration -> send port

I defined the ‘Firstname’ element as promoted property to have it promoted by the out-of-the-box XmlReceive pipeline. After that the message is sent to the message box and picked up by the orchestration to do some processing. Next the orchestration will send the message to the message box again using a send shape. Finally the send port picks up the message and sends it to some URI using an adapter.

In the send port I used a custom pipeline containing a pipeline component with this code:

waspromoted_code

 After the message has been picked up by the send port the messaging engine will alter the context of the message. The ‘Firstname’ element that was promoted before is not promoted anymore now. To prove this I call the IsPromoted method for the specific property (see code above).

So what if you want to know if the property was promoted before? This is where the ContextPropertyType object comes in. Together with the ‘GetPropertyType’ method on the context object I’m able to find the status of the property.

Running this example shows the following output in DebugView:

waspromoted_debug_view

 As you can see the PropertyType has a value equal to ContextPropertyType.WasPromoted. In the above sample I used an orchestration in the middle but the same will also apply to messaging only scenarios.

Although I recently made use of this API while implementing a very simple repair and resubmit feature, there might not be so many real world scenarios where one would use this. At least I couldn’t think of many. (Suggestion? Ping me, please.).  Also be aware that is an undocumented feature for which the BizTalk help states it is for internal use only. This basically means Microsoft will not guarantee any backward compatibility for this when new versions or SPs are released.


Follow

Get every new post delivered to your Inbox.