Here’s a topic that, without any particular reason, I rarely covered on my blog: Business Rules Engine (BRE).
This post won’t teach BRE from scratch. However, since this is my first time writing about it, I want to start with a short introduction and a few practical notes.
📝 One-Minute Brief
BRE lets you externalize business logic into policies and reuse it across BizTalk solutions. In this post, I explain what BRE is, why teams often misunderstand it, and why migrating policies from BizTalk 2006 R2 to BizTalk 2013 R2 is usually straightforward.
Business Rules Engine (BRE): what it is
BRE is a runtime inference engine. It evaluates rules against “facts” and triggers actions based on the result. In BizTalk, those facts can come from:
- .NET objects
- XML documents
- Database tables
BizTalk includes BRE as an optional component. It lets teams create and manage business decision logic as rules, grouped into policies.
Since BizTalk Server 2004, Microsoft has delivered BRE as part of the Business Rules Framework, which includes several modules and tools.
Main components of the Business Rules Framework
The primary modules include:
- Business Rule Composer is a graphical user interface that enables developers, business analysts, and administrators to construct vocabularies and policies.
- Rule Engine Deployment Wizard for export, import, deploy, or undeploy vocabularies and/or policies created in the Business Rule Composer.
- The Run-Time Business Rule Engine executes policies on behalf of a host application.
Why people misunderstand BRE (my take)
In my opinion, BRE is one of the most misunderstood BizTalk components—only BAM confuses people more.
Microsoft originally aimed Business Rule Composer at business analysts. The idea was simple:
- Business owners define and update rules,
- Developers keep code stable,
- BizTalk orchestrations reuse policies to decide process paths.
In practice, that vision rarely comes to pass.
What goes wrong
Business Rule Composer feels unfriendly for most business analysts. The UI and concepts create friction. As a result:
- Developers end up creating the rules, and
- Administrators end up maintaining them.
This creates a second problem. Developers prefer Visual Studio, and admins prefer the BizTalk Admin Console. BRE sits outside both. On top of that, the terminology confuses many teams: vocabularies, rules, and policies don’t feel natural at first.
Why BRE still matters
BRE hasn’t changed radically since 2004. Even so, it remains powerful.
For example, Ricardo Torre, in his series about BizTalk Server Tips, highlighted two strong points:
- BRE evaluates rules at high performance, even compared with WF rules.
- BRE helps you modularize business logic that changes often. You can update a policy version without downtime in many scenarios.
In fact, the most common application of BRE is to isolate business rules, in a centralized manner, from the BizTalk applications, making it eminently reusable in a simple and efficient manner. But what many people don’t realize is that we can do many more things with it, for example:
- BRE can be used to store configuration data (or Application configurations), using a vocabulary, which is essentially parameters, or friendly names for the facts, that can be used within the execution of a rules policy. However, the vocabularies can also be accessed from C# code, and they can be a wonderful way to abstract facts from their implementation.
- The Rule Engine Config Get Functoid, available in the BizTalk Mapper Extensions UtilityPack, allows you to obtain a definition value from a Vocabulary in the Business Rules Engine to be used inside your maps.
Before we get to the purpose of this post, let me mention a particular note: Normally, we have policies that consume vocabularies to generate rules; however:
- We can have simple vocabularies that are not consumed by any policy
- Or we can have simple policies that don’t consume any vocabulary
This week, I have the necessary skills to migrate a simple policy (without any vocabulary) from an old version of BizTalk (2006 R2) to BizTalk Server 2013 R2. So what is necessary to migrate these artifacts? Do I need to recreate everything, or are they compatible?
How to migrate Business Rules Policies from BizTalk Server 2006/2006 R2 to BizTalk Server 2013 R2
Well, as I mentioned earlier in this post, BRE hasn’t suffered any radical changes since 2004; therefore, this is a very simple task to be accomplished. For that, you just need to use the Rules Engine Deployment Wizard tool to import from your older environment and export them into your new environment.
Exporting policy from BizTalk Server 2006/2006 R2:
- Click Start > Programs > Microsoft BizTalk Server 2006, and then click Business Rules Engine Deployment Wizard.
- On the Welcome to the Rules Engine Deployment Wizard page, click Next.
- On the Deployment Task page, select the Export Policy/Vocabulary to file from database option, and then click Next.
- On the Policy Store page, from the drop-down lists, select an available SQL Server computer and database, and then click Next.
- On the Export Policy/Vocabulary page:
- Select the Policy option.
- From the Policy/Vocabulary drop-down list, select the desired policy you want to export.
- Click Browse to select the definition file path and name.
- And then click Next.
- On the Ready page, review the information, and then click Next.
- On the Exporting Policy/Vocabulary page, after the export is completed, click Next.
- On the Completing the Rules Engine Deployment Wizard page, review the completion status, and then click Finish.
Importing a policy to BizTalk Server 2013 R2:
- In the BizTalk Server machine, press the Windows key to switch to the Start screen, type Business Rules Engine Deployment Wizard or rules, and then click the Business Rules Engine Deployment Wizard option from the Search menu.
- On the Welcome to the Rules Engine Deployment Wizard page, click Next.
- On the Deployment Task page, select the Import and publish Policy/Vocabulary to the database from file option, and then click Next.
- On the Policy Store page, from the drop-down lists, select an available SQL Server computer and database, and then click Next.
- On the Import Rules Engine Policy/Vocabulary file page:
- Click Browse to select the definition file that we previous export from BizTalk Server 2006/2006 R2.
- And then click Next.
- On the Ready page, review the information, and then click Next.
- On the Importing Policy/Vocabulary page, after the import is completed, click Next.
- On the Completing the Rules Engine Deployment Wizard page, review the completion status, and then click Finish.
Now, if we access to the Business Rule Composer, you will notice that your policy is published and ready to be deployed.
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.
I have done the following steps but now am getting an error as A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server)