Dynamic Itinerary Resolution (ESB toolkit 2.0/2.1)

If you ever had a situation where you needed to attach an itinerary to your message dynamically, ESB toolkit just allows you to do that.

I recently worked on a project that involved various stages (which each stage having >1 orchestrations) and depending on the content of the message, it would get thrown out to a sharepoint portal for business exceptions. The support staff could then view the message, fix the contents of the message via infopath and resubmit the message into BizTalk. However, since there was a common entry point for all the messages into BizTalk, I needed a mechanism to dynamically attach the correct itinerary to the message depending on the progression made by that message just before it was thrown to Sharepoint. This is where the ESB toolkit comes in.

The ESB toolkit installs some receive and send pipelines which are designed for itineraries. One such receive pipeline is called ‘ItinerarySelectReceiveXml’ pipeline. This pipeline allows you to specify a BRI (not BRE) policy to determine which itinerary to use.

I created a file receive port and defined a new file location as under:

You can view the properties of this pipeline by clicking the button next the pipeline. Here you can set the fact key and the resolver connection string to point to your BRI policy.

The two important properties to set are:
ItineraryFactKey: The key in the dictionary returned by the resolver that contains the actual XML of the Itinerary selected. In most cases, it should be set to ‘Resolver.Itinerary’, unless a custom resolver is used.

ResolverConnectionString: Connection string to the itinerary that should be attached to the incoming message. This is a resolver connection string that contains name-value pairs that a resolver can use to select and/or look-up an itinerary. This in turn executes either the Static or Business Rules resolver, which provides an itinerary name (and version number). The ESB Itinerary Selector component then uses this name and version information to load the requested itinerary from the itinerary database.

Example ResolverConnectionString:
ITINERARY:\\name=MyItineraryName;
BRI:\\policy=MyPolicy;version=1.0;useMsg=True;

Name: The name of the itinerary to use.
Policy: In case the business rules engine is used to set the itinerary, the policy name is set here.
Version: Version of your policy to use. if this is left blank, the BRI engine uses the latest policy deployed.
useMsg: Set this to true if you need to pass the context of the message to the business rules engine (for content based routing).

Once these properties are set, you need to create and deploy a policy in the business rules composer. One of the rules in my policy is shown under:

My message stages would be something like:
Stage1
Stage2
Stage3
Stage4

Once this policy is deployed, it will be called by the pipeline and the message passed through.

Basically what I have done is first checked the target namespace and ensured that it matched the namespace of the message I was expecting. The second condition was to check if the message was thrown out to Sharepoint from one of the stages in this itinerary. I wanted that itinerary to be attached to this message only if the message dint go through all the stages in that itinerary. Once the message goes through the last stage in this itinerary, the messagestage it set to something like “PhaseAProcessed” thus not meeting the above conditions for this itinerary.

You can create similar rules in your policy to match certain stages and attach the relevant itineraries.

Thats about it. You can now throw a message in your receive location and the correct itinerary will be attached to your message based on the content.