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 this to a friend (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)
Looking for something?
- Temporal Data in a Relational Database
- Manual BizTalk Deployments and Assembly Version Mismatches
- BRE Rules Evaluation in ESB Toolkit: Document Types Are Different than Expected
- AppFabric Caching Tip: Watch Your Memory Usage
- Another ESB Toolkit Itinerary Gotcha: Be Sure to Correctly Set IsRequestResponse on Off-Ramp Extenders
- RyuJIT Bug Advisory in the .NET Framework 4.6 - .NET Blog - Site Home - MSDN Blogs blogs.msdn.com/b/dotnet/archi… 17 hours ago
- AppFabric Support Ends in April 2016 wp.me/pPRXE-ws 2 months ago
- All great software development is fueled by coffee. m.cariboucoffee.com/mobileapp 3 months ago
- 61,916 Monkeys!