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:

The Messaging engine failed to process a message submitted by adapter:YOUR_ADAPTER. Details:The published message could not be routed because no subscribers were found. This error occurs if the subscribing orchestration or send port has not been enlisted, or if some of the message properties necessary for subscription evaluation have not been promoted. Please use the Biztalk Administration console to troubleshoot this failure.

 

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!

About these ads

Tags: , , , , , , , ,

About Ed Jones

Ed is a Connected Systems and .NET Specialist for RBA in the Twin Cities. Contact Ed

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 369 other followers

%d bloggers like this: