Infosys | Microsoft

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))
                {
                    dd.Undeploy(rs);
                }
               
                if ((rs.MajorRevision == 1) && (rs.MinorRevision == 1))
                {
                    dd.Deploy(rs);
                }
            }

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.