So to keep up the promise that I made yesterday, I am posting a simple yet very useful (in my opinion :) ) application to help the MS BRE users out there. MS BRE has a useful artifact called vocabulary. To quote from msdn,

The terms used to define rule conditions and actions are usually expressed by domain or industry-specific nomenclature.Underlying this domain-specific terminology are the technology artifacts (objects, database tables, and XML documents) that implement rule conditions and rule actions. Vocabularies are designed to bridge the gap between business semantics and implementation.

In short, vocabularies are industry-specific, business analyst friendly aliases for facts. Vocabularies help the domain experts to encapsulate their process knowledge in business rules without worrying about the underlying technical implementation details. Vocabularies as a concept itself seems to be very useful. Once you start developing your rules with vocabularies you would both love them a lot and hate them a lot.

The biggest pain point with vocabularies is that once they are published they cannot be modified, and that you cannot use your vocabularies in your rules without publishing them. This really causes a problem while developing rules as often a case arises when you have to modify a vocabulary definition and then you have to modify all the rules that used this vocabulary definition. Vocabularies are not first class citizens in MS BRE. The core engine doesn't understand vocabulary definitions. Rules instead of linking to the individual vocabulary definitions contain the complete vocabulary definition embedded in them. Hence, just changing a vocabulary definition does not automatically update the rules that use this definition. There are two design considerations in this implementation

• Tracking becomes difficult. Its very hard to go back in time and say what rule executed on a particular saturday.
• Performance suffers. Now at run-time, you have to do all the validation checks and then merge all the vocabularies with the ruleset to get an executable ruleset.
• Rules become inconsistent very often. Changing a vocabulary definition from float to double might not cause much trouble, but if you change a constant from column1 to column2 where in you use the constant value as a SQL column name. 

To solve some of these issues I have written a small command line tool to update your policies to use the latest version of your vocabularies. Using it is simple. Run 

VocabChanger.exe <policy-name> <policy-version>

  Running this creates a new version of the policy with all the rules updated to use the latest vocabulary definitions. The tool tries to be as friendly as possible by letting you not only change the values of vocabulary definition like changing pi from 3.14 to 3.1415 but also letting you change the definition types like changing customer-id from an xml-element to a sql column as long as the types remain compatible.

Download the tool here.