Resolving Multiple Maps in Sequence with the Busines Rules Engine in BizTalk ESB Toolkit 2.0

One of the nicest thing of the BizTalk ESB Toolkit 2.0 is the concept of Resolvers that allow you to implement dynamic routing and dynamic transformation in you data exchange scenarios.

A few weeks ago, Jeremie was working on implementing several exchange patterns around an itinerary-based approach which consists in executing multiple transformations of the incoming message in sequence, based on the contents of the message itself. He then set out to use the Business Rules Engine Resolver.

A first map was used to transform the incoming message to a canonical representation. A second map, depending upon the contents of the resulting canonical message was used to perform the appropriate transformation for the specific scenario at stake.

However, no matter how he tried, the second map would never be executed at all and the exchange would fail systematically with the following error message:

The map name was not provided and is required.

I then set out to try this scenario myself and lo an behold, it definitely did not work as expected. Clearly frustrated, I though time was come for a little investigation.

Meeting Microsoft.Practices.ESB.ResolveProviderMessage

In fact, the very first map is always successfully resolved. The problem comes with the second map, and possibly subsequent maps, in the itinerary. What gives?

Therefore, I quickly wrote a custom Business Rules Engine Resolver, in order to incorporate interception of rules engine execution and observed the results.

In the trace log above, you can clearly see the reason why the map is failing in the second case. It turns out the the type of the incoming message is mistakenly determined to be Microsoft.Practices.ESB.ResolveProviderMessage.

I don’t know if this is a bug or simply a side-effect of how the ESB Toolkit 2.0 is designed. In fact, as far as I know, this behaviour has always been the same in the previous version, then known as ESB Guidance.

What makes this behaviour frustrating is that you need to designed your policies with this in mind. In fact this makes it impossible for your rules to be agnostic to whether they will be called as part of the first messaging service in the itinerary of as part of subsequent services.

Anyway, once you know this, you have made sensible progress towards a solution…

This entry was posted in BizTalk ESB Toolkit 2.0. Bookmark the permalink.