Evaluation of Rules and Decision Tabl...

Introduction

Cordys BOP-4 offers numerous ways to add logic to Business Processes.

One convenient way is to use Business Rules and Decision Tables. Business Rules apply to to business objects and are generally used to implement validations and logic that is often addressed at database level using stored procedures.

Decision Tables have no direct link to a business object. They implement logic that is mainly used for medium complex conditional behaviour in a Business Process. Using decision tables we may prevent complex sequences of conditions appearing in our BPM, blurring the real intentions of the business process.

Decision Tables

A decision table consists of a set of Rules, which each contain one or more conditions and actions. Conditions are evaluated to either true or false. Actions are executed if all conditions for a Rule evaluate to true. The schema fragment is the actual interface to the Decision Table. If used as a BPM activity it is exposed in the Message Map of the Business Rule modeler, and allows to specify input values and to retrieve output values after the step is completed. From the schema fragment attributes may be selected to use in conditions (e.g. for comparisons), and in actions (e.g. to assign values).


 Example of Decision Table, showing all concepts described above

Execution

Execution of a Decision Table-step in a BPM comprises the following:

1. First the massage mapping on the Decision Table attributes is made. 
2. Next the evaluation process is started: Every rule is evaluated separately in sequence, starting from left most, working to right.
3. The values of the concerned condition attributes are used to evaluate the conditions of the rule. If each condition of a rule evaluates to true, the actions specified for that specific rule are executed, starting with the top-most, working down to the bottom.

Example

In case we have a Decision Table TD, containing 3 rules: R1, R2 and R3, each having 2 conditions (Cx.1 and Cx.2, where x is the rule number), and 2 actions (Ax.1 and Ax.2 where x is the rule number), the statement in terms of pseudo code code would be like:

IF ( C1.1 AND C1.2) THEN

    a1.1

    a1.2

END IF

IF ( C2.1 AND C2.2) THEN

    a2.1

    a2.2

END IF

IF ( C3.1 AND C3.2) THEN

    a3.1

    a3.2

END IF

Implications

The example shows three important implications:

• Each rule is evaluated, even if its predecessor evaluates to true. (Hence: multiple rules may be executed)
  
• There is no OTHERWISE or DEFAULT construct available. (Like in the java SWITCH..CASE statement)
  
• The execution of an action of a certain rule may impact the result of the execution of one of the succeeding rules (e.g. by modifying values of attributes used in the conditions) 
  

So what if we want to perform a default action "a_def" in case none of the specified rules evaluate to true?


The solution would be to create an additional rule: R4.

R4 would contain 3 rules that are all the negations of the conditions of R1, R2 and R3:


In pseudo code:

IF ((NOT (C1.1 AND C1.2)) AND (NOT (C2.1 AND C2.2)) AND (NOT (C3.1 AND C3.2))) THEN

   a_def

END IF

One can imagine that this may be an time consuming and error prone activity if the Decision Table contains more rules and conditions.

An alternative may be using a flag, indicating if at least one of the rules has evaluated to true. This flag should be set initially to false. In case a rules evaluates to true, the flag should be set to true. (This implies that every rule would need an additional action that implements this!). In last (default) rule it just requires to check the value of the flag: If it is (still) false, the default action should be executed, otherwise not.


Note that the flag will have to be contained in the schema fragment of the Decision Table, and hence appears in its interface. Not the most elegant solution, but in certain cases a good trade off for the the possible complex conditions as described above.

Harald van der Weel

e-mail: haraldvanderweel@gmail.com