A decision table in Drools is a document stored in an XLS (Microsoft Excel) or CSV (Comma Separated Value) formatted file, which defines a set of rules using a very compact syntax.

The advantage of using XLS and not any other spreadsheet format is that many of the office suite products already support it. An XLS file can be edited nowadays with any of the most popular office suites such as MS Office, LibreOffice, OpenOffice, and so on.

A decision table in Drools requires a specific structure in order to be executed. This structure aids the compiler in the identification of different sections of the spreadsheet that play different roles in the rules that get ultimately generated when the decision table is compiled. That's right, just like with DSL/DSLR, a decision table is first converted into DRL before it is compiled as part of a KIE Container.

Following our simple categorization scenario, where customer categories were assigned according to age, they could easily be rewritten using a very simple decision table, such as the one shown next:

Even if we haven't talked about the structure of a decision table yet, it's quite simple to understand what's going on by simply looking at it. The tabular nature of a decision table makes it easy to read and modify.

Let's now analyze what the different sections of a decision table are and what they mean.

There are 2 main keywords when defining a decision table: RuleSet and RuleTable. The RuleSet (B2) keyword identifies where the decision table actually begins. The column where this keyword is used is also important; it determines the column that has to be used for any of the other keywords in the sheet. The RuleTable (B6) keyword identifies the beginning of a group of rules.

In the previous section, we introduced how a decision table could be used for our simple scenario of customer classification by age. Let's now analyze how the example decision table, shown next, gets converted into DRL:

The preceding spreadsheet can be found as part of the sources bundle associated with this chapter, along with the corresponding unit tests.

As we already know, the two keywords used in the RuleSet section of our decision table specify the package name and the no-loop attribute of the rules defined in it.

The rules, according to the spreadsheet, are composed of three conditions applied to a single pattern. In this case, the pattern is of type Customer. Notice that we have bound a variable to our pattern: $c. The first two conditions make reference to the age attribute of our Customer class. When a condition is only composed of a binary operator (such as ==, >, <, and so on), the use of $param is optional. The condition in cell B9 could have been written as age >. In these cases, Drools will understand that the interpolation value has to be placed at the end of the condition. When the operator is ==, things are even simpler: it's enough to just name the attribute we want to use for the comparison—that is, age.

When a data cell is left empty (like C14 in our example), the associated condition will not be included in the generated rule. In our scenario, the rule in row 14 doesn't impose a maximum value for the age of a customer; condition C9 is then not required.

The spreadsheet also shows that the generated rules will contain a single action composed of a modify statement. This statement is used to set the category of the matching customer $c.

Starting from row 11, we find the definition of four rules. Column A for those rows is just a descriptive name of the rule and it is ignored by Drools. The values in columns B, C, D, and E provide the interpolation data used for the conditions and actions.

If we look closer, the values for the third condition (D11-D14) look suspicious. They all have the same "NA" value. For these types of fixed values, we have three options: we can repeat the value for each of the rules, we can merge all the cells together to avoid repeating the same value over and over, or we can set the value in the constraint itself. The latter option presents some challenges though. If we change the value of the condition (in D9) to "category == Customer.Category.NA" we still need to come up with a value for the cells D11:D14; otherwise, the entire condition will be omitted in the generated rules. The problem is that, if we do set a value in these cells, Drools will recognize that the condition doesn't contain any interpolation variable and will assume that we are trying to use an implicit " == $param " operator. The generated code will then become invalid. A possible solution to deal with conditions without interpolation variables is to append them to some other condition by using a comma. In our example, we could modify the B9 condition to look like "age > $param, category == Customer.Category.NA" or "category == Customer.Category.NA, age > $param". The condition on cell C9 is not a good candidate in this case because there is a blank cell in this column. As we can see, a condition is not restricted to a singular DRL condition.

Taking the rules in rows 11 and 14 as an example, let's see what the generated DRL for these rules looks like:

package chapter07.dtable.simple;
import org.drools.devguide.eshop.model.Customer;
no-loop true

rule "Simple Customer Categorization_11"
when
    $c: Customer(age > 18, age <= 21, category == Customer.Category.NA)
then
    modify($c) { setCategory(Customer.Category.NA)}
end
rule "Simple Customer Categorization_14"when
    $c: Customer(age > 40, category == Customer.Category.NA)
then
    modify($c) { setCategory(Customer.Category.GOLD)}
end

In the preceding DRL we can see the result of rows 11 and 14 being converted to DRL. There are some important things to be noted in that DRL:

Because decision tables introduce a level of indirection between what the user writes and the DRL that actually gets generated, dealing with errors can be challenging.

As an example, let's assume that there is a typo in the condition present in C9. Instead of the correct value "age <= $param", let's assume that we inadvertently wrote "age =< $param". When the decision table containing this typo is compiled, it will generate the following error message:

Error while creating KieBase[
Message [id=1, level=ERROR, path=chapter07/dtable-simple/customer-classification-simple.xls, line=8, column=0 text=[ERR 102] Line  8:29 mismatched input '=' in rule "Simple Customer Categorization_11"],
Message [id=2, level=ERROR, path=chapter07/dtable-simple/customer-classification-simple.xls, line=16, column=0 text=[ERR 102] Line 16:29 mismatched input '=' in rule "Simple Customer Categorization_12"],
Message [id=3, level=ERROR, path=chapter07/dtable-simple/customer-classification-simple.xls, line=24, column=0 text=[ERR 102] Line 24:29 mismatched input '=' in rule "Simple Customer Categorization_13"],
Message [id=4, level=ERROR, path=chapter07/dtable-simple/customer-classification-simple.xls, line=0, column=0 text=Parser returned a null Package]]

The messages make reference to errors in three different rules: Simple Customer Categorization_11, Simple Customer Categorization_12, and Simple Customer Categorization_13. In all the cases, the error is the same: "mismatched input '='". The problem here is that each error makes reference to the line and column inside the generated DRL, but we don't actually know what that DRL looks like.

One of the ways, and probably the best way, to deal with errors in a decision table's generated DRL is to dump it into a place where it can be analyzed.

A decision table can easily be converted into DRL by using the class org.drools.decisiontable.DecisionTableProviderImpl from the drools-decisiontables project:

InputStream dtableIS = //get the input stream to the decision table file
DecisionTableProviderImpl dtp = new DecisionTableProviderImpl();String drl = dtp.loadFromInputStream(dtableIS, null);

DecisionTableProviderImpl defines a loadFromInputStream method that takes two arguments:

The sources bundle associated with this chapter has a working example of the preceding code.

Being able to reproduce the DRL generated from a decision table is a valuable help when we deal with errors. The line and column numbers in the error messages can be traced to the DRL generated by the DecisionTableProviderImpl class.

The example we just covered shows the basics of decision tables in Drools. There are many more interesting things we can do to make the life of the users of these spreadsheets easier. Most of the nice features spreadsheets support are also supported by Drools' decision tables. The features we are talking about are: collapsed/fixed/merged rows and columns, functions, colors, links between cells, and so on. By combining these features, we can create much more customized spreadsheets that enhance the overall experience of the user.

As an example, we can take the original decision table introduced in this chapter and apply some changes to leave it like the one bellow:

This enhanced version of the original decision table can be found in the source bundle with the name customer-classification-enhanced.xls.

Some of the enhancements present in this new version of the decision table are:

This example shows only a few of all the possibilities decision tables bring to the table to create a more elegant and concise way to define rules. The source bundle includes the decision table version of our advanced classification rules that uses the number of orders of a customer in order to set its category. The name of this decision table file is customer-classification-advanced.xls.

Decision tables provide an excellent way to easily create a considerable number of rules without too much work. Once the structure of the decision table is defined, the only job the rule author has is to add, update, or delete values in its cells. The possibility of making mistakes while authoring rules is still there, but, compared to DSLs/DSLRs, the risk is much lower.

Another advantage of decision tables over DSL is that we don't need any special UI for the former. Business users, most of the time, are already familiar with spreadsheets. There is no need to introduce a new UI to users before they can start writing their own rules.

But decision tables are not ideal for every situation: one of the biggest limitations is that rules we can model using decision tables must have the same structure. For cases like scoring, categorization, and classification, where the structure of the rules is almost the same and the only thing that changes is the values of their constraints, decision tables are a very efficient option. For situations where the structure of the rules doesn't necessarily remain the same, decision tables give us no benefits at all.

Another limitation decision tables have is that the structure of both the rules and the data is tightly coupled; they can't be reused separately from each other.

For situations where more flexibility is required, there is another option we may want to consider: rule templates.