Controlling where Maps are processed with BizTalk ESB 2.0
(Canonical Messaging Pattern)

While implementing some ESB patterns, my team and I at Tellago were tasked with purposely running a map after the message gets published to the Message Box. Which brings up the topic of this post. If you want to control where in the processing steps a map is transformed, let's say on the receiving side, or on the sending side, we can do this with the "Routing Slip" pattern for ESB aka Itineraries.

Before I get into how this is done, let me explain why you may need to do so. One reason could be you simply want to follow a Canonical Message Exchange Pattern. Where Endpoint specific messages are transformed into a common canonicalized format. A formart in which you control and process. After processing, you may need to transform the message back into an endpoint specific format that only the endpoint understands.

The way in which we accomplished this was to apply a Transformation service before after the publishing to the Message box. In ESB 2.0 itinerary design, a Transformation step is applied before the off ramp extender and another is applied after, which the post transformation step having its container set to the Send Port/Send Off Ramp as outlined in the following Itinerary design:



This design allows for a message to come into BizTalk using one format, then transformed into a canonical format, processed and routed to a subscribing endpoint. At which point in time the message gets published to the message box. Any subscribing endpoint would then receive a copy of this message and could further process the routing slip steps. How this works is that the Itinerary is promoted into the Message context for each message copy. You can also do other forms of processing, such as normal BizTalk processing like orchestrations or other send ports.

In order to continue processing the itinerary steps after the Off ramp extender, all you need is a component that understands the itinerary that can be found inside the message context. This could be a send port with a send pipeline which contains an ESB Dispatcher component. To process the steps inside a custom orchestration, use the ESB Itinerary Utility classes to get the current step. In anycase this pattern allows for multiple steps to occur after the message is published to the message box.


Happy ESB'ng