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.
Looking for something?
- Temporal Data in a Relational Database
- Removing Empty Nodes from a Message using XSLT and the BizTalk Mapper
- BRE Rules Evaluation in ESB Toolkit: Document Types Are Different than Expected
- WCF: (400) Bad Request while Streaming Large Files through IIS
- Dynamic Map and Pipeline Execution in a BizTalk Orchestration: A Case Study
- Windows 9 unveiling set for September 30, report says cnet.co/1pO7VhI via @CNET 21 hours ago
- RT @edbott: People exercising First Amendment rights are so much more interesting than those exercising Second Amendment rights. 1 week ago
- I'm thinking about changing a few of my passwords. xkcd.com/936/ 1 week ago
- 51,338 Monkeys!