Click here to Skip to main content
14,040,625 members
Click here to Skip to main content
Add your own
alternative version


7 bookmarked
Posted 1 Dec 2011
Licenced CPOL

Dynamic Message Processing and Routing in Itineraries using BizTalk 2010 with Enterprise Service Bus Toolkit 2.1

, 8 Dec 2011
Rate this:
Please Sign up or sign in to vote.
The article attempts to explain to how to choose a BizTalk ESB Itinerary dynamically based on message content.

Are you New to BizTalk Enterprise Service Bus (ESB) 2.1 Toolkit?

Refer to my Hello ESB article which takes you on an introduction route.


In this article, you will learn how to use BRI to determine which Itinerary to attach to a message, based on the message contents. Here we are looking at the message contents and determining which Itinerary to attach for the message. You will also learn how to code an ESB complaint orchestration to consume messages from the ESB bus.

Problem Statement

How would you determine which Itinerary to attach to a Contact message by looking at its contents dynamically?

A CRM Contact is routed to either MS CRM system or a BlackBaud CRM system using Itineraries based on the ContactID (which is part of the message itself). A Contact is represented with the symbol 'C' and an Itinerary is represented with the symbol 'I'.


What are the Different Ways to Assign an Itinerary to an Incoming Message?

The 3 different ways to assign an Itinerary to a message are 'Advanced Service client', 'Adaptive Service Client'and 'Service Proxy'. The following notes explains them in further detail.

  1. Advanced Service Client: A client specifies the Itinerary in the WCF/SOAP header request itself.
  2. Adaptive Service Client: Client resolves Itinerary via resolver service and then sends it in a WCF/SOAP Header request.
  3. Service Proxy: Itinerary is resolved on the server’s ESB On-Ramp receiving port via configurable resolver.

NOTE that in this article, we are using the Service Proxy approach.

The Contact Message

The Contact XML message:

<ns0:Contact xmlns:ns0="http://ContactCanonical.Contact">
<address type="home">
      <street>707 Richmon Trl</street>

<address type="work">
      <street>2232 N Walnut Ave</street>
    <phone type="work">
    <phone type="home">

NOTE the ContactID in the Contact XML message.

Determining the Itinerary to Attach to the Contact Message

A policy and a set of rules is used to determine which Itinerary needs to be selected for the Contact message.

You would specify this policy in the ESB receive pipeline on the receive location. This would determine which Itinerary to use for the Contact message.

NOTE that any XML schema instance (XML document) that passes through the ESB must have the document type on Rule engine set to 'Microsoft.Practices.ESB.ResolverProviderMessage'. For additional information, please see the links in the references section.


Understanding the Itinerary

Note that there are two Itineraries (one for each CRM) in this example, but only one has been described here, since they are almost similar.

  1. ESB On-Ramp: An ESB on-ramp receives the Contact message.
  2. Orchestration Extender: The Contact message is consumed by the orchestration configured in the orchestration extender.
  3. Off-ramp extender: Notice the use of BRE extender. Note that this is a BRE and not BRI (which is used to select an Itinerary). Here BRE is used to set outbound properties. See the next section below.
  4. ESB Off-Ramp: The message is routed to a dynamic BizTalk Server send port, which is also referred to as an ESB off-ramp.

Understanding the BRE resolver in the Itinerary

The BRE resolver is used to retrieve the Outbound transport properties from the Business Rules Engine (BRE) policy. Observe the settings in the screen shot.


The data returned by the resolver contains the transport properties.


Steps to Develop a BizTalk ESB Compatible Orchestration

Step 1: Message Box Binding

A logical receive port, bound directly to the message box is required for receiving ESB messages. Notice the filter settings required for the activatable receive shape.


Step 2: Coding the Meat of the Orchestration

// Retrieve the current itinerary step.
itineraryWrapper = new Microsoft.Practices.ESB.Itinerary.SerializableItineraryWrapper();
itineraryStepWrapper = new Microsoft.Practices.ESB.

itineraryWrapper.Itinerary = Microsoft.Practices.ESB.
itineraryStepWrapper.ItineraryStep = 

hasNextService = itineraryWrapper.Itinerary.HasNextService();


The hasNextService flag is used to determine whether to send the message back to ESB bus for further Itinerary processing. In our example, if the flag is false, no message is placed on the ESB bus.

Step 3: Promoting the Correlation Properties of the Outgoing Message

A logical send port, bound directly to the message box is required for sending ESB messages. Notice the correlation properties required to be set for the send shape.


Step 4: esb.config Entries

Locate the esb.config under C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1, find the XML tag itineraryServices and add the following:

<itineraryService id="e2710ecc-1dcd-49e0-b6a0-fd318227d24c"
name="ContactOperation.ProcessMSCRMSubscription" stage="None"
scope="Orchestration" type="ContactOperation.ProcessMSCRMSubscription,
ContactOperation, Version=, Culture=neutral,
PublicKeyToken=2710b190689828fa" />

<itineraryService id="b506da17-126d-41b1-8bff-664a59e91570"
name="ContactOperation.ProcessBBAUDSubscription" stage="None"
scope="Orchestration" type="ContactOperation.ProcessBBAUDSubscription,
ContactOperation, Version=, Culture=neutral,
PublicKeyToken=2710b190689828fa" />


The use of BRI to resolve and attach an Itinerary to a message, by looking at the message contents. In the example, we have attached an Itinerary to the Contact message based on the value of the ContactID.

Downloadable Code

There is no code provided with this article, since this is left as an exercise for the developer.

References for Further Reading


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Naveen Karamchetti
Architect AT&T Wi-Fi Services
United States United States
Naveen has done his Masters (M.S.) in Computer science, has started his career programming the mainframes and now has more than a decade of programming, development and design experience. Naveen has a sharp eye and keen observation skills. Naveen has worked for several companies and strived hard to build large scale business applications and bringing better solutions to the table.
Quite recently Naveen has built a fairly complex integration platform for a large bank. His hobbies include training, mentoring and research. Naveen spends his free time visiting National Parks nationwide.

Naveen has developed the BizTalk Control Center (BCC)

You may also be interested in...


Comments and Discussions

QuestionNo source code for download attached Pin
sumeetec10527-May-15 5:03
membersumeetec10527-May-15 5:03 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Cookies | Terms of Use | Mobile
Web01 | 2.8.190425.1 | Last Updated 8 Dec 2011
Article Copyright 2011 by Naveen Karamchetti
Everything else Copyright © CodeProject, 1999-2019
Layout: fixed | fluid