Relationships between Rules Inside Decision Tables

The OpenRules execution logic inside decision tables is very intuitive. OpenRules does not assume any implicit ("magic") execution logic and executes rules in the order specified by a rule designer.  All rules are executed one-by-one in the order they are placed in the rules table. There is a simple rule that governs rules execution inside a rules table:

The preceding rules are evaluated and executed first!

For standard vertical decision tables, all rules (rows) are executed in top-to-bottom order. For horizontal decision tables, all rules (columns) are executed in left-to-right order.

The execution logic of one rule (one row in the decision table) is as follows:

            IF ALL conditions are satisfied THEN execute ALL actions.

If at least one condition is violated (the proper code evaluation produces false), all other conditions in the same rule (row) are ignored and are not evaluated. 

The absence of a parameter in a condition cell means the condition is always true.  Actions are executed only if ALL conditions in the same row evaluated to be true.  Action cells with no parameters are ignored.

Processing Multi-Hit and Single-Hit Decision Tables

Let's consider how OpenRulesEngine executes very simple rules that defines a salutation "Mr.", "Mrs.", or "Ms." based on a customer's gender and marital status:

Rules void defineSalutation(Customer customer, Response response)
Gender	Marital Status	Set Salutation
Male		Mr.
Female	Married	Mrs.
Female	Single	Ms.

If a customer is Married Female the conditions of the second rules are satisfied and the salutation "Mrs." will be selected.  This is only a business view of the rules table.  The complete view including the hidden implementation details ("Java snippets") are presented below:

Rules void defineSalutation(Customer customer, Response response)
C1	C2	A1
customer.gender.equals(gender)	customer.maritalStatus.equals(status)	response.map.put("salutation",salutation);
String gender	String status	String salutation
Gender	Marital Status	Set Salutation
Male		Mr.
Female	Married	Mrs.
Female	Single	Ms.

OpenRulesEngine will execute rules (all 3 "white" rows) one after another. For each row if conditions C1 and C2 are satisfied then the action A1 will be executed with the selected "salutation".

Please note that for this table conditions for all 3 rules will be examined before executing any actions. This is an example of so-called "multi-hit" rules table that executes all rules it may "hit". We may add one more rules at the very end of this table:

Rules void defineSalutation(Customer customer, Response response)
Gender	Marital Status	Set Salutation
Male		Mr.
Female	Married	Mrs.
Female	Single	Ms.
		???

In this case, after executing the second rule OpenRulesEngine will also execute the new 4th rule and will override a salutation "Mrs." with "???".  It is obviously not good.  However, sometimes it may have a positive effect to avoid undefined values in cases when our previous rules did not cover all possible situations. What if our customer is a Divorced Female?!

How to avoid this multi-hit effect? We want to produce "???" only when no other rules were satisfied.  To achieve this you may use so-called "single-hit" tables that are specified by putting any return type except of "void" after the keyword "Rules".  The following is an example of a single-hit rules table that will do exactly what we need:

Rules String defineSalutation(Customer customer, Response response)
Gender	Marital Status	Set Salutation
Male		Mr.
Female	Married	Mrs.
Female	Single	Ms.
		???

Another positive effect of such "single-hitness" may be felt for large tables with say 1000 rows: if OpenRulesEngine hits a rule #10 it would not bother to check the validity of the remaining 990 rules.

Having rules tables with a return value may also simplify your interface. For example, we do not really need a special object Response in which we used to write the defined salutation. Our simplified rules table may look like follows:

Rules String defineSalutation(Customer customer)
C1	C2	A1
customer.gender.equals(gender)	customer.maritalStatus.equals(status)	return salutation;
String gender	String status	String salutation
Gender	Marital Status	Set Salutation
Male		Mr.
Female	Married	Mrs.
Female	Single	Ms.
		???

Here is an example of Java code that creates an OpenRulesEngine and executes the latest rules table "defineSalutation":

public static void main(String[] args) {     String fileName = "file:rules/main/HelloCustomer.xls";     OpenRulesEngine engine = new OpenRulesEngine(fileName);     Customer customer = new Customer();     customer.setName("Robinson");     customer.setGender("Female");     customer.setMaritalStatus("Married");     String salutation = (String) engine.run("defineSalutation", customer);     System.out.println(salutation); }

You can learn more about OpenRulesEngine API from the User's Guide.  The standard OpenRules's installation contains many examples that demonstrate how to invoke OpenRulesEngine from regular Java applications (see projects HelloJava, HelloJsr94, HelloXMLCustomer) as long as from web-based applications (see projects HelloJsp, HelloForms, and HelloWS). 

Relationships Between Rule Tables

In most practical cases business rules are not located in one file or in a single rule set, but rather are represented as a hierarchy of inter-related rules tables located in different files and directories - see Business Rules Repository. When you run OpenRulesEngine, you are executing a method from its main xls-file.  Frequently, this method defines an execution logic that uses the conditions and sequences of rules presented in other rules tables and methods.  In trivial cases, the rule engine can execute a rule table directly from a Java program. Typically, the main method executes a launcher that is a simple method specifying the execution sequence for different rules tables.

Because OpenRules interprets rules tables as regular methods, designers of rules frequently create special "processing flow" decision tables to specify the conditions under which different rules should be executed.  See examples of processing flow rules in such sample projects as Loan2 and LoanDynamics.  One way or another, a rule designer needs to explicitly specify the execution logic for different rule sets.

In the several years that OpenRules has been used as a component of complex real-world applications it has proven its high level of performance and its scalability.  These days most Rule Engines demonstrate a high level of performance, but OpenRules is frequently chosen over major commercial BR products because of the following differentiators:

	High performance
	High scalability for multi-user environments
	Efficient use of memory.

Consider the results cited in a a report OpenRules recently received from a major international bank.  The bank created a series of performance and scalability tests before selecting OpenRules as the BR product of choice.  They demonstrated that OpenRules scales to more than 300 concurrent users on a hyper-threaded Xeon box.  Each concurrent user executed its rules 10,000 times with the following results: