Partilhar via

ESB Toolkit How To Video #4: Dynamic Itinerary Resolution

  • Artigo

Update: After I posted this originally, I was notified that my video did not contain any audio! Therefore, it was probably difficult to understand what was going on :) I've recreated the video and replaced the old one so that the video and audio are both working. Cheers

Welcome to #4 in my series of ESB Toolkit How To Videos. Each of these videos has built up from the one before it, so if you have seen the previous videos, I encourage you to do so. In video #3 (found here), I showed you how to use the toolkits new "Itinerary Resolution" feature.  In that video, I showed you how to use the Static Itinerary Resolver within a BizTalk receive port to load up an itinerary from the itinerary database and attach it to an incoming message. To do this, we added a resolver configuration string to the pipeline such as "ITINERARY:\\name=DemoService;" (where DemoService was the itinerary that we wanted to load) One shortcoming of that solution is that had multiple itineraries you would need a different receive port for each one.  In a real world solution, you might want to assign an itinerary to a message based on the message's schema, or some piece of data found within the message or based on who sent it and you would want to do all of this with as few receive ports as possible.  Therefore, the ESB really needs to be able to dynamically and intelligently figure out what itinerary an incoming message needed with us having to hard code the name.

Fortunately, the ESB Toolkit provides us a flexible and intelligent way to resolve itineraries and this is the Business Rules Engine resolver. This allows us to the use the BizTalk Rules Engine to make a decision about what itinerary should be used. We can create rules to look at Context properties associate with the message (such as the message type, the sender etc) or we can look at the content within the message to make our decision on which itinerary to use. In this video, I'll show you how to create an BRE policy to resolve itineraries and I'll show you how to setup your BizTalk receive ports to use this policy. I'll show you how to implement context and content based itinerary resolution.

Here's the link to the video

Cheers and keep on BizTalking...

Peter

Comments

  • Anonymous
    June 17, 2009
    Hi, There appears to be no sound with the video. Which sound codec did you use.

  • Anonymous
    June 25, 2009
    Hi Peter, been watching your video series on esb - it has been extremely helpful in making the jump from v1 of ESB. I just have one clarification - when resolving itineraries from the pipeline using message content you can just use the normal fully qualified document type in the business rule, instead of Microsoft.Practices.Esb.ResolverProviderMessage. In order to this you need to add the attribute recognizeMessageFormat to the BRI resolver connection like this: BRI:\policy=MyIntinerary;useMsg=true;recognizeMessageFormat=true;

  • Anonymous
    July 24, 2009
    The comment has been removed

  • Anonymous
    July 25, 2009
    @GrantSamuels I tried your suggestion and I cannot seem to get this to work. If i take out the predicate that checks for the Level inside the document i can see the rule fires and always sets the "Composed" itinerary. Put it back in without chaning the Document Type, with adding that new attribute and it fails! I get an error about an Itinerary needs a parameter @name. Only assuming that the Fact that sets the name didn't fire.

  • Anonymous
    April 22, 2014
    Hi, In the rule composer the condition works just fine. I am using Context Message Type and one field from the message to resolve the map name. But in the run time no map map is returned and I get the error as “Reason: The map name was not provided and is required." I changed the Document Type as suggested in the BRE but in the run time while resolving the map, nothing is returned.