Itinerary Pipelines and Losing BTS.MessageType Promotions
Part of the appeal of using an ESB architecture is that we can create a loosely-coupled system where such contractual data as a Message Type doesn’t have to matter at all. But at some point, even the most loosely-coupled architecture must define a physical implementation.
In the ESB toolkit, this activity takes place within specialized pipeline components. These components perform such actions as loading itineraries, advancing a message through an itinerary, making routing decisions, and executing transformations. It gains flexibility by using tools such as BRE and UDDI to resolve locations, select maps, etc. You get the idea.
And almost everything is done in a pipeline.
In an inbound pipeline like ItinerarySendReceive, for example, properties such as BTS.MessageType get promoted in the XmlDisassembler in Stage Two of the pipeline. But it is in Stage Three where the ESB Toolkit’s Transformation service is invoked. Transformations, of course, usually result in a change in MessageType. This is where there may be a problem and a possible bug in the component. When the message changes, the BTS.MessageType property changes to the correct type as it is supposed to, but the property is no longer promoted.
Most of the time, especially in pure messaging scenarios, this isn’t an issue. But orchestration is one area in BizTalk where Message Type does matter most of the time. In fact, the message type is a key part of subscriptions that are used to activate an orchestration!
Here’s a sample itinerary that presents a problem:
Note that this itinerary ends with an orchestration that is immediately preceded by a transform. In this example, the orchestration may not get activated because the MessageType portion of its subscription is not satisifed. The message is suspended with the following (familiar) exception:
Fortunately, there’s a work-around that you can use to get past this hurdle. Simply using a generic XmlDocument object as your inbound message will solve this issue because all messages in the BizTalk Message Box are of this type. You’ll need to take obvious caution here–make sure the filter expression on your orchestration is well-defined enough so that it doesn’t attempt to process unwanted messages. Orchestrations used by ESB Toolkit Itineraries will have subscriptions based on ServiceName, ServiceState, ServiceType, and IsRequestResponse so this is often not an issue. Another cautious step to take will be to assign the XmlDocument to a message of the desired type early in the orchestration to avoid other type-related issues in processing.
Good Luck!
