5 Working with Decision Tables

This chapter describes how to use Decision Tables to create and use business rules in an easy to understand format that provides an alternative to the IF/THEN rule format. It also covers the various components of a Decision Table such as conditions, conflicts, actions, and discusses the various operations that you can perform on a Decision Table.

The chapter includes the following sections:

• Introduction to Working with Decision Tables

• Creating Decision Tables

• Introduction to Decision Table Operations

• Creating and Running an Oracle Business Rules Decision Table Application

• Editing Decision Tables in Microsoft Excel

5.1 Introduction to Working with Decision Tables

Businesses invest in software to automate their business processes. Historically, this automation focused on the collection, presentation, and manipulation of data to facilitate human decision-making about that data. Increasingly, however, software designers and developers are called upon to automate the decision making process by putting detailed rules about business processes into software architectures. In addition, many enterprises are experiencing increasing pressure to make software systems more responsive to business changes.

In some cases, the role of writing and testing business rules is no longer assigned to software engineers, but is passed to trained business users. Alternatively, some organizations attempt to separate changes in the business behavior of software from the traditional software development cycles, and tie changes to business driven imperatives like product or sales cycles.

A Decision Table provides a mechanism for describing data processing tasks, especially when that description is done by business analysts rather than computer programmers.

The Decision Table format is intuitive for business analysts who are familiar with spreadsheets. The formal structure that a Decision Table provides makes it easier to author, understand, and change multiple similar rules and lets software check for rule completeness and consistency.

Oracle Business Rules Decision Tables provide the following features:

• Powerful Visualization: Compact and structured presentation. This visualization matches the way real world business policies are expressed: with many tables, declarative, and organized into simple steps.

• Error Prevention: Avoids incompleteness and inconsistency. Because a Decision Table is well structured, automated tools can check for conflicts, redundancy, and incompleteness to speed development of valid, consistent business rules.

• Modular Knowledge Organization: Group rules into a single table. A spreadsheet metaphor puts groups of rules that work together onto a single viewable pane. For example, if there are six rules that check an applicant's eligibility, it is more convenient to see all the rules than to view the rules as individual but related rules.

• Optimization of Rules and Performance Benefits: Oracle Business Rules Decision Tables provide automated features that can reduce the number of required rules, as compared to the IF/THEN rules (this is called rule coalescing).

• Rule Validation and Verification: Provides capabilities for ensuring the logical consistency of rules before deployment. Automated tools for checking conflicts or incompleteness help speed development of valid, consistent business rules.

Ease of verification and visualization are the major reasons for using Decision Tables.

For information, see Working with Rulesets and Rules.

5.1.1 What is a Decision Table?

A Decision Table displays multiple related rules in a single spreadsheet-style view. In Rules Designer a Decision Table presents a collection of related business rules with condition rows, rules, and actions presented in a tabular form that is easy to understand. Business users can compare cells and their values at a glance and can use Decision Table rule analysis features by clicking buttons and selecting values in Rules Designer to help identify and correct conflicting or missing rules.

To help understand Decision Table concepts, consider a set of IF/THEN rules that determines if a driver is eligible for a license, and an equivalent Decision Table. Note if a driver has taken a driver training class then the driver has training certification.

The IF/THEN rules follow:

if driver.age < 20 and driver.has_training then training = true
if driver.age < 20 and driver.has_training = false then driver.eligible = false
if driver.age >= 20 then driver.eligible = true (do not care about training for this case) 

Figure 5-1 shows a Decision Table representation of these rules that includes areas for Decision Table Conditions and Actions.

Figure 5-1 Sample Decision Table with Conditions and Actions

Description of "Figure 5-1 Sample Decision Table with Conditions and Actions"

5.1.1.1 What You Need to Know About Decision Table Conditions

The Conditions area in a Decision Table includes one or more condition rows. Each condition row has a condition expression and, for each rule, a condition cell. A condition expression is an expression that you build in Rules Designer. The condition expression is often a fact property or a function result, but it can be any expression that has a type that can be associated with a value set. Test expressions are often used, such as Driver.age<16. These expressions are associated with the built-in boolean value set, with values true and false. The value or the range for a given condition cell takes its value or its range from one or more values or ranges in the associated LOV or Ranges value set. For more information on value sets, see Working with Value Sets.

For example, Figure 5-1 shows the condition expression for a Driver fact with the Driver.age property. The corresponding row in the Decision Table shows condition cells including values for the ranges <20, and >=20. The values in the cells come from the global value set named driver_ages.

Figure 5-1 also shows a condition row for the Driver fact with the Driver.has_training property. This condition row shows condition cells with the values, true, false, and -. The hyphen (-) means "do not care" (that is, Driver.has_training could be true or false in this case). The values for these condition cells come from the default value set associated with boolean types (this consists of default values for the values true and false).

The '-' (don't care) value is useful to ensure that a decision table will not have gaps when new values are added to a value set. For example, if a valueset initially contains 1, 2, and otherwise, a rule matching otherwise will fire if the input is 3. But after 3 is explicitly added to the valueset, then otherwise no longer matches an input value of 3. If no rule contains a '-' for this input, then no rule will fire when the input value is 3 and the decision table is said to have a gap.

Use 'otherwise' when you explicitly want to match the 'otherwise' value in the valueset, and not any other value. 'Otherwise' is useful to avoid conflicts in a decision table. '-' is used to match any value, and will often cause conflicts. These conflicts can be automatically resolved using the 'auto override' conflict policy.

Decision Tables show rules in bucket order, and to change the order of rules you need to change the order of buckets in the value set. Thus, the order of the buckets in the value set associated with a condition row determines the order of the condition cells, and thus the order of the rules. You can control rule ordering in a Decision Table by changing the relative position of the buckets in an LOV value set associated with a condition row; however, you cannot reorder range buckets (values). For information on ordering buckets in a value set, see How to Define a List of Values Global Value Set.

5.1.1.2 What You Need to Know About Decision Table Actions

Actions are associated with rules in a Decision Table. At runtime, when facts match for condition cells, the Rules Engine prepares to run the actions associated with the rule.

Table 5-1 shows the types of actions you can choose in the Actions area. Thus, in an action you can call a function, assert a new fact, retract a fact, or modify a fact, and so on. In the Actions area the cells corresponding to an individual action for a rule are called action cells. For more information on advanced mode, see How to Select the Advanced Mode Option.

Table 5-1 Decision Table Actions for Action Cells

Action	Description
assert new	Assert a new fact.
assign	Assign a value to a variable.
call	Call a function.
modify	Modify a data value associated with a matched fact.
retract	Retract a fact.
assert	Assert a fact.
assert tree	Asserts a tree of facts given the root.
assign new	Assign a value to a new variable.
expression	Perform expression.
return	The return action returns from the action block of a function or a rule. A return action in a rule pops the ruleset stack, so that execution continues with the activations on the agenda that are from the ruleset that is currently at the top of the ruleset stack.
throw	Throw an exception, which must be a Java object that implements java.lang.Throwable. A thrown exception may be caught by a catch in a try action block.

When you add multiple actions the actions that you add in the Actions area are ordered; actions appearing in the higher rows run before actions in the following rows.

The Decision Table actions such as modify can refer to facts matched in the condition cells. For example, given a Decision Table with condition rows on the Driver fact that includes condition rows for Driver.age and Driver.has_training, actions can modify the property Driver.eligible and you can specify a value for Driver.eligible for each action cell.

Certain types of actions in the Actions area include a Parameterized check box. This check box specifies that a property from the action can have its value set in the action cell associated with a rule in the Decision Table. When the parameterized check box is selected, the value you supply for the expression value in the action, in the Actions area, becomes the default value for the property if a value is not supplied in the action cell. For example, see Figure 5-2 where the value false is assigned as the default value for the action property eligible.

Figure 5-2 Action Editor Showing Parameterized Action with Default Value

Description of "Figure 5-2 Action Editor Showing Parameterized Action with Default Value"

5.1.1.3 What You Need to Know About Decision Table Rules

A ruleset contains a Decision Table; this provides a way to group the Decision Table along with IF/THEN rules. When rules and Decision Tables are grouped in a ruleset, the IF/THEN rules and the Decision Table rules all execute as a set of interrelated rules.

A rule in a Decision Table is not named. Although Rules Designer shows rules in a Decision Table with labels, for example, R1, R2, and R3, these rule labels are not names for individual rules but are labels derived from the current ordering of the rules in the Decision Table. Thus, a rule with the label R1 could be moved to position 3 and then Rules Designer relabels this rule R3.

Rules in a Decision Table are organized as a table that contains a tree of condition cells. The condition cells in the first row span the cells of later condition rows. A parent cell in row i spans its children in row i+1.

Figure 5-3 shows rules in a Decision Table where each rule consists of one cell from each row in the Conditions area, and an associated action cell in the same column in the Actions area. Figure 5-3 shows the rule with the label R3 defined by the first cell from condition 1 (the Driver.age < 20 value), the second cell from condition 2 (the Driver.eye_test equals fail value), and the third cell from condition 3 (the Driver.has_training equals true value). Likewise for each of the other rules, R1 to R12, there is a unique path through the Decision Table.

Figure 5-3 Rules in a Decision Table

Description of "Figure 5-3 Rules in a Decision Table"

As shown in Figure 5-3, it is significant for a cell to be a parent of another cell and a parent cell spans lower cells. In the Conditions area, when condition cells have the same parent condition cell the cells are called siblings. Certain operations only apply for condition cells that are siblings. For example, Figure 5-4 shows two sibling cells that are selected; with these cells selected the Merge Selected Cells operation is valid. For these cells, the corresponding value set with the value fail for Driver.eye_test is also a sibling (as shown in the R3 and R4 columns in Figure 5-4). For more information, see How to Merge or Split Conditions in a Decision Table.

Figure 5-4 Sibling Condition Cells in a Decision Table

Description of "Figure 5-4 Sibling Condition Cells in a Decision Table"

Rules Designer lets you easily reorder rows by selecting the row and clicking a Move button. By reordering rows in the Conditions area you can perform operations on condition cells at the desired granularity. Thus, the move operations can assist you when you want to split, merge, or assign certain values that might only be appropriate at a particular level in the tree, depending on the location of a condition cell or depending on the location of the parent, children, or siblings of a condition cell.

5.1.2 Understanding Condition Cell Values

By default, when you create a condition row, Rules Designer creates a single condition cell and assigns the "?" value to the cell. A condition cell with the value "?" indicates that the value of the cell is undefined in the value set. For example, Figure 5-5 shows a "?" value for StrategyContext. Note that contiguous value ranges in a condition cell are combined. For example, if you select <20 and [20..40] it will display as <=40.

Figure 5-5 Sample Decision Table Showing Undefined in Condition Cell

Description of "Figure 5-5 Sample Decision Table Showing Undefined in Condition Cell"

5.1.3 Understanding Action Cell Values

In the Decision Table Actions area you can specify that an action cell "do nothing." In this case, clear the action cell. When the action cell check box is cleared, this means do not perform this action when the pattern matches for the specified condition values in the Decision Table. Thus, for each action cell you can specify whether the rule associated with the action cell should activate the action, or does not perform the action.

In a Decision Table, when a condition cell represents a value that has been removed from the value set, Rules Designer provides a validation warning such as the following:

RUL-05831: Decision table value reference not found

To fix this type of validation warning you can do one of the following:

• Define a value by double-clicking the condition cell and selecting one or more values from the list.

• Add the missing value to the value set or associate the condition with another value set that contains the missing value.

5.1.4 What You Need to Know About Decision Table Loops

A Decision Table loop occurs when the value for a condition row is changed by an action. Loops can occur across the rules in a single Decision Table or spread over several Decision Tables, or spread over rules and Decision Tables in the same ruleset. Try not to create Decision Table actions that modify fact properties that are used in Decision Table conditions. This could cause an infinite loop.

Note:

You can prevent infinite loops by using the rule firing limit on the containing decision function.

5.2 Creating Decision Tables

You add a Decision Table by performing several steps.

These steps include creating a Decision Table, creating value sets, and then adding conditions and actions to Decision Table, and using the Decision Table to operate to validate, correct, and modify the Decision Table.

5.2.1 How to Create a Decision Table

To work with a Decision Table, start by creating a Decision Table in a ruleset.

To create a decision table:

1. From Rules Designer select an existing ruleset from the rulesets tab or create a ruleset by clicking Create Rule Set....
2. Click Create from the Decision Tables area on the Overview tab, as shown in Figure 5-6. This creates a Decision Table.

   Figure 5-6 Adding a Decision Table

   
   Description of "Figure 5-6 Adding a Decision Table"

Note:

When you add a Decision Table the rules validation log displays validation warnings. The Decision Table is not complete and does not validate without warnings until you add conditions and actions to the Decision Table.

5.2.2 How to Add Condition Rows to a Decision Table

A Decision Table includes a Conditions area where you specify Decision Table condition rows. The condition rows determine the facts that the Oracle Rules Engine matches at runtime. To create a Decision Table you need to add one or more condition rows to the Decision Table.

To add condition rows to a decision table:

1. From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to add conditions.
2. In the Decision Table area, from the list next to the Add button select Condition.
3. In the Conditions area, double-click <edit-condition> to display the navigator to select or enter an expression as shown in Figure 5-7.

   Figure 5-7 Adding a Condition to a Decision Table

   
   Description of "Figure 5-7 Adding a Condition to a Decision Table"
4. Enter an expression by clicking in the navigator to select a variable or click the Expression Builder button to display the Expression Builder window. The Expression Builder lets you build expressions.
5. Each condition row requires a value set from which to draw the values for each cell. When the value you select has an associated global value set, then by default the value set is associated with the condition row.
6. Repeat Step 2 through Step 5, as required to add additional condition rows in the Decision Table.

5.2.3 How to Use or Specify the Value Set for a Decision Table Condition

1. Each condition row requires a value set from which to draw the values for each cell. When the value you select has an associated global value set, then by default the value set is associated with the condition row.
2. If there is no global value set associated with the value, then after you add a condition row to a Decision Table you need to specify either a Local List of Values or a Local List of Ranges value set to associate with the condition row, or specify an existing global value set. To add a value set for the condition, in the Conditions area select the condition and then select from the value set list to associate a value set, as shown in Figure 5-8. The value set list includes available global value sets of the appropriate type.

   Figure 5-8 Specifying a Value Set For a Condition Row in a Decision Table

   
   Description of "Figure 5-8 Specifying a Value Set For a Condition Row in a Decision Table"
3. If you do not specify a global value set, then you can create and use a local value set by selecting either Local Value Set or Local Range Value Set to create and use the specified type of value set.
4. Repeat Step 2 through Step 3, as required to define additional condition rows in the Decision Table.

For more information on creating value sets, see Working with Value Sets.

5.2.4 How to Add Actions to a Decision Table

A Decision Table includes an Actions area where you specify Decision Table actions. The actions determine actions for rules in a Decision Table. To create a valid Decision Table, add actions to a Decision Table. For each action cell, where specific values apply, set the values for the action cells. For each action cell, when the action does not apply to the rule, deselect the action cell. By default when you add an action to a Decision Table, actions for all the rules are unselected

To add actions to a decision table:

1. From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to add actions.
2. From the list next to the Add button, select Action and select an available action from the list. Table 5-1 lists the available actions. For example, select Modify. Rules Designer displays the Action Editor dialog as shown in Figure 5-9.

   Figure 5-9 Adding an Action to a Decision Table

   
   Description of "Figure 5-9 Adding an Action to a Decision Table"
3. In the Action Editor dialog select the action target in the Target area. This specifies the data model object the action applies to.
4. For the specified target, as needed to make the action do what is required, modify the fields in the Arguments table. In the Action Editor dialog the Arguments table includes the fields shown in Table 5-2.

   Table 5-2 Action Editor Dialog Arguments Fields

   Field	Description
   Property	Displays the property names for the specified target.
   Type	Displays the type for the property.
   Value	Select the default value for the action from the list of available actions. The specified value applies to either the entire action, as the default value, or when a particular action cell is selected, the value specified applies for that particular action cell.
   Parameterized	This specifies a parameterized value. A parameterized value displays in a Decision Table action cell. When you select parameterized value for a property, this generally means that each rule supplies a different parameter value.
   Constant	Select to specify a constant value.

5. In the Action Editor dialog, to select action cells for all the rules, select the Always Selected check box.
6. Repeat Step 2 through Step 5, as required to define additional actions for the Decision Table.

5.2.4.1 How to Set Values for Action Cells in a Decision Table

To set values for action cells:

1. From Rules Designer, select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to specify action cell values.
2. In the Actions area, check that the appropriate action cells are selected. If the Always Selected check box is specified in the Action Editor dialog, then all action cells should be selected. If Always Selected is not selected, then select the appropriate action cells using the action cell check box.
3. In the Actions area, enter the appropriate value for parameterized properties for each selected action cell. To do this select the action cell property cell, and either enter a value, select a value from the list, or click the Expression Builder button to use the Expression Builder dialog.

   For more information on referring to a value set from a Decision Table, see How to Define a List of Ranges Global Value Set.

5.2.4.2 How to Deselect an Action Cell in a Decision Table

To deselect an action cell:

1. From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want deselect an action cell.
2. In the Actions area, select the action cell and deselect the check box in the action cell. You are not allowed to deselect action cell values when Always Selected is selected for the action.

When you add actions, you may need to change the order of the actions. In Rules Designer you can use the Move Down button or Move Up button to change the order of actions.

5.2.5 How to Add a Rule to a Decision Table

You can add a rule to a Decision Table. Rules Designer adds a column for the rule to the left of the existing rules and each condition cell is initialized to "?", which actually means a validation error prompting you to populate the cell with relevant values.

To add a rule to a decision table:

1. From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to add the rule.
2. From the list next to the Add button, select Rule.
3. Enter values for the condition cells. Notice that the new rule is added as the first rule of the Decision Table on the left and the other rules have moved as required to keep the values in their defined order.
4. Enter values for the action cells.

The Order Rules By Bucket check box under the Advanced Settings of a Decision Table is selected by default. In this case, the Decision Table layout changes automatically on adding new rules.

When you add a new rule to a Decision Table, the new rule is added as the first rule of the Decision Table and the other rules move as required to keep the values in their defined order. This is because Order Rules By Bucket is enabled, which means rule ordering in a Decision Table is set according to the relative position of values associated with a condition expression. If Order Rules By Bucket is not enabled when you add a rule, the new rule is added as the last rule of the Decision Table. In either case, the cells in the new rule column have "?" symbols, indicating the cells do not have values yet.

Note:

When Order Rules By Bucket is selected, the rules are ordered and duplicate rules (rules with exactly the same values) are combined. So, you cannot add two rules without any values to a Decision Table, because in that case, the rules are duplicates and would immediately be combined. When Order Rules By Bucket is cleared, then duplicate rules are allowed.

In addition, the Move buttons pertaining to a rule column are also enabled. You can use them to reposition rules. Use the Flip the Table Rows and Columns button to change the view of the Decision Table. This also affects the Move buttons: the move direction may be Up or Down, Left or Right. The Merge, Compact and Span options are also enabled. You can also cut, copy, or paste rules.

For more information, see Introduction to Decision Table Operations.

5.2.6 How to Define Tests in a Decision Table

You can define tests in a Decision Table. The tests must evaluate to true for any rule in the decision table to fire. For more information about defining tests and working with rule conditions, see Working with Rules.

You can use the Data Explorer tab to find fact types and value sets in the data model.

To add tests to a Decision Table:

1. From Rules Designer, select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to add the rule.
2. Click the Show Patterns/Tests button (magnifying glass) left of the Decision Table name. If Advanced Mode is selected, clear the check box.
3. Select any of the options according to your requirements, as shown in Figure 5-10. Note that variables without any tests are often used so that the variables can be used in the decision table conditions and actions.

   • simple test

   • variable

   • nested test

   • negated test

   • all of the following...

   • any of the following...

   • is a

   • there is a fact where...

   • there is a case where...

   • there is no fact where...

   • there is no case where...

   • aggregation...

   • boolean expression

   Figure 5-10 Options List

   
   Description of "Figure 5-10 Options List"
4. Click the left and the right <operand> to enter the operand values, and the operator list to select an operator, as in Figure 5-11:

   Figure 5-11 Value Options List

   
   Description of "Figure 5-11 Value Options List"

For more information about writing tests, see Testing and Validating Business Rules.

5.3 Introduction to Decision Table Operations

After you create a Decision Table you may want to modify the contents of the Decision Table to produce a Decision Table that includes a complete set of rules for all cases, or to produce a Decision Table that provides the least number of rules for the cases.

After you create a Decision Table there are operations that you may want to perform on the Decision Table, including the following:

• Compact or split cells in a Decision Table.

• Merge a condition or split a condition in a Decision Table.

• Finding and resolving conflicts between rules in a Decision Table.

• Find and fix gaps (missing rules) in a Decision Table.

5.3.1 Understanding Decision Table Split and Compact Operations

The split and compact operations enable you to manipulate the contents of the condition cells in a Decision Table.

The split table operation creates a rule for every combination of values across the conditions. For example, in a Decision Table with 3 boolean conditions, 2 x 2 x 2 = 8 rules are created. In a Decision Table with 32 boolean conditions, 2**32 ~ 2 billion rules are created. Thus, you only use split table when the number of rules created is small enough that filling in the action cells is feasible.

When you want to apply match conditions for the "do not care" values in a Decision Table and create a match case for each cell, you use the split table operation.

Split can be applied to an entire Decision Table or to a single condition row. Additionally, split may be performed on an individual condition cell.

Depending on what is selected in the Decision Table, the split operation can create condition cells. Thus, using the split operation you can create rules in a Decision Table. Table 5-3 summarizes the split operation for a selected condition cell, condition row, or for a complete Decision Table.

Table 5-3 Summary of Split Operation

Operator	Description
Condition Cell	Creates one sibling condition cell for each value represented by the cell. If the condition cell value is "do not care", then the cell is split into one sibling cell for each value in the valueset that is not represented by a sibling condition cell, and "do not care" is no longer represented.
Condition Row	For each condition cell in the proceeding condition expression, create a sibling group which contains a cell for each value in the value set. The effect of this operation is the same as adding a "do not care" to each sibling group and calling split on each condition cell in each sibling group.
Decision Table	Same as calling split on each condition row in the Decision Table.

Depending on what is selected in the Decision Table, the compact table or merge cells operations remove condition cells. The compact table operation can be applied to an entire Decision Table. Additionally, the merge operation may be performed on sibling cells or on an entire condition row. Thus, using compact table or merge you can remove rules from a Decision Table. Table 5-4 summarizes the compact table and merge operations.

Table 5-4 Summary of Merge Operation

Operator	Description
Condition Cell	Merging two or more condition cells adds all values in the cells to a single cell, and removes all but one of the cells. If one of the cells represents "do not care", then the merged cell represents "do not care". This operation may merge action cells and this can create warnings for duplicate action cells, such as, RUL-05847: Duplicate decision table action parameter.
Condition Row	Combine all values in each sibling group into a single "do not care" cell for each condition cell in the proceeding condition expression. The effect of this is the same as calling merge on all cells in each sibling group. This operation may merge action cells and this can create warnings for duplicate action cells, such as, RUL-05847: Duplicate decision table action parameter.
Decision Table	Compacts the Decision Table by merging conditions of rules with identical actions.

Split and merge are inverse operations when conflicting action cells are not associated with the operation. In this case, without conflicting action cells, a merge operation combines all the values from the siblings into one sibling, and discards the other sibling condition cells, and as a result of merging the condition cells, when a Decision Table contains action cells, the action cells are also merged. Thus, the merge operation combines multiple condition cells into a single condition cell and adds all values to the single cell.

When there are conflicting values for the action cells, a merge operation merges the action cells in a form that requires additional manual steps. Thus, if two action cells have conflicting parameters, after the merge the action cell contains multiple conflicting parameter values. These conflicting values are appended to the action cell and must be manually resolved by selecting and deleting the unwanted duplicate parameters. For example, see Figure 5-12 that shows conflicting values in an action cell.

An action cell that contains multiple values for a property is invalid. When you select the action cell Rules Designer shows a popup window with check boxes to allow you to select a single value for the action cell. As shown in the validation log in Figure 5-12, Rules Designer shows a validation warning until you select a single value.

Figure 5-12 Conflicting Properties to be Resolved for a Merged Action Cell

Description of "Figure 5-12 Conflicting Properties to be Resolved for a Merged Action Cell"

5.3.1.1 Understanding Decision Table Move Operations

You can move the conditions or actions in a Decision Table. The Move buttons let you reorder condition rows in the Conditions area and actions in the Actions area. Moving conditions up or down may reorder visual display of the rules, but these operations does not change the logic in any way. For example, if (x.a == 1 and x.b == 1) is logically the same as if (x.b == 1 and x.a == 1).

When you work with Decision Tables some operations only apply for condition cells that are siblings. Using the Move button you can reorder rows so that Decision Table operations apply to the tree at the desired granularity. For example, when you want to change the action of a condition cell for a single rule, then you need to move that condition cell to the last row in the Decision Table Conditions area. For example, consider the Decision Table shown in Figure 5-13.

Figure 5-13 Rules in a Decision Table

Description of "Figure 5-13 Rules in a Decision Table"

To view this table with granularity for the Driver.age, move the Driver.age condition from the first row to the third row, as shown in Figure 5-14.

Figure 5-14 Decision Table After Move Down with Age Condition Last

Description of "Figure 5-14 Decision Table After Move Down with Age Condition Last"

Now to make the Driver.age conditions "do not care" for the first two rules, where the driver passes the eyesight test and has had driver training is true, you can easily apply changes to these particular conditions when the Driver.age condition is in the last row. Thus, in this table, it is easier to view and modify age related rules when Driver.age is in the last row, with the finest granularity.In general, the move operations can assist you when you want to split, merge, or assign certain values that might only be appropriate at a particular level in the tree, depending on the location of a condition cell, or depending on the location of the parent, children, or siblings of a condition cell.

For actions in the Actions area, clicking Move Up or Move Down lets you reorder the actions. Actions are ordered so that when multiple actions apply, the first action runs before subsequent actions. Thus, using the Move Up or Move Down operation on an action may be appropriate, depending on your application.

5.3.1.2 Understanding Decision Table Gap Checking

A gap is a "missing" rule in a Decision Table. A Decision Table has a gap if there is a combination of values, one from each condition, that is not covered by an existing rule. Rules Designer provides Gap Checking to check for gaps. When you click the Gap Analysis button, Rules Designer finds gaps and presents a dialog to fix any gaps that are found.

You can choose to make existence of gaps a validation warning. When you clear Allow Gaps in the Advanced Settings area, the Decision Table reports a validation warning when a gap is found. For more information, see Using Advanced Settings with Rules and Decision Tables.

For example, using the Driver example if you create a gap by deleting the rule that covers the case for Driver.age < 20 and Driver.has_training false, and then you click Gap Analysis, Rules Designer shows the Gap Analysis dialog as shown in Figure 5-15. Clicking OK with the check boxes selected adds either all rules or the selected rules to the Decision Table (this example only shows a single rule to add).

Figure 5-15 Checking Gaps

Description of "Figure 5-15 Checking Gaps"

Gap checking generates different new rules for the following cases:

• Sibling rules: multiple missing sibling rules are added as a single new rule. For example, consider a rule with two conditions, Driver.age and Driver.hair. When there are two missing rules for different hair colors and the rules are siblings, that is, they have a common parent, then gap checking shows a single rule as shown in Figure 5-16.

• Non-sibling rules: multiple missing non-sibling rules are added as individual new rules. For example, when there are two different rules missing that do not have the same parent, then gap checking provides two rules, as shown in Figure 5-17.

Figure 5-16 Gap Checking with Missing Sibling Rules

Description of "Figure 5-16 Gap Checking with Missing Sibling Rules"

Figure 5-17 Gap Checking with Missing Non-Sibling Rules

Description of "Figure 5-17 Gap Checking with Missing Non-Sibling Rules"

In both of these cases shown in Figure 5-16 and Figure 5-17 there are two missing values, but for sibling rules the multiple values are combined in a single new rule. Thus, in general gap checking suggests fewer more general rules in preference to many more specific rules.

For sibling rules you can add multiple rules then edit each cell to pick the values you want. Alternatively, you can use Find Gaps to add a rule and then split the cell with multiple values, and delete the rules you do not want to keep.

5.3.1.3 Understanding Decision Table Conflict Analysis

The rules in a Decision Table can conflict. Two rules conflict when they overlap and they have different actions. Two rules overlap when at least one of their condition cells has a value in common. Overlap is common when a Decision Table contains "do not care" condition cells. Overlap without conflict is common and harmless.

Rules Designer finds conflicts and you can see the conflicts in the Conflict Resolution row in the Decision Table when you click Show Conflicts. How you handle and resolve conflicts depends on the specified conflict policy. You can choose a conflict policy or use the default manual conflict policy. When you set a conflict policy using the Conflict Policy option in the Advanced Settings area, Rules Designer sets the conflict policy for the Decision Table. The Conflict Policy specifies the Decision Table conflict policy and is one of the following:

• manual: Conflicts are resolved by manually specifying a conflict resolution for each conflicting rule.

• auto override: Conflicts are resolved automatically using an override conflict resolution when this is possible, using the Oracle Business Rules automatic conflict resolution policies.

• ignore: Conflicts are ignored.

For more information, see Using Advanced Settings with Rules and Decision Tables. For example, Figure 5-18 shows a Decision Table with conflicting rules that you resolve with the default manual conflict policy.

Figure 5-18 Decision Table Showing Conflicting Rules in the Conflicts Area

Description of "Figure 5-18 Decision Table Showing Conflicting Rules in the Conflicts Area"

By clicking on the cells in the Decision Table Conflict Resolution area Rules Designer lets you resolve conflicts between rules as follows:

• Override (Override and OverriddenBy): You override one rule with the other. Override specifies that one rule fires. Override is a combination of prioritization and mutual exclusion. Prioritization is transitive and not symmetric. Mutual exclusion is both transitive and symmetric. If A overrides C and B overrides C, then A or B runs before C but only one of A, B, or C runs.

• Run Before (RunBefore and RunAfter): You prioritize the rules. Run before lets the two rules fire in a prescribed order. Prioritization is transitive but not symmetric. That is, if A runs before B runs before C, then A runs before C but B does not run before A. This uses a Decision Table runBefore list specifying that the rule that runs before has a higher priority than rules in the list.

• Ignore (NoConflict): You OK the conflict. Ignore lets the two rules fire in arbitrary order. For example, consider the following conflicting rules in a decision table:

  rule1: everybody gets a 10% raise (as specified with a do not care value in a decision table condition cell)
  rule2: employee with Top Performer set to true gets a 5% raise
  

  In these rules, if rule2 overrides rule1, then a top performer gets a 5% raise, and everyone else gets a 10% raise. However, in this case, you would like to have both rules fire. Because it does not matter which rule fires first, and there is no conflict, then a top performer gets a 15.5% raise either way. In this case, use the NoConflict list to remove the conflict. Note that no conflict is what you get with IF/THEN rules with equal priorities, only you are not warned of a conflict and you have to think carefully if you want one rule to override the other.

Figure 5-19 shows the Rules Designer Conflict Resolution dialog shown when you select a conflicting rule in the Conflict Resolution area. This dialog lets you resolve conflicts between rules by selecting overrides, prioritization with RunBefore or RunAfter options, and a NoConflict option.

Figure 5-19 Using the Decision Table Conflict Resolution Dialog

Description of "Figure 5-19 Using the Decision Table Conflict Resolution Dialog"

You can use the Decision Table Advanced Settings Conflict Policy auto override option to specify that, where possible, conflicts are automatically resolved. The automatic override conflict resolution policy specifies that a special case overrides a more general case. For more information, see Using Advanced Settings with Rules and Decision Tables.

Thus, when there are conflicts in a Decision Table, you can do one or more of the following to resolve the conflicts:

• Use auto override conflict resolution by selecting the Conflict Policy and then auto override option in the Decision Table.

• Ignore conflicts by selecting the Conflict Policy and then ignore option in the Decision Table.

• Use manual conflict resolution by selecting the Conflict Policy and then manual option in the Decision Table and set Conflict Resolution for each conflicting rule in the dialog by selecting cells in the Conflict Resolution area with the Show Conflicts check box selected.

• Change the Decision Table to remove an overlap.

• Combine actions to remove conflicts.

5.3.2 How to Compact or Split a Decision Table

Use the Compact Table and Split Table buttons to compact or split cells in a Decision Table. For more information, see Understanding Decision Table Split and Compact Operations.

To compact or split cells in a decision table:

1. In Rules Designer, select a rule set from the Rule Sets navigation tab. On the Overview tab, select the Decision Table and click Edit.
2. Click the Compact Table button to compact or the Split Table button to split the cells.

5.3.3 How to Merge or Split Conditions in a Decision Table

Use the merge condition and split condition operations to merge or split a condition in a Decision Table. For more information, see Understanding Decision Table Split and Compact Operations.

To merge or split a condition in a decision table:

1. In Rules Designer, select a rule set from the Rule Sets navigation tab. On the Overview tab, select the Decision Table where you want to merge or split a condition and click Edit.
2. In the Conditions area, select the condition you want to merge or split.
3. Right-click, and from the list select Merge Condition or Split Condition.

5.3.4 How to Use the Condition Cell Operations

Use the condition cell operations to split a condition cell, to merge sibling condition cells, or to specify a "do not care" value for a condition cell in a Decision Table. For more information, see Understanding Decision Table Split and Compact Operations.

5.3.4.1 How to Merge Sibling Cells in a Condition in a Decision Table

1. In Rules Designer, select a rule set from the Rule Sets navigation tab. On the Overview tab, and select the Decision Table where you want to merge condition cells and click Edit.
2. Select the sibling condition cells to merge.
3. Right-click, and from the list select Merge selected cells.

5.3.4.2 How to Split a Cell in a Condition in a Decision Table

1. In Rules Designer, select a rule set from the Rule Sets navigation tab. On the Overview tab, and select the Decision Table where you want to split a condition cell and click Edit.
2. Select the cell to split.
3. Right-click, and from the list select Split selected cell.

5.3.4.3 How to a "Do Not Care" Value for a Cell in a Condition in a Decision Table

1. From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to set the "do not care" value.
2. Select the appropriate condition cell.
3. Right-click, and from the list select Do Not Care.

5.3.4.4 How to Select all Value Sets to Specify a "Do Not Care" Value for a Cell in a Condition:

1. In Rules Designer, select a rule set from the Rule Sets navigation tab. On the Overview tab, and select the Decision Table where you want to set the "do not care" value and click Edit.
2. Select the appropriate condition cell.
3. Double-click, and from the list select all the available check boxes for all possible values.

5.3.5 How to Perform Decision Table Gap Checking

A gap is a "missing" rule in a Decision Table. A Decision Table has a gap if there is a combination of values, one from each condition, that is not covered by an existing rule. Rules Designer provides Gap Checking to check for gaps. When you use this operation Rules Designer presents a window to fix gaps. For more information, see Understanding Decision Table Gap Checking.

You can choose to make existence of gaps a validation warning. When you clear Allow Gaps in the Advanced Settings area, the Decision Table reports a validation warning when a gap is found. For more information, see Using Advanced Settings with Rules and Decision Tables.

To perform decision table gap checking:

1. In Rules Designer, select a rule set from the Rule Sets navigation tab. On the Overview tab, and select the Decision Table where you want to perform gap checking and click Edit.
2. Click the Gap Analysis button.

5.3.6 How to Perform Decision Table Manual Conflict Resolution

The rules in a Decision Table can conflict. Two rules conflict when they overlap and they have different actions. Two rules overlap when at least one of their condition cells has a value in common. For more information, see Understanding Decision Table Conflict Analysis.

To perform manual decision table conflict resolution:

1. In Rules Designer, select a rule set from the Rule Sets navigation tab. On the Overview tab, and select the Decision Table where you want to check conflicts and click Edit.
2. Set the conflict policy to manual (this is the default conflict policy). For more information, see Understanding Decision Table Conflict Analysis.
3. In the Conditions area, in the conflicts area, when conflicts exist for each rule with a conflict double-click the appropriate condition cell to display the Conflict Resolution dialog.
4. In the Conflict Resolution dialog, for each conflicting rule, in the Resolution field select a resolution from the list.

5.3.7 How to Set the Decision Table Auto Override Conflict Resolution Policy

When you select the Advanced Settings option in a Decision Table, you can select that Decision Table conflicts are automatically resolved using the auto override conflict policy (this applies only when it is possible to resolve the conflict using the Oracle Business Rules automatic conflict resolution policies). The automatic override conflict resolution uses a policy where when there is a rule conflict a special case overrides a more general case. For more information, see Understanding Decision Table Conflict Analysis.

To select the auto override policy:

1. Select the rule or Decision Table where you want to use ignore conflict policy.
2. Click the Show Advanced Settings button next to the rule or Decision Table name.
3. From the Conflict Policy option select auto override.

5.3.8 How to Set the Decision Table Ignore Conflicts Policy

When you select the Advanced Settings option in a Decision Table, you can select that the Decision Table conflicts are ignored using the ignore conflict policy. The ignore policy tells Oracle Business Rules to ignore conflicts in the Decision Table. For more information, see Understanding Decision Table Conflict Analysis.

To select the ignore conflict policy:

1. Select the rule or Decision Table where you want to use the ignore conflicts policy.
2. Click the Show Advanced Settings button next to the rule or Decision Table name.
3. From the Conflict Policy option select ignore.

5.4 Creating and Running an Oracle Business Rules Decision Table Application

The Order Approval application demonstrates the integration of a SOA composite application with Oracle Business Rules and the use of a Decision Table.

In this application a process is modeled that uses the decision component to:

• Process rules from XML inputs including: a credit score and the annual spending of a customer, and the total cost of the incoming order.

• Provide output that determines if an order is approved, rejected, or requires manual processing.

To complete this procedure, you need to:

• Obtain the Source Files for the Order Approval Application

• Create an Application for Order Approval

• Create a Business Rule Service Component for Order Approval

• View Data Model Elements for Order Approval

• Add Value Sets to the Data Model for Order Approval

• Associate Value Sets with Order and CreditScore Properties

• Add a Decision Table for Order Approval

  • Split the Cells in the Decision Table and Add Actions

  • Compact the Decision Table

  • Replace Several Specific Rules with One General Rule

  • Add a General Rule

• Check Dictionary Business Rule Validation Log for Order Approval

• Deploy the Order Approval Application

• Test the Order Approval Application

5.4.1 How to Obtain the Source Files for the Order Approval Application

The source code for Oracle Business Rules-specific samples and SOA samples are available online in the Oracle SOA Suite samples page.

To work with the Order Approval application, you first need to obtain the order.xsd schema file either from the sample project that you obtain online or you can create the schema file and create all the application, project, and other files in Oracle JDeveloper. You can save the schema file provided in the following example locally to make it available to Oracle JDeveloper.

The following example shows the order.xsd schema file.

<?xml version="1.0" ?>
<schema attributeFormDefault="qualified" elementFormDefault="qualified"
        targetNamespace="http://example.com/ns/customerorder"
        xmlns:tns="http://example.com/ns/customerorder"
        xmlns="http://www.w3.org/2001/XMLSchema">
  <element name="CustomerOrder">
    <complexType>
      <sequence>
        <element name="name" type="string" />
        <element name="creditScore" type="int" />
        <element name="annualSpending" type="double" />
        <element name="value" type="string" />
        <element name="order" type="double" />
      </sequence>
    </complexType>
  </element>
  <element name="OrderApproval">
    <complexType>
      <sequence>
        <element name="status" type="tns:Status"/>
      </sequence>
    </complexType>
  </element>
  <simpleType name="Status">
    <restriction base="string">
        <enumeration value="manual"/>
        <enumeration value="approved"/>
        <enumeration value="rejected"/>
    </restriction>
  </simpleType>
 </schema>

5.4.2 How to Create an Application for Order Approval

To work with Oracle Business Rules, you first create an application in Oracle JDeveloper.

To create an application for order approval:

1. In the Application Navigator, click New Application.

2. In the Name your application dialog, enter the name and location for the new application.

   1. In the Application Name field, enter an application name. For example, enter OrderApprovalApp.

   2. In the Directory field, specify a directory name or accept the default.

   3. In the Application Package Prefix field, enter an application package prefix, for example com.example.order.

      The prefix, followed by a period, applies to objects created in the initial project of an application.

   4. For a SOA composite with Oracle Business Rules, in the Application Template area select SOA Application for the application template. For example, see Figure 5-20.

   5. Click Next.

      Figure 5-20 Adding the Order Approval Application

      
      Description of "Figure 5-20 Adding the Order Approval Application"

3. In the Name your project page enter the name and location for the project.

   1. In the Project Name field, enter a name. For example, enter OrderApproval.

   2. Enter or browse for a directory name, or accept the default.

   3. For an Oracle Business Rules project, in the Project Technologies area ensure that SOA, ADF Business Components, Java, and XML are in the Selected area on the Project Technologies tab, as shown in Figure 5-21. If an item is missing, select it in the Available pane and add it to the Selected pane using the Add button.

      Figure 5-21 Adding a Project to an Application

      
      Description of "Figure 5-21 Adding a Project to an Application"

4. Click Finish.

5.4.3 How to Create a Business Rule Service Component for Order Approval

After creating a project in Oracle JDeveloper you need to create a Business Rule Service component within the project. When you add a business rule you can create input and output variables to provide input to the service component and to obtain results from the service component.

To use business rules with Oracle JDeveloper, you do the following:

• Add a business rules service component

• Create input and output variables for the service component

• Create an Oracle Business Rules dictionary in the project

To create a business rule service component:

1. In the Application Navigator, in the OrderApproval project expand SOA Content and double-click composite.xml to launch the SOA composite editor (this may already be open after you create the project).
2. From the Component Palette, drag-and-drop a Business Rule from the Service Components area of the SOA menu to the Components lane of the composite.xml editor.

   Oracle JDeveloper displays a Create Business Rules page, as shown in Figure 5-22.

   Figure 5-22 Adding a Business Rule Dictionary with the Create Business Rules Dialog

   
   Description of "Figure 5-22 Adding a Business Rule Dictionary with the Create Business Rules Dialog "
3. To add an input, from the list next to the Add button select Input to enter input for the business rule.
4. In the Type Chooser dialog, click the Import Schema File... button. This displays the Import Schema File dialog.
5. In the Import Schema dialog click Browse Resources to choose the XML schema elements for the input variable of the process. This displays the SOA Resource Lookup dialog.
6. In the SOA Resource Lookup dialog, navigate to find the order.xsd schema file and click OK.
7. In the Import Schema File dialog, make sure Copy to Project is selected, as shown in Figure 5-23. Click OK.

   Figure 5-23 Importing the Order.xsd Schema File

   
   Description of "Figure 5-23 Importing the Order.xsd Schema File"
8. If the Localize Files dialog displays, click OK to copy the schema to the composite process directory.
9. In the Type Chooser, navigate to the Project Schemas Files folder to select the input variable.

   For this example, select CustomerOrder as the input variable.

   On the Type Chooser window, click OK. This displays the Create Business Rules dialog, as shown in Figure 5-24.

   Figure 5-24 Create Business Rules Dialog with CustomerOrder Input

   
   Description of "Figure 5-24 Create Business Rules Dialog with CustomerOrder Input"
10. In a similar manner, add the output fact type OrderApproval from the imported order.xsd.
11. In the Create Business Rules dialog, select Expose as Composite Service, as shown in Figure 5-25.

    Figure 5-25 Create Business Rules Dialog with Input and OrderApproval Output

    
    Description of "Figure 5-25 Create Business Rules Dialog with Input and OrderApproval Output"

    Click OK. This creates the Business Rule component and Oracle JDeveloper shows the Business Rule in the canvas workspace, as shown in Figure 5-26.

    Figure 5-26 Business Rules Component in OrderApproval Composite

    
    Description of "Figure 5-26 Business Rules Component in OrderApproval Composite"

The business rule service component enables you to integrate your SOA composite application with a business rule. This creates a business rule dictionary and enables you to execute business rules and make business decisions based on the rules.

5.4.4 How to View Data Model Elements for Order Approval

Before adding rules you need to create the Oracle Business Rules data model. The data model contains the business data definitions (types) and definitions for facts that you use to create rules. For example, for this sample the data model includes the XML schema elements from order.xsd that you specify when you define inputs and outputs for the business rule activity.

At times when you work with Rules Designer to create a rule or a Decision Table, you may need to create or modify elements in the data model.

To view data model elements for Oracle business rules:

1. Select the composite tab with the value composite.xml, and in the Components lane select the business rule (this surrounds the component, OracleRules1 with a dashed selection box).
2. Double-click the selection box to launch Rules Designer.
3. In Rules Designer select the Facts navigation tab.
4. Select XML Facts tab in the Facts navigation tab as shown in Figure 5-27.

   Figure 5-27 Opening a Business Rules Dictionary with Rules Designer

   
   Description of "Figure 5-27 Opening a Business Rules Dictionary with Rules Designer"

5.4.5 How to Add Value Sets to the Data Model for Order Approval

To use a Decision Table you need to define value sets that specify how to draw values for each cell for the conditions that constitute the Decision Table. For this example the value sets are defined with a list of ranges that you define in Rules Designer.

To add OrderAmount value set to the data model:

1. In Rules Designer, select the Value Sets navigation tab.
2. From the drop down next to the Create Value Set... button, select Range Value Set.
3. In the Name field, enter OrderAmount. Press Enter to accept the name.
4. Double-click the OrderAmount value set icon to display the Edit Range Value Set dialog.
5. Click Add Value to add a value.
6. Click Add Value again to add another value.
7. In the Range Values area, in the top Endpoint field enter 1000 for the endpoint value.
8. In the Range Values area, for the middle bucket in the Endpoint field enter 500 for the endpoint value.
9. In the Included Endpoint field for each value set ensure the check box is selected, as shown in Figure 5-28.

   Figure 5-28 Adding the OrderAmount Value Set

   
   Description of "Figure 5-28 Adding the OrderAmount Value Set"
10. Modify the Alias field for each value to High, Medium, and Low. Click OK.

5.4.5.1 How to Add CreditScore Value Set to the Data Model

To add CreditScore value set:

1. In Rules Designer select the Value Sets navigation tab.
2. From the drop down next to the Create Valueset... button, select List of Ranges.
3. In the Name field, enter CreditScore.
4. Double-click the CreditScore valueset icon to display the Edit Valueset dialog.
5. Click Add Value to add a value.
6. Click Add Value again to add another value.
7. In the top valueset, in the Endpoint field enter 750.
8. For the middle valueset, in the Endpoint field enter 400.
9. In the Included Endpoint field for each valueset, ensure the check box is selected.
10. Modify the Alias field for each endpoint value to solid for 750, avg for 400, and risky for -Infinity. Click OK.

5.4.6 How to Associate Value Sets with Order and CreditScore Properties

To prepare for creating Decision Tables you can associate a value set with fact properties in the data model. In this way condition cells in a Decision Table Conditions area can use the valuesets when you create a Decision Table.

Note that the OrderApproval.status property is associated with the Status value set when the OrderApproval fact type is imported from the XML schema. In the schema, Status is a restricted String type and is therefore represented as an enum valueset. Rules Designer creates the status value set. For more information, see What You Need to Know About XML Facts.

To associate value sets with Order and CreditScore properties:

1. In Rules Designer select the Facts navigation tab.
2. Select the XML Facts tab in the Facts navigation tab as shown in Figure 5-29.

   Figure 5-29 Opening a Business Rules Dictionary with Rules Designer

   
   Description of "Figure 5-29 Opening a Business Rules Dictionary with Rules Designer"
3. Select the type you want to modify. For example in the XML Facts table double-click the icon next to the CustomerOrder entry. This displays the Edit XML Fact dialog.
4. In the Edit XML Fact dialog, in the Properties table in the Value Set column select the cell for the appropriate property and from the list select the valueset you want to use. For example, for the property order select the OrderAmount valueset, as shown in Figure 5-30.

   Figure 5-30 Associating the OrderAmount Valueset with CustomerOrder.order

   
   Description of "Figure 5-30 Associating the OrderAmount Valueset with CustomerOrder.order"
5. In a similar manner, for the property creditScore select the CreditScore valueset.
6. Click OK.

5.4.7 How to Add a Decision Table for Order Approval

You create a Decision Table to process input facts and to produce output facts, or to produce intermediate conclusions that Oracle Business Rules can further process using additional rules or in another Decision Table.

While you work with rules you can use the rule validation features in Rules Designer to assist you. Rules Designer performs dictionary validation when you make any change to the dictionary. To show the validation log window, click the Validate button or select View>Log and select the Business Rule Validation tab. If you view the rules validation log you should see warning messages. You remove these warning messages as you create the Decision Table. For more information on rule validation see Understanding Rule Validation.

To use a Decision Table for rules in this sample application you work with facts representing a customer spending level and a customer credit risk for a particular customer and a particular order. Then, you use a Decision Table to create rules based on customer spending, the order amount, and the credit risk of the customer.

To add a Decision Table for order approval:

1. In Rules Designer, select Ruleset_1 under the Rulesets navigation tab.
2. Click the Add button and from the list and select Create Decision Table.
3. In the Decision Table, click the Add button and from the list select Condition.
4. In the Decision Table, double-click <edit condition>. Then, in the navigator expand CustomerOrder and select creditScore. This enters the expression CustomerOrder.creditScore in the Conditions column.
5. Again, in the Decision Table, click the Add button and from the list select Condition.
6. In the Decision Table, in the Conditions area double-click the <edit condition>. Then, in the navigator expand CustomerOrder and select order. This enters the expression CustomerOrder.order.
7. Again, in the Decision Table, click the Add button and from the list select Condition.
8. In the Decision Table, double-click <edit condition>.
9. In the navigator expand CustomerOrder and select annualSpending. In the text entry area, add >2000 as shown in Figure 5-31.

   Figure 5-31 Adding the Annual Spending Entry to a Decision Table

   
   Description of "Figure 5-31 Adding the Annual Spending Entry to a Decision Table"
10. Type Enter to accept the value, as shown in Figure 5-32. If you view the rules validation log you should see the warning messages as shown in Figure 5-32. You remove these warning messages as you modify the Decision Table in later steps.

    Figure 5-32 Adding Conditions to the CustomerOrder Decision Table

    
    Description of "Figure 5-32 Adding Conditions to the CustomerOrder Decision Table"

5.4.7.1 How to Create an action in a Decision Table

To create an action in a Decision Table:

1. In the Decision Table click the Add button and from the list select Action > Assert New.
2. In the Actions area, double-click assert new(. This displays the Action Editor dialog.
3. In the Action Editor dialog, in the Facts area select OrderApproval.
4. In the Action Editor dialog, in the Properties table for the property status select the Parameterized check box and the Constant check box. This specifies that each rule independently sets the status.
5. In the Action Editor dialog, select the Always Selected check box as shown in Figure 5-33.

   Figure 5-33 Adding an Action to a Decision Table with the Action Editor Dialog

   
   Description of "Figure 5-33 Adding an Action to a Decision Table with the Action Editor Dialog"
6. In the Action Editor dialog, click OK.

Next you need to add rules to the Decision Table and specify an action for each rule.

5.4.7.2 Split the Cells in the Decision Table and Add Actions

You can use the Decision Table split operation to create rules for the valuesets associated with the condition rows in the Decision Table. This creates one rule for every combination of condition valuesets. There are three order amount valuesets, three credit score valuesets, and two boolean valuesets for the annual spending amount for a total of eighteen rules (3 x 3 x 2 = 18).

To split cells in a decision table:

1. Select the Decision Table.
2. In the Decision Table, click the Split Table button and from the list select Split Table. The split table operation eliminates the "do not care" cells from the table. The table now shows eighteen rules that cover all ranges as shown in Figure 5-34.

These steps produce validation warnings for action cells with missing expressions. You fix these in later steps.

Figure 5-34 Splitting a Decision Table Using Split Table Operation

Description of "Figure 5-34 Splitting a Decision Table Using Split Table Operation"

5.4.7.3 How to Add Actions for Each Rule in the Decision Table

In the Decision Table you specify a value for the status property associated with OrderApproval for each action cell in the Actions area. The possible choices are: Status.MANUAL, Status.REJECTED, or Status.ACCEPTED. In this step you fill in a value for status for each of the 18 rules. The values you enter correspond to the conditions that form each rule in the Decision Table.

To add actions for each rule in the decision table:

1. In the Actions area, double-click the action cell for the rule you want to work with, as shown in Figure 5-35.

   Figure 5-35 Adding Action Cell Values to a Decision Table

   
   Description of "Figure 5-35 Adding Action Cell Values to a Decision Table"
2. In the list, select and enter a value for the action cell. For example, enter Status.MANUAL.
3. For each action cell, enter the appropriate value as determined by the logic of your application. For this sample application use the values for the Decision Table actions as shown in Table 5-5.
4. Select Save All from the File main menu to save your work.

Table 5-5 Values for Decision Table Actions

Rule	C1 creditScore	C2 order	C3 annualSpending > 2000	A1 OrderApproval status
R1	risky	Low	true	Status.MANUAL
R2	risky	Low	false	Status.MANUAL
R3	risky	Medium	true	Status.MANUAL
R4	risky	Medium	false	Status.REJECTED
R5	risky	High	true	Status.MANUAL
R6	risky	High	false	Status.REJECTED
R7	avg	Low	true	Status.APPROVED
R8	avg	Low	false	Status.MANUAL
R9	avg	Medium	true	Status.APPROVED
R10	avg	Medium	false	Status.MANUAL
R11	avg	High	true	Status.MANUAL
R12	avg	High	false	Status.MANUAL
R13	solid	Low	true	Status.APPROVED
R14	solid	Low	false	Status.APPROVED
R15	solid	Medium	true	Status.APPROVED
R16	solid	Medium	false	Status.APPROVED
R17	solid	High	true	Status.APPROVED
R18	solid	High	false	Status.MANUAL

5.4.7.4 Compact the Decision Table

In this step you compact the rules to merge from eighteen rules to nine rules. This automatically eliminates the rules that are not needed and preserves the no gap, no conflict properties for the Decision Table.

To compact the decision table:

1. Select the Decision Table.
2. Click the Resize All Columns to Same Width button.
3. Click the Compact Table button and from the list select Compact Table. The compact table operation eliminates rules from the Decision Table. The Decision Table now shows nine rules, as shown in Figure 5-36.

Figure 5-36 Compacting a Decision Table Using Compact Table

Description of "Figure 5-36 Compacting a Decision Table Using Compact Table"

5.4.7.5 Replace Several Specific Rules with One General Rule

Notice that five of the nine remaining rules result in a manual order approval status. You can reduce the number of rules by deleting these five rules. Note it is often best practice to not do this (that is not replace several specific rules with one general rule). You need to compare the benefits of having fewer rules with the added complexity of managing the conflicts introduced when you reduce the number of rules.

To replace several specific rules with one general rule:

1. Select the Decision Table.
2. In the Decision Table, select a rule with OrderApproval status action set to Status.MANUAL. To select a rule, click the column heading. For example, click rule R2 as shown in Figure 5-37.
3. Click Delete to remove a rule in the Decision Table. Be careful to click the delete button in the Decision Table area to delete a rule in the decision table (there is also a delete button shown in the Ruleset area that deletes the complete Decision Table).

   Figure 5-37 Deleting Rules from a Decision Table

   
   Description of "Figure 5-37 Deleting Rules from a Decision Table"
4. Repeat these steps to delete all the rules with action set to Status.MANUAL. This should leave the Decision Table with four rules as shown in Figure 5-38.

   Figure 5-38 Decision Table After Manual Actions Removed

   
   Description of "Figure 5-38 Decision Table After Manual Actions Removed"

5.4.7.6 Add a General Rule

Now you can add a single rule to handle the manual case. After adding this rule you set the conflict policy with the option Conflict Policy auto override for conflict resolution.

To add a general rule:

1. In the Decision Table, click the Add button and from the list select Rule.
2. In the Conditions area, for the three conditions leave the "-" do not care value for each cell in the rule.
3. In the Actions area, enter Status.MANUAL, as shown in Figure 5-39. Notice that the Business Rule Validation log includes the warning RUL-05851 for unresolved conflicts.

   Figure 5-39 Decision Table with Conflicting Rules

   
   Description of "Figure 5-39 Decision Table with Conflicting Rules"
4. Show the conflicting rules by clicking the Toggle Display of Conflict Resolution button, as shown in Figure 5-40.

   Figure 5-40 Adding a Rule to Handle Status Manual

   
   Description of "Figure 5-40 Adding a Rule to Handle Status Manual"

5.4.7.7 How to Enable the Auto Override Conflict Resolution Policy

To enable the auto override conflict resolution policy:

1. In the Decision Table click Show Advanced Settings (next to the Decision Table name).
2. In the Conflict Policy list, select auto override. After adding the manual case rule and selecting auto override, notice that the conflicts are resolved and special cases override the general case, as shown in Figure 5-41.

   Figure 5-41 Adding a Rule to Handle Status Manual with Auto Override Conflict Policy

   
   Description of "Figure 5-41 Adding a Rule to Handle Status Manual with Auto Override Conflict Policy"

5.4.8 How to Check the Business Rule Validation Log for Order Approval

Before you can deploy the application you need to make sure the dictionary validates without warnings. If there are any validation warnings, you need to fix any associated problems. To validate the dictionary, in the Business Rule Validation Log, check for any validation warnings. If there are warnings, perform appropriate actions to correct the problems.

5.4.9 How to Deploy the Order Approval Application

Business rules created in a SOA application are deployed as part of the SOA composite when you create a deployment profile in Oracle JDeveloper. You deploy a SOA composite application to Oracle WebLogic Server.

To deploy and run the order approval application:

1. If you have not started your application server instance, then start the Oracle WebLogic Server.
2. In the Application Navigator, right-click the OrderApproval project and select Deploy > OrderApproval > to the appropriate server name.

   Then the SOA Deployment Configuration dialog displays. Select your Application connection which you either have created already or you can create it now. The connection contains the authorization and other connection information (server name, port, etc).

3. Click Next.
4. In Select Server select or create and then select your application connection.
5. Click Next, Next and Finish.

5.4.10 How to Test the Order Approval Application

After deploying the application you can test the Decision Table in the SOA composite application with the Oracle Enterprise Manager Fusion Middleware Control Console.

To test the application:

1. Open the composite application in Oracle Enterprise Manager Fusion Middleware Control Console, as shown in Figure 5-42.

   Figure 5-42 Testing the Order Approval Application

   
   Description of "Figure 5-42 Testing the Order Approval Application"
2. Click Test.
3. In the Input Arguments area, select XML View. Replace the XML with the contents of the sample input for testing Order Approval application example as shown below.

   <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
      <soap:Body xmlns:ns1="http://xmlns.oracle.com/OracleRules1/OracleRules1_DecisionService_1">
           <ns1:callFunctionStateless name="OracleRules1_DecisionService_1">
                      <ns1:parameterList xmlns:ns3="http://example.com/ns/customerorder">
                              <ns3:CustomerOrder>
                                      <ns3:name>Gary</ns3:name>
                                          <ns3:creditScore>600</ns3:creditScore>
                                          <ns3:annualSpending>2001.0</ns3:annualSpending>
                                          <ns3:value>High</ns3:value>
                                          <ns3:order>100.0</ns3:order>
                       </ns3:CustomerOrder>
                      </ns1:parameterList>
              </ns1:callFunctionStateless>
          </soap:Body>
   </soap:Envelope> 
   

4. Replace the values in the input shown in step 3 as desired for your test.
5. Click Test Web Service.
6. In the Response tab, view the results. For example, for this input:

   /OracleRules1_DecisionService_1" xmlns:ns2="http://xmlns.oracle.com/bpel">
         <resultList>
             <OrderApproval:OrderApproval      xmlns:OrderApproval="http://example.com/ns/customerorder"
   xmlns="http://example.com/ns/customerorder">
                 <status>approved</status>
             </OrderApproval:OrderApproval>
          </resultList>
     </callFunctionStatefulDecision>
   

5.5 Editing Decision Tables in Microsoft Excel

Business users may find that editing Decision Tables is easier to do in Microsoft Excel. New functionality enables both developers and business users to export and edit Decision Tables in Excel and then import the Decision Tables back into the dictionary.

You can export and edit Decision Tables at design-time in Oracle JDeveloper or Business Process Composer. At runtime, you can export and edit in SOA Composer. You can export one or more Decision Tables from a Rule dictionary to the same Excel workbook.

When you import back into the dictionary, you can create a new dictionary, overwrite the existing dictionary, or perform a Diff-Merge. The Diff-Merge enables you to compare dictionaries and accept (merge) or reject any differences.

For more information about comparing dictionaries, see How to Compare or Merge Two or More Dictionaries.

The Excel workbook structure consists of several worksheets: a Readme sheet, a Value Set sheet, and one sheet for each exported Decision Table, as shown in Figure 5-43. Only Rules and Value Sets can be edited in Excel. You can export to .xlsm (default) or .xls.

Figure 5-43 Microsoft Excel Workbook

Description of "Figure 5-43 Microsoft Excel Workbook"

When you open the Excel workbook, the macros are disabled by default. If you enable the macros, a new tab called Oracle Business Rules, appears. This tab enables you to add or delete rules, merge or split cells, and add or remove values from value sets. You can also disable or enable highlighting, use a simple or advanced mode and hide or show the Readme worksheet.

You can edit with the macros disabled, though you will not be able to:

• Choose values from drop lists for restricted cells.

• Edit free form cells.

• Copy and paste a range of cells to add a rule or Value Set.

• Delete a range of cells to delete a rule or Value Set.

• Split or merge cells.

• Create Value Sets automatically.

• Validate the structure of Decision Tables or Value Sets.

Using the predefined macros, you can:

• Add and delete rules.

• Split or merge cells.

• Add or delete Value Sets.

• Editable cells include:

  • Description for Rules, Conditions, Actions.

  • Condition and Action nodes.

  • Action state.

  • Parameterized options for Action parameters.

• Non-editable cells include:

  • Condition expressions.

  • Action expressions.

  • Action parameters.

  If you try to edit these cells, you will get an error message, as shown in Figure 5-44.

  Figure 5-44 Non-Modifiable Cell

  
  Description of "Figure 5-44 Non-Modifiable Cell"

5.5.1 Understanding What is Exported

In the SDK, there are shared Value Sets that can be associated with multiple conditions across Decision Tables. However, in Excel there are no shared Value Sets--each condition has its own Value Set--so you can only export a Value Set if it is modifiable in Excel. The Value Sets that are non-modifiable include:

• Linked Dictionary Value Sets.

• Enums.

• Internal Value Sets, for example, boolean Value Sets.

In the worksheet, you can only select values from the drop down for the conditions associated with non-modifiable Value Sets. A highlighting mechanism informs you which conditions are associated with non-modifiable Value Sets.

5.5.2 How to Export Decision Tables

The export and import functionality is invoked using the toolbar button, as shown in Figure 5-45.

Figure 5-45 Export and Import Toolbar Button

Description of "Figure 5-45 Export and Import Toolbar Button"

To export Decision Table:

1. In Rules Designer, click Export to Excel.
2. In the Export to Excel dialog box, select the Format and browse to the folder where you want to save the workbook.
3. Click Add and select the Decision Table(s) to export and click OK.
4. Check the Read Only Value Set check box to make all of the value sets read-only in Excel. There will not be any Value Sets sheet in the Excel workbook. All conditions will have drop down menus from which values can be selected but no values can be added or removed.
5. Click Export. You can now open the workbook and edit the Decision Table.

5.5.3 How to Import Edited Decision Tables Back to the Dictionary

The export and import functionality is invoked using the toolbar button, as shown in Figure 5-45. You can only import Excel workbooks that have been previously exported.

To import edited Decision tables:

1. In Rules Designer, click Import from Excel.
2. In the Import from Excel dialog box, select the File to browse to the folder where you saved the workbook.
3. The Perform Diff-Merge on Import check box is selected by default. Browse to the Base Dictionary that you want to compare your file to. The base dictionary is required for a 3 way diff-merge.
4. Clear the Perform Diff-Merge on Import check box and select Create New or Overwrite.
5. Click Import. The decision table is imported into Rules Designer, where you can accept or reject changes, as shown in Figure 5-46. Each changed artifact is flagged with a change icon. Merging dictionaries should be done with caution.

   For more information about using the Diff-Merge, see How to Compare or Merge Two or More Dictionaries.

   Figure 5-46 Perform Diff-Merge on Import

   
   Description of "Figure 5-46 Perform Diff-Merge on Import"

5.5.4 How to Edit Decision Tables in Excel

In Excel, enable the macros to view the Oracle Business Rules tab, which provides you with options to author rules, edit Value Sets, and set preferences.

5.5.4.1 Adding or Deleting Rules and Merging or Splitting Cells

For each Decision Table worksheet, you can add a rule, as shown in Figure 5-47, delete rules, and merge or split cells.

Figure 5-47 Oracle Business Rules tab in Excel

Description of "Figure 5-47 Oracle Business Rules tab in Excel"

5.5.4.2 Adding or Removing Value Sets

In the ValueSets tab, you can add or remove Value Sets, as shown in Figure 5-48. Depending on the cell you click in, your options will vary: endpoints or values.

Figure 5-48 Value Sets Worksheet

Description of "Figure 5-48 Value Sets Worksheet"

5.5.4.3 Showing or Hiding Value Sets and Editing the Description

On the Value Sets worksheet, right click and select Show/Hide Values to toggle between viewing or hiding values as shown in Figure 5-49. You can also right click and select Edit Bucket Description to change the description.

Figure 5-49 Show/Hide Value Sets

Description of "Figure 5-49 Show/Hide Value Sets"

5.5.4.4 Setting Preferences

In the Value Sets tab, click Enable Highlighting or Disable Highlighting, as shown in Figure 5-50.

Figure 5-50 Enabling Highlighting

Description of "Figure 5-50 Enabling Highlighting"

5.5.4.5 Using Simple or Advanced Mode

In your worksheet, click Simple Mode or Advanced Mode to toggle between the two modes.

Simple mode displays only the descriptions of conditions and actions and not the actual expressions. Also, action parameters are displayed, but you cannot specify them as fixed or variable.

Advanced mode displays both the descriptions and expressions for conditions and actions, as shown in Figure 5-51. Also, you can specify the action parameter type from fixed and variable, which is equivalent to specifying "Parameterized/Constant" in the SDK.

Figure 5-51 Advanced Mode

Description of "Figure 5-51 Advanced Mode"

5.5.4.6 Hiding or Showing the Readme Worksheet

Click Hide or Show ReadMe Sheet to toggle between the modes, as shown in Figure 5-52. The ReadMe worksheet provides helpful information about how to use the features on the Oracle Business Rules tab.

Figure 5-52 Show/Hide Readme

Description of "Figure 5-52 Show/Hide Readme"

5.5.4.7 Editing Condition Cells

You can choose from the drop down or use auto-addition to add new values, shown in Figure 5-53. For some of the condition cells, you can only choose values from the drop down menu. These cells have been differentiated by using color code. Any conditions you change between a Value Set or Decision Table are automatically synced.

Figure 5-53 Editing Conditions

Description of "Figure 5-53 Editing Conditions"

5.5.4.8 Editing Actions

You can select the action state (active/inactive) from the drop down, as shown in Figure 5-54.

Figure 5-54 Editing Action States

Description of "Figure 5-54 Editing Action States"

5.5.4.9 Editing Expressions

You can edit the values of action expression cells. Use care to maintain the validity of these cells when editing.

5.5.4.10 Editing Action Expression Parameters

You can make action parameters fixed or variable, as shown in Figure 5-55. If the action parameter is fixed, then all the rules will have the same value for that particular parameter. If the action parameter is variable, then different rules can have different values for that particular parameter.

Figure 5-55 Editing Action Expression Parameters

Description of "Figure 5-55 Editing Action Expression Parameters"

5.5.4.11 Editing Descriptions

You can edit descriptions for actions, conditions, and rules. If the description is not provided for any of the action or condition or rule then it will be defaulted to "A", "C" or "R" followed by a number which denotes its position in the decision table, respectively.

Figure 5-56 Editing Descriptions

Description of "Figure 5-56 Editing Descriptions"

5.5.4.12 Using the Auto-Addition Feature

You can add values in the value sets in two ways:

1. Go to the specific value set in the value sets worksheet. In the Oracle Business Rules tab, click Add Bucket.
2. Enter a value (in case of LOV valuesets) or end point (in case of Range valuesets) in the condition cell. This is called auto-addition as the value will be automatically added to the corresponding value set, as shown in Figure 5-57.

   Figure 5-57 Entering a Value in the Condition Cell

   
   Description of "Figure 5-57 Entering a Value in the Condition Cell"

   The value set above has three values: – 1) <18 , 2) [18..60) , and 3) >=60.

3. To add a new value, for example, [18..30] and (30..60), type 30 in the cell as shown in Figure 5-58 and press Enter.

   Figure 5-58 Adding a New Value

   
   Description of "Figure 5-58 Adding a New Value"
4. After you press enter, the value will be added to the value set and will be shown in the drop-down as shown in Figure 5-59.

   Figure 5-59 Value is Auto-Added

   
   Description of "Figure 5-59 Value is Auto-Added"

   Various highlighting techniques are used to inform you about auto-added values in the value set, see the following examples. The comment and the highlighting of the value is removed after you select another value for any other rule for that condition or if a new value is added in the same value set.

   The first is to highlight the newly added value in the value set sheet as shown in Figure 5-60.

   Figure 5-60 Highlighted Value Set

   
   Description of "Figure 5-60 Highlighted Value Set"

   The second is the addition of a comment in the condition cell, as shown in Figure 5-61.

   Figure 5-61 Comments in Condition Cells

   
   Description of "Figure 5-61 Comments in Condition Cells"

   The third is to print a message box, shown in Figure 5-62. Note that the box is only shown the first time when the value is auto-added.

   Figure 5-62 Message Dialog

   
   Description of "Figure 5-62 Message Dialog"

5.5.4.13 Aliases of Values in the Value Sets Worksheet

In the value sets sheet, there are two rows for every value set. The first row denotes the value and the second one denotes the alias of the value. It is the alias of the value that is shown in the drop-down of condition cells.The aliases can be edited. Any change made in aliases will be immediately available in corresponding condition cells.

5.5.4.14 Syncing Value Sets and Conditions

The value sets and condition cells are always in sync. Any change made in value set is promptly synced with the condition cells whether it is an addition/deletion of any value, or any change in the alias. The sync is always maintained between value set and the corresponding condition cells.