BRE Rules Evaluation in ESB Toolkit: Document Types Are Different than Expected

One thing that is incredibly useful about the use of an ESB Toolkit Itinerary is that decisions can be made at runtime regarding the routing of messages or selection of transformations to execute against messages.   For my projects, the most useful tool to facilitate this resolution has been the Business Rules Engine that comes with BizTalk.

When you use a BRE resolver, you have the option to select whether the Rules Engine will use only the context of the message you pass into the engine (the default setting) or you can have the Rules Engine use the content of the message as well by setting the useMsg attribute to true. 

I have not experienced any problems when using message context as evaluation criteria in my rules but until recently I have been unsuccessful in using the message content as part of  the evaluation criteria.  The trouble I had was that regardless of how I arranged the Facts in the Business Rule Composer, the evaluation always returned false and the rule never fired while processing the message.

This is truly a frustrating scenario.  Here is the error message you will  most often see (or something similar):

Error details: There was a failure executing the response(receive) pipeline: “Microsoft.Practices.ESB.Itinerary.Pipelines.ItinerarySendReceive, Microsoft.Practices.ESB.Itinerary.Pipelines, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35” Source: “ESB Dispatcher” Send Port: “YOUR_SENDPORT_NAME” URI: “YOUR_URI” Reason: Transport location could not be resolved from teh resolver string BRE:\\policy=YOUR_POLICY;version=;useMsg=true;messageFile=;recognizeMessageFormat=false;.


Fortunately I found this interesting tidbit: the Document Type that the Itinerary components send into the BRE is not what you expect.  Instead of the Document Type that shows up in the Rules Composer  when you select your fact from an XML schema (like the schema name, for example), it sends in Microsoft.Practices.ESB.ResolveProviderMessage instead.

So what do you do?

One work-around is to replace the Document Type attribute in the BRE Rule Composer from its default to Microsoft.Practices.ESB.ResolveProviderMessage.  This will allow the rules engine to recognize the document type and fire rules correctly as it processes the message . 

Here’s how: 

  1. Open the Business Rule Composer
  2. In the Facts explorer, select “XML Schema” and load whichever schemas you will need to work with.
  3. Select the schema name.  Note the Document Type property in the Properties Window.  It will be the same name as your schema.
  4. Change the Document Type property’s value to Microsoft.Practices.ESB.ResolveProviderMessage for each schema. 
  5. Drag-and-Drop nodes from the schema into the Conditions section as you normally do.  Note that the new type is represented with the XPath in your conditions.

When the rules execute, it should now be able to find the referenced nodes and evaluate your rules correctly.


About Ed Jones

Ed is a .NET and Integration architect for Avanade in the Twin Cities. Contact Ed

5 responses to “BRE Rules Evaluation in ESB Toolkit: Document Types Are Different than Expected”

  1. jahuso says :

    I’m using the message type as a condition to route the message, change the properties of the schemas does not change the rule behavior, any suggestion?

    • Ed Jones says :

      Difficult to tell without seeing the rule and the input doc. What results are you seeing when testing with the rule composer. Are the rules firing?

  2. Sachin Gupta says :

    Hi Ed, 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 run time no map map is returned and I get the error as “Reason: The map name was not provided and is required. “

    • Ed Jones says :

      Sounds like the message types are not lining up. Best bet is to take a look at the message just prior to going to the rules engine and see what the message type is and adjust the rule accordingly.

      • Sachin Gupta says :

        Hi Ed, I have tried almost everything that I could without any success, Now my focus is shifting towards the pipeline to use, I am currently using ItinerarySelectReceiveXml and this doesn’t seems to be parsing the message correctly. I even enabled the tracing for ESB Toolkit and found the following test in the Debugview window: [11364] DocType for typed xml document is Microsoft.Practices.ESB.ResolveProviderMessage. But still receive the error as “[11364] The map name was not provided and is required.”. Any help / clue on this appreciated.

What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: