Performing Context-Based Routing after an Orchestration with BizTalk ESB Toolkit 2.0
In last week’s post, I described a simple snippet of code that can be used in a custom pipeline component in order to inspect the contents of an XML message and determine its MessageType. Today, I will show how this helped me solve one little problem with the BizTalk ESB Toolkit 2.0.
In a recent project we have made extensive use of the BizTalk ESB Toolkit 2.0 to take advantage of dynamic routing and transformation in our implementation of web services.
As part of this project, I found myself making systematic use of the Business Rules Engine resolver to determine what transformations to use at each step of the Itinerary. The rules where based on the context or the content of the message. Although there might be some issues to take into account when using this approach, this allowed us to leverage a single consistent exchange pattern in one Itinerary for different web services.
In certain cases, however, there was a need to resort to an orchestration for specific requirements. I took one of the samples as a starting point and quickly got an ESB Toolkit 2.0 compliant orchestration to be used in an Itinerary. However, I still clearly had some issues making the Business Rules Engine Resolver to actually resolve transformations designed to be executed after the orchestration in the Itinerary.
In the Itinerary illustrated above, a request is first received, that needs to be mapped to a canonical representation published to the MessageBox. A subscribing orchestration receives the canonical message and performs any appropriate action. In return, the orchestration drops a internal response to the MessageBox. Eventually, this internal response needs to be mapped to the format expected by the caller.
In this scenario, the first and second transformations are determined at runtime, based upon the context of the message, using the Business Rules Engine.
First, it is important to notice that since we’re trying to have the resulting transformation executed as part of the On-Ramp Send Handler, it is necessary to change the default PassThruTransmit pipeline to an Itinerary-aware pipeline in the WCF receive location, that is, one that contains the ESB Dispatcher pipeline component such as the ItinerarySendPassthrough.
However, I found myself unable to make the Business Rules Engine successfully resolve the second transformation. For some reason, I kept hitting the now familiar error message:
For some reason, at this specific point in the Itinerary, the Business Rules Engine does not recognize the message type, which it should given the circumstances.
After careful investigation and a bit of source code perusing thanks to Reflector, I observed that one of the very first steps the ESB Dispatcher component is taking is to perform some processing based upong the type of the incoming message, as well as the strong name of its schema.
My initial attempt was to make sure to promote the appropriate context properties when leaving the orchestration, by initializing and appropriately configured Correlation on the last Send shape. However, this did not result in the context properties being promoted when the message reached the ESB Dispatcher pipeline component in the response pipeline.
I still have not been able to figure out why, but I clearly had to find some other solution.
An Itinerary Transmit Passthru Pipeline
Therefore, I thought of creating a custom Itinerary Transmit Passthru pipeline in order to force the promotion of the MessageType context property before handing the message down to the ESB Dispatcher.
By putting the snippet of code we saw in the previous post in a custom MessageTypePromoter pipeline component, the configuration of said pipeline looks like this:
The goal of this pipeline is to determine and promote the MessageType context property, as well as the associated SchemaStrongName property that is used as part of the Business Rules Engine Resolver logic. The following step consists in using the Itinerary-aware ESB Dispatcher component to carry out the execution of the Transformation messaging service as configured by the Itinerary.
The MessageType context property is most useful for Context-Based Routing, whereas the SchemaStrongName property is useful for Content-Base Routing. Both of these properties are used as part of the Business Rules Engine Resolver processing.
In the BizTalk Server Administration console, this pipeline is associated with the Send Handler of the original Receive Location.
With this custom pipeline, running our service now works correctly, with the second transformation being resolved appropriately by the Business Rules Engine Resolver.
In the next article, I will describe the full source code for the MessageTypePromoter custom pipeline component.