Handling message enrichment with Business Rule Engine

One common thing that we need to handle at an integration level is enrichment of messages, this is often due to missing information in the incoming message or requirements of additional static data. This could be static hard coded data or more advanced rules that consists of several parameters. And the actions might as well be simple static data or more complex handling of adding nodes and elements. The values might change over instances (i.e. different values in Test and production). By using the Business Rule Engine (from now called BRE) we can create a solution with very high maintainability with good tools and support for change both input parameters to the rule and actions taken when the rule is executed without changing any source code or do any redeployment. This is made due to using standard components with minimal links, the only link is the name of the policy which we need to specify when we call the BRE rule engine from our pipeline or orchestration.

So basics first what is the BRE engine? It’s a rule engine and with that said you basically put in rules that turn into true or false and when the result is true there is an action executed. These actions can be quite flexible and can be used to add new elements, records or attributes or just simply set a value to one or more existing attributes or elements.

Now how and where do we use it? Well the places where enrichment is natural is the following, when received by BizTalk before inbound map, inside orchestration or when leaving BizTalk after outbound map (see picture). This possible execution places is receive-, send-pipeline or orchestration and to be able to do that we need some pipeline components and orchestration shapes. There are a great framework for working with BRE called “BizTalk Business Rules Engine Pipeline Framework

So let’s take an exampel:

I have this message received and the sending system cannot provide the field “MinChef”


Let’s say that the rule will be following: If company code is 9999 then we add the following static information:


Small and easy, also very flexible since adding or changing information like this is not forcing or demanding a recompilation or redeploy. Just add a new version of the policy and deploy and the change is done. There are possibilities to do more complex functions as well, check this example where we add a node and records under the node.  (It might look complex but the tool will help you fill in the information.

Installing and configuring BRE rules engine och BRE pipeline Framework. So basically BRE is shipped with BizTalk so it’s probably installed or you need to run the BizTalk installer. Install he BRE pipeline Framework download here and install.

Tips and tricks regarding BRE:

If you need the possibility to run the added .net functions and libraries we need to change a value in the registry accordingly:


Add the following parameter: Name: StaticSupport Type: REG_DWORD Value: 2


If you create a pipeline from the pipeline component we need to add a new policy a “InstructorLoaderPolicy” that will check the message root node text and if it’s a match it will initiate and set a BRE pipeline context value.

The pipeline will then look like this:

Where the TestManager is the policy where the manipulation of the message is happening and the InstructorLoaderPolicy is the meta data policy that helps loading meta data like message type to the BRE engine.


We can easily add static data this way and prevent from hard coding it into maps but It needs to be planed and designed for since there are limited places where the enrichment can be done. The enrichment that the components are doing is adding data or performing functions to the message and return the result and the result will be the message that BizTalk continues to work with, but I’ll give you an advice to keep this as isolated as you can since it will fast grow quite complex. Otherwise by using this pattern we can create better and more maintainable solutions where changes to the static data are made simply by updating these rules rather than code and redeploy solutions, witch is a very time consuming task. This also gives the developer more time to spend on developing and other fun stuffs rather than change static data that the business suddenly had to change for any good reason.

Posted in: •Integration  | Tagged: •BizTalk  •BizTalk Business Rules Engine Pipeline Framework  •BRE  •BRE Pipeline Framework  •Business Rule Engine  •Maintainability  •Tips & Trix