Blog, Peter Kelcey, Peter, Kelcey, BizTalk, ESB, ESBT, ESB Toolkit, SOA, RFID, B2B, Azure, .NET Services, Canada
Welcome to MSDN Blogs Sign in | Join | Help

Connected Systems in the Great White North

Peter Kelcey's blog about Connected Systems and all the fun technology that entails. Focused on SOA, ESB, Cloud Integration, Modelling, B2B and RFID in Canada.
ESB Toolkit How To Video #4: Dynamic Itinerary Resolution

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

Posted: Wednesday, June 17, 2009 11:37 AM by pkelcey

Comments

olof said:

Hi,

There appears to be no sound with the video. Which sound codec did you use.

# June 17, 2009 9:51 PM

GrantSamuels said:

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;

# June 25, 2009 6:47 PM

ryancrawcour said:

Hi Peter,

Excellent series of videos

I worked through this one step by step and I was wondering how you manage to workaround the problem InfoPath seems to have with xs:any.

You showed another prebuilt receive location, was this one using the acutal document type by any chance?

I can get it to work when i do that, but that's a hack because i then don't have this Generic Onramp which is meant to be our goal.

Any help on this would be greatly appreciated.

Thanks

# July 25, 2009 6:27 AM

ryancrawcour said:

@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.

# July 26, 2009 1:16 AM
Anonymous comments are disabled
Page view tracker