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.
- Click to email (Opens in new window)
- Share on Facebook (Opens in new window)
- Click to share on Twitter (Opens in new window)
- Click to print (Opens in new window)
- Click to share on Google+ (Opens in new window)
- Click to share on Pinterest (Opens in new window)
- Click to share on Reddit (Opens in new window)
- Click to share on Tumblr (Opens in new window)
- Click to share on Pocket (Opens in new window)
About Ed JonesEd is a .NET and Integration architect for Avanade in the Twin Cities. Contact Ed
Looking for something?
- Conditional Port Deployment Using the Deployment Framework for BizTalk (BTDF)
- Temporal Data in a Relational Database
- BRE Rules Evaluation in ESB Toolkit: Document Types Are Different than Expected
- BizTalk ESB Toolkit 2.0: Exception Management Gotchas--Create the Fault Message in the Right Place
- AppFabric Caching Tip: Watch Your Memory Usage
- RT @AddInfoOrg: Watch Arnold Schwarzenegger Take On Nazis And White Supremacists In Scathing New Video addictinginfo.com/2017/08/18/wat… 2 months ago
- Conditional Port Deployment Using the Deployment Framework for BizTalk (BTDF) talentedmonkeys.wordpress.com/2017/02/17/con… 8 months ago
- Neil deGrasse Tyson: U.S. science illiteracy a serious threat greensboro.com/news/schools/n… via @NewsandRecord 8 months ago
- 76,176 Monkeys!