Decision Rules

Decision rules are a way to visually model a conditional statement with multiple output values. This is very similar to a SWITCH statement in programming. Just like any other rule in AppBase, it accepts multiple input parameters and returns multiple output parameters. To calculate the output parameters, the decision rule is broken into multiple items (cases) that are executed sequentially in a predefined order. 

The process of calculating these parameters is broken into multiple parts that are executed in predefined manner. Ability to separate complex rule into multiple pieces makes the process of rule creation much more manageable. Each piece of the entire decision rule can be created and then changed independent of all other parts of that rule.

The decision rule is broken up into two parts:

1. The predicate (Rule)
2. Output parameters (Cost and Price in the example below)

The predicate

When a Decision Rule is executed, it goes through each row and evaluates the Predicate. If the result of the Predicate is true, then it returns the output parameters accordingly. If none of the cases match, it will return the values defined in the DEFAULT row. 

To set the Predicate click on the  Edit button next to the desired Predicate.

SQL NonQuery

This predicate will get executed like a normal rule. Its input parameters will be those passed into the Decision Rule itself and it will have one predefined output parameter named Result.

• Setting the Result parameter to 0 means this predicate returns a false value and indicates to the Decision Rule to continue with the other cases. 
• Setting it to 1 means the Decision Rule's output parameters will be set based on that predicate's case.

If the Decision Rule has an input parameter of ProductName then we can have an SQL Body like this:

BEGIN 
 :Result := 0;
IF :ProductName = 'TV' THEN 
 :Result := 1; 
 END IF; 
END;

Note: Because this predicate gets evaluated just like a rule, it can access data in Business Objects to create more complex criteria.

SQL Scalar

This predicate will get executed like a normal SQL Scalar rule.It's input parameters will be those passed into the Decision Rule itself and it's result will be the result of the SQL Body.

• Have a result of 0 means this predicate returns a false value and indicates to the Decision Rule to continue with the other cases. 
• Result of 1 means the Decision Rule's output parameters will be set based on that predicate's case.

If the Decision Rule has an input parameter of AccountID then we can have an SQL Body like the code below. It checks whether the passed in AccountID has any outstanding bills, if the Customer does then this predicate returns 1.

SELECT CASE 
         WHEN Count(*) = 0 THEN 0 
         ELSE 1 
       END AS cnt 
FROM   <%=Table("Customer")%>
WHERE  <%=Column("Customer","AccountID")%> = :AccountID AND
	   <%=Column("Customer","OutstandingBills")%> = 1

Note: Because this predicate gets evaluated just like a rule, it can access data in Business Objects to create more complex criteria.

Reference Table

Reference table is database representation of any business object created from specific template Action Table. When such business object is created in a solution it will contain all fields required for full definition of Decision Rule item. Of course custom properties can be added to this business object. When using reference table for decision rule item definition, all parts of the decision rule item (case) are stored inside that table in a single row. In this case the system will process each row in the order defined in configuration for the entire reference table. Each row may be considered as a single item (case) of decision rule. The advantage of this is that you can additional cases for a Decision rule on the fly without having to re-deploy. 

The setup screen of a Case of type Reference Table looks like:

The number of fields you see will depend on how many output parameters you have. The properties are:

If I want an Action Table for a Decision Rule that has output parameters Cost and Price, part of the table could look like:

Object Expression

Text

Output Values

If the case's predicate is true then the resulting output parameters of that case will be the results of the Decision rule. There are four four types of 

To set the output click on the  Edit button next to the desired output.

Constant

This is the simplest case and indicates that the output will always be the same for this case. Make sure the value is compatible with the output parameter's data type.

Object Expression

Text

SQL Non Query

This output will get executed like a normal rule. It's input parameters will be those passed into the Decision Rule itself and it will have one predefined output parameter named Result what will determine the value for this output.

An example of a simple SQL Non Query is below that sets the result to 880:

BEGIN 
:Result := 800 * 1.10; 
END;

Note: Because this SQL Body gets evaluated just like a rule, it can access data in Business Objects to create more complex criteria.

SQL Scalar

This output will get executed like a normal rule. It's input parameters will be those passed into the Decision Rule itself and it's result will be determine the value of the output. 

If the Decision Rule has an input parameter of AccountID then we can have an SQL Body like the code below. It checks whether the passed in AccountID has any outstanding bills, if the Customer does not then this predicate returns a -200 discount.

SELECT CASE 
         WHEN Count(*) = 0 THEN -200 
         ELSE 0 
       END AS cnt 
FROM   <%=Table("Customer")%>
WHERE  <%=Column("Customer","AccountID")%> = :AccountID AND
	   <%=Column("Customer","OutstandingBills")%> = 1