A business rule is the basic unit of rule processing in a Business Rule Management System (BRMS) and, as such, requires a fundamental understanding. Rules consist of a set of actions and a set of conditions whereby actions are the consequences of each condition statement being satisfied or true. With rare exception, conditions test the property values of objects taken from an object model which itself is gleaned from a Data Dictionary and UML diagrams. See my article on Data Dictionaries for a better understanding on this subject matter.

A simple rule takes the form:

Teaching You Tools to Become Empowered

To build a successful business and career, you must always keep up with changes in the IT Marketplace. AWS, Office 365, LinkedIn, Sales Force, SEO, Social Media are just a few examples of where knowledge is a huge factor for success.

Training with HSG addresses your knowledge gaps and provides you with the requisite tools to outpace the competition.

if condition(s)

then actions.

An alternative form includes an else statement where alternate actions are executed in the event that the conditions in the if statement are not satisfied:

if condition(s)

then actions

else alternate_actions

It is not considered a best prectice to write rules via nested if-then-else statements as they tend to be difficult to understand, hard to maintain and even harder to extend as the depth of these statements increases; in other words, adding if statements within a then clause makes it especially hard to determine which if statement was executed when looking at a bucket of rules. Moreoever, how can we determine whether the if or the else statement was satisfied without having to read the rule itself. Rules such as these are often organized into simple rule statements and provided with a name so that when reviewing rule execution logs one can determine which rule fired and not worry about whether the if or else statement was satisfied. Another limitation of this type of rule processing is that it does not take full advantage of rule inferencing and may have a negative performance impact on the Rete engine execution. Take a class with HSG and find out why.

Rule Conditions

Rule Conditions must be boolean expressions that resolve to either true, false, null or with some BRMS products unavailable or unknown. Such expressions can combined via the and and or operators:

if expression1 and expression2 or expression3

requires that expression1 must be satisfied as well as expression2 or expression3.

Rule Actions

Rule actions may execute any or all of the following:

1. modify an object property

2. object instantiation and deletion

3. method invocation

4. rule groups or sub-node invocation

5. data retrieval from a DBMS, file, enterprise application or web service

Rule Template

Now onto the fun stuff. Suppose we had a number of rules which were very similar to one another; that is, their conditions are affected by the same object(s) and the action statements share lists of common functionality. The question then becomes would it be feasible to create a rule template that can be used to generate a number of these types of rules. The value add of this endeavor would be to allow a non-software guru i.e. a rule author to create these rules as they relate to the terms that they understand.

Let's take a simple example. Suppose we were to create a travel software program that included corporate travel discounts. There are many factors we would have to consider but we can limit the possibilities to the name of the corporation, the duration of the flight and the requested service class of the flight. The only action in the action statement of the rule will be to set the service class status. The rule author can then create a variety of rules that will determine the type of flight status for which an employee qualifies based upon their employer, the duration of the flight and their requested flight type. The illustration to the left provides an example of how a rule template may be constructed.

There are a number of things to notice about this illustration:

1. Both conditions and actions are written in English like syntax. No dot notation or any other software like syntax should be required to confuse the rule author.

2. The option to remove conditions from the rule should be provided unless the rule requires that they be part of the if statement.

3. All conditions in this rule template are connected via the and operator. If this satisfies all such rule types, then job well done; however, if these expressions can be or'ed together, than the software developer/template author needs to include them.

4. All mathematical operators in this example have been hard-coded. The equals (=) operator and the less than (<) operator are a permanent part of the condition. If these business rules may include a not equal to, greater than, greater than or equal to ... more options than the hard-coded options provided, this functionality should be written into the rule template

5. Only a drop down list with 3 choices is written into the action template. If these rules may yield different options in the action statement, then each one needs to be included as an option by the template author.

What is not shown in the illustration is that the rule author can create more than one rule. Depending upon the constructs of both the condition and action statements, the number of rule permutations may be extensive. As per the article on BRMS, the resulting rules are stored in an XML instance file in a rule repository.

Limitations

After reading this article you may be euphoric, well maybe excited, realistically speaking intrigued by the possibilites of templatizing your business logic so that you may quickly react to the competition and modify/grow your options without technological limitations. Before you prepare for the challenge, let me identify some of the limitations:

1. Before creating a rule template, you must have more than one, correction, make that considerably more than one rule, that should be generated from such a template. There is a lot of work that goes into creating templates, and to squander an inordinate amount of time and money creating them for one rule that will never change is, well, not the most efficient undertaking.

2. Certain constructs should not be templatized. Rules that contain a fair amount of complex computations or functions, if you will, should not be modeled into a template. I can go on and on as to the reasons behind this suggestion; suffice it to say that presenting a rule author with the option to create a Fibonacci series or some other complex mathematical operation may not yield the desired outcome. Some organizations have realized this after they decided to include all of their business logic in a BRMS let alone a template; not only did they suffer getting the product to market in a reasonable time but runtime performance hits were incurred as these rules may not have been written to make the best use of the Rule engine when compared to running them via C++ or some other natively compiled language.

3. Who will modify the rules? Who will be able to read them? When and how will these rules be deployed? Obviously, an entire deployment and security model needs to be built that identifies the players and addresses enterprise application challenges.

4. Do you have the requisite expertise to begin building such templates and to aid rule authors in their development process? These types of endeavors require time, expertise and capital to complete successfully.

5. If the object model tends to change a lot before or after creating these templates, look out! The development team may, forever, be in update mode having to incorporate these changes into the templates, sub-templates ... One little change to the object model by way of changing a property name or type or by including another property may have sweeping consequences resulting in a slew of compiler errors and hours of debugging.

Rule templates, as part of a BRMS, can be incredibly invaluable. Some applications cannot function without them because rule placement is on a client-by-client basis; that is, the rules of the application are unique for each client that purchases the product. These clients can enter their own rules so that the product functions in the manner they need. Rule templates also make rule replacement and modification quick and easy. Selecting a condition and action from a drop-down list is much easier than writing the code behind it.

Rule templates can also be the bane of the development staff when a lot of work goes into beautifying code so that everyone can read it and only some can change it. Perhaps writing a rule or set of rules without deriving them from a template may be the better option.