In this Blog, I am going to talk about using Itineraries in BizTalk Server 2009 ESB Toolkit 2.0 to achieve business functionality. Itineraries are relatively new concept to BizTalk server having been introduced with BTS 2006. With BTS 2009, Microsoft took it to new level altogether by introducing new components and a designer itself to create them using Visual Studio 2008. If you have followed the instructions in my previous blog, then Visual Studio will provide you with an Itinerary Designer to allow you to create them visually instead of hardcoding the XML.

So, What is an Itinerary? Why do we need them? What do they provide that BizTalk doesn't already provide out of the Box???

Well, An Itinerary is a small snippet of XML string that tracks the trajectory of the 'Message' as it traverses through the BizTalk Engine, and also telling it what components to use once it enters the BizTalk Environment!!! Typically, an Itinerary will have an On-Ramp component(this is where the message enters the BizTalk Message Box), an Off-Ramp(this acts as a send port, subscribing to the message using various filters) and a bunch of Itinerary Services chained together. These services will carry the instructions to process the message, telling it what BizTalk components (Orchestration, Messaging Pipeline, Business Rules Engine) to use to achieve the desired result.

For example, an Itinerary Service will have plethora of properties associated with it, which you could configure(at runtime) to tell it what BizTalk component to use. You could configure 'Itinerary Service Extender' propery to either 'Orchestration Extender', 'Messaging Extender' or an 'Off-Ramp Extender'. An Orchestration Extender will allow you to call a pre-Existing Orchestration in the BizTalk Engine. A Messaging Extender will allow you to 'Transform' the message using BizTalk maps or 'Route' it to various locations using BizTalk Adapters and 'Trasport Locations'. And an Off-Ramp extender will ofcourse allow you to specify a dynamic send port that subscribes to the message and forward this message to the subscribing send port for further processing.

Each of these 'Itinerary Services' will have resolvers which actually contain the instructions. An On-Ramp and Off-Ramp will have 'Receive and Send Handlers' that allow you to process the message in the 'Receive' or 'Send' Pipelines respectively.

I am going to include a series of articles in the following blog posts that would give you a complete idea as to how to make the best use of Itineraries to achieve your business functionality. If time permits, I am also planning to include few videos too...

So, Why do we need Itineraries at all?

The reason behind using Itineraries or Enterprise Service Bus(ESB) for that matter, is that it would allow you to build loosely coupled dynamic applications. BizTalk Applications traditionally relied on a 'Centralized Routing Engine' that would make the decisions where to 'Route' the message, what 'Transformations' to apply etc., You would manually create Receive Ports, Receive Locations, Send Ports and configure their filters to subscribe to incomming messages. It makes use of various pluggable components like Maps, Pipelines, Orchestrations all of which are developed and configured during design time. Ofcoruse, you could change the configurations during run-time but there is very little flexibility.

With the help of Itineraries, a whole new functionality is provided to BizTalk that didn't exist before. You could actually attach a 'Routing-Slip' to the incomming message telling the BizTalk Engine what to do. It would contain all the instructions telling what ports to route the message, what maps to call, or even execute a .NET code... The Message itself carries instructions in it's header (XML format), there by allowing the clients/developers to change the instructions dynamically on the fly without ever touching any of the BizTalk components. If you think it's unsafe to give the clients an Itinerary, no problem. Just store the Itinerary in the 'DataStore' and use the 'Business Rules Engine' to pull the appropriate Itinerary and attach it to the message as soon as it enters the BizTalk Engine.

 

What does a typical Itinerary look like? Here it is :