This document describes a business user/analyst view of Drools Decision Tables.
Decision tables are a "precise yet compact" (ref. Wikipedia) way of representing conditional logic, and are well suited to "business" level rules.
What does one look like?
This shows a decision table in Microsoft Excel. You can use any spreadsheet editor that outputs CSV or Excel 97+ format spreadsheet files (such as Open Office).
Spreadsheets have been a key business information tool for up to 25 years now, so it was a good idea to use them to capture decision tables. Banks run their entire treasuries on spreadsheets (scary, I know, but it works !).
Running it
A decision table is executed in a deployed system by the Drools engine. First, the decision table is converted into the drools rule language (DRL), and then executed by the rule engine on demand. This means that it is possible for business rules to change without stopping and starting, or redeploying any software.
How does the table work?
In brief: the columns represent conditions (and consequences), and rows represent individual rules (each row is a rule).
In a "normal" table, each rule row will fire where all the conditions are matched. This behaviour can be altered as needed, so that the first rule to fire "stops" further rules, and the rules can be processed in a "top to bottom" fashioned for simple cases if needed.
Columns: A condition or consequence column only applies if there is data in a specific rule row. In the example above, the first "rule row" ("Catastrophic Claim") only uses the "Is case catastrophic" condition, as there is no data in any other cells.
Rows: Data is entered in cells that correspond to the condition column that you wish to apply. If there is data in more then one cell, then all the column conditions apply (logical "and").
Conditions and Actions: Actions are the action that is to take place should all the conditions be true. The convention is to have the action(s) on the right hand side, and also colour coded to separate from the conditions. There can be more then one action. As with conditions, actions only apply if a value is in the cell.
The above picture shows actions (colour coded for clarity).
Business and IT collaboration
To make decision tables work, some collaboration is required with IT prior to being deployed of course.
There is a business and a technical view of these decision tables. In the above examples, the technical view was hidden (by using the "Data grouping" feature).
The "+" symbols show/hide the technical details of the "mapping" between the business language (description) and the object fields that the condition/action applies to.
Generally, non technical users should not edit data in these protected/hidden cells, unless familiar with the appropriate language.
Editing rules
Once a decision table has been in use for some time, and changes are required, tables may be edited, rows added, and then redeployed as needed. Due to the separation of technical from business views, the impact of rule changes is controlled and thus lower risk. In some cases, however, IT involvement may be required to add new fields, or edit some underlying behaviour.
Typical workflow
Typically, the whole process of authoring rules (coming up with a new decision table) would be something like:
1. Business analyst take a template decision table (from a repository, or from IT)
2. Decision table business language descriptions are entered in table
3. Decision table rules are entered (roughly)
4. Decision table is handed to a technical resource, who maps the business language (descriptions) to scripts (this may involve software development of course, if it is a new application or data model !)
5. Technical person hands back and reviews the modifications with the business analyst.
6. The business analyst can continue editing the rule rows as needed (moving columns around is also fine etc).
7. In parallel, the technical person can develop test cases for the rules (liasing with business analysts) as these test cases can be used to verify rules and rule changes once the system is running.
Input validation
It is possible, using spreadsheet features to set validation rules for rule data (such as numeric, data ranges, and drop downs)
This shows a drop down that is populated from a list which is stored in another worksheet. This can further enforce the validity of rules.
Date formats
At present, date fields must be entered as "Text" (right-click, choose format, and set the type to "text").
Comments/documentation
You are free to put documentation anywhere in the spreadsheet around/outside of a rule table. Columns that are marked as conditions or actions should not have documentation in them (only rule data). You are free to use comments anywhere, however.
Under the covers
The above diagram shows how the columns are identified as a condition (action is not shown) and the scripts.
It also shows that this spreadsheet is operating in "top to bottom" mode.
Also note that Drools uses the "RETE" algorithm, which means that the normal practices of writing declarative rules still apply (this is a bigger subject, and not covered here).
If you are thinking of simple "IF... THEN" style rules, then decision tables can still apply.