ESB Itinerary Broker Filters

Biztalk's Itinerary Broker Filters are a great example of what Biztalk development is about. Start off with a business process and throw out any ideas of how you'd implement it in the normal world and massage, squeeze it into the Biztalk way of doing things.

Let's start off with how to get started with this component.
Drag the Itinerary Broker Service onto your design surface and configure it with these properties:

• Container - your onramp
• Itinerary Service Extender - Messaging Broker|Messaging Broker Extender
• Service Name - Microsoft.Practices.ESB.Itinerary.Services.Broker.MessagingBroker

In my usage I'll be creating filters to route a file to different offramps based on what type of file output I need.

For each resolver, set the resolver implementation to CONTEXT. You may see other options but don't get fancy and try to use anything else because it won't work.

Add a filter and choose XPATH for the filter implementation. In the expression set your xpath expression.

Drag an Itinerary Broker Outport and drop it onto the Itinerary Broker Service. Configure the Outport to match up a filter and a resolver.

This is a review of the basic steps to configure the Itinerary Broker Service and you could have worked this out from Microsoft's documentation. The tricky part is setting a filter expression that works.

To solve this for the use case I just mentioned, I created a schema property called OutputDoctype and promoted it during the Onramp. I start up Debugview and drop an instance of my message and Debugview will spit out a bunch of properties like so:

Grab the schema property you're interested in and put it into your favourite xml editor and craft an xpath expression against it. In my case it is:

count(//Property[@name='OutputDocType' and @namespace='https://?????.Outbound.Internal.???'][contains(., 'EDI')]) > 0

Put this into your Itinerary Broker Service filter and you should be good to go. Your XPath expression must use Xpath 1.0 and it must return a True to fire. This is why the above expression uses xsl:count()>0 rather than xsl:exists().

You may think that another way of getting the correct xml to craft an xpath expression could be to suspend a message and save the context to filesystem. The xml looks similar but it's not the same and you won't be able to craft an xpath against this.

Another thing to note is that you only need to write the properties to context and it's not needed to promote them. Itinerary Broker Service does not work with any other data sources/types such as message content. They must be context properties.