Infosys Microsoft Alliance and Solutions blog

« Vista RTM | Main | Visual Studio 2005 and SQL 2005 on Vista RTM »

BizTalk BRE - Is it true Business Users Rules Engine?

I have been working with BizTalk for a while now and one question that I always have for the BizTalk's Business Rules Engine (BRE) is, is this really a true business user's tool? My take is, it is not and probably that is why it is called Business rules engine and not Business Users Rules Engine !

Without really getting into comparison with other Rules based tools available out there, I want to focus more on what a business user will want and does BRE offers all that. The primary need for business users if obviously to be able to create, edit, delete rules. Once a rule is created they may also want to temporarily disable the rule for some duration. While BRE, does offers these features, it is the way in which they are offered that makes it more of a developer tool than a business user tool. Lets take a few key features of BRE and discuss about them below.

Vocabularies, that make building rules easier, is a great feature to have. But vocabularies can't really be created by business users easily. They will need to be built by a developer who know the various .net components, their get/set methods, know the XML schemas and understand them, know the DB schemas and know which table/column to look for, for the data etc. Given that someone has built these vocabularies, a business user might be able to create policies with them.

This brings us to the policy creation editor. Business users with some training can probably make use of this to build the necessary rules. However things that make it complex are the right XPATHs, priorities of rules execution, agenda updates, assertions etc . Additionally, vocabularies once built and deployed become immutable and hence making changes to them becomes difficult. Refer to my earlier blog where I had talked about one way of doing this.

Consider a business case where say discounts are being offered based on seasons. Everytime the season changes, the discounts need to be changed to the one applicable for that season. A business user will be more interested in say enabling the season specific discount and disable other or be able to quickly modify the % discount and reapply the rule.

If we take the case of enable/disable, in BRE perspective, this could mean a different policy for each season, but this has issues since the calling orchestartion will need to be modified everytime a particular policy needs to be disabled and another enabled. This could be handled via another wrapper policy that calls the right policy internally. See policy chaining sample here. We also selectively enable disable different versions of the same policy.

For the other option of modifying just the %, it isn't straighforward in BRE and would typically mean creating and deploying new versions. Versions is a concept that works well with developers, but not with business users. With my own OOP development background, I am used to base class and inherited class and inherited class having similar features as base class and it can extend them further. Though versioning in BRE isn't a direct parallel, but consider why would someone create a new policy version. Since policies once published are immutable, to make any changes to them, one needs to have new versions. One can argue that the need could also be to write new rules, but then why reuse the same policy name. I would typically create a new policy for writing new rules and work with new sets of facts and vocabularies, possibly.

So given that I create new version for rule updates, it is surprising that this isn't the default behavior of BRE. When I create a new version for a policy, it is blank and I need to explicitly copy and paste old rules to it and then start modifying it. My take is that this should have been the default behavior.

Things aren't all bad also. With a little tweaking and thought, one can build upon BRE to meet some of the needs. I earlier used an example of enable/disable season based policy. One way this can be done is as below

1. Start by creating a policy (along with necessary vocabularies) for a particular season and set appropriate discount %.
2. Save and Publish this.
3. Create a new version and change the discount % as appropriate for another season.
4. Repeat the steps till you create as many versions as you want for the various seasonal discounts.

Now based on the current season, you can deploy a particular version and undeploy another. It is definitely possible to undeploy version 1.4 and deploy and earlier 1.1 version via BRE. The tricky part is that the identification will have to be done based on version 1.0, 1.1 etc, which is not that business user friendly representation. Since BRE can be invoked via custom code, you can display these versions using more meaningful names in your custom application and business users can then easily enable/disable usign more meaningful names like Autumn, Spring, Winter etc. Code like following is what you use to query the Rule store and deploy/undeploy specific versions. In the code these will be using explicit version numbers, but on the UI, you can show more user friendly names.

            RuleSetDeploymentDriver dd = new RuleSetDeploymentDriver();

            RuleStore sql = dd.GetRuleStore();

            RuleSetInfoCollection rlColl = new RuleSetInfoCollection();
            rlColl = sql.GetRuleSets("MyPolicy", RuleStore.Filter.All);
            foreach (RuleSetInfo rs in rlColl)
                if ((rs.MajorRevision == 1) && (rs.MinorRevision == 2))
                if ((rs.MajorRevision == 1) && (rs.MinorRevision == 1))

If you are wondering which RuleSetDeploymentDriver to use, since there are two of them available, check this. Additionally there are tools available to work with BRE from third party like Policy Verificator and now the newer version, which is currently in beta, called Business Rules Manager.


RuleBurst has a great capability around managing BizTalk rules. You might like to investigate that.

Managing BizTalk Business Rule Solutions With RuleBurst

@Anil, thanks for point this out. Yes, I agree that RuleBurst has great capabilities. Wish some of those will get added to BRE so that we don't have to worry about another product to procure

No, its certainly not a tool for business users. Microsoft has no offering in the BRMS space. This is a development tool only.

The 'Business' tag is a matter of history. Back in 2001-2003, the design and thinking behind the BRE was influenced quite significantly by work done by IBM Research in the late 1990s which culminated in CommonRules and Business Rule Markup Language (BRML). BRML was the precursor to RuleML and ultimately the W3C RIF standard. BRML advocated a rule model for e-Commerce that used 'Courteous Logic'. The idea was to make it easier to resolve certain logical inconsistencies that tend to occur because business users/analysts don't always specify rules fully. Example: Rule 1 says we offer a discount to loyal customers. Rule 2 says we don't offer a discount to late payers. A customer is asserted who is both loyal and a late payer. Which rule wins? Courteous logic introduced a mechanism for resolving these inconsistencies by allowing business users to specify an additional specialized rules called 'mutexes'. BRML has some other interesting features. The main one was the concept of 'situated' reasoning in which predicates and functions can be bound directly to external code (BRML thought of this code as comprising 'sensors' and 'effectors', which is 'software agent' terminology). This is designed to be supplemented by capabilities in the engine for 'directive events'. This is where the bound external code can issue events back to the engine to notify it of the need to assert, update or retract facts. BRML was also designed as a common rule language for interchange between different systems.

Microsoft's BRE does not implement Courteous Logic, though it looks like they may have been thinking about it at one time. The bad part of the 'logic program' legacy is that BRE is the one engine in its class that doesn't support quantification or even Negation-as-Failure (actually, BRML had NaF!). This is a real tragedy and badly needs to be fixed. Anyway, everything else was taken into BRE. The Business Rule Language is really just a high-level modelling language (you can still see the correspondance with RuleML the W3C RIF if you know what to look for). It is very BRML-like in parts (e.g., predicates and functions). It supports bindings to external code, and the engine supports directive events (you pass the built-in 'executor' function as an argument to external code). Microsoft also borrowed ideas directly from CommonRules like long- and short-term facts. The point is that CommonRules and BRML were envisaged as a step forward for supporting the use and interchange of business rules in e-Commerce applications - 'webizing' business rules, as the IBM people put it at the time. That is where the 'Business' tag seems to have come from, originally. Blame IBM!

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter