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:

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, incompleteness, or gaps, help speed development of valid, consistent business rules.

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

For information, see Chapter 4, "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 icons and selecting values in Rules Designer to help identify and correct conflicting or missing cases.

To help understand Decision Table concepts, consider a set of IF/THEN rules that determine 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 driver.eligible = 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 follows
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 bucketset. Test expressions are often used, such as Driver.age<16. These expressions are associated with the built-in boolean bucketset, 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 buckets in the associated LOV or Ranges bucketset. For more information on bucketsets, see Section 3.6, "Working with Bucketsets".

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 buckets for the ranges <20, and >=20. The values in the cells come from the global bucketset 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 bucketset associated with boolean types (this consists of default buckets for the values true and false).

Decision Tables show rules in bucket order, and to change the order of rules you need to change the order of buckets in the bucketsets. Thus, the order of the buckets in the bucketset 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 bucketset associated with a condition row; however, you cannot reorder range buckets. For information on ordering buckets in a bucketset, see Section 3.6.1, "How to Define a List of Values Global Bucketset".

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. In the Actions area the cells corresponding to an individual action for a rule are called action cells. Note, in advanced mode there are additional options for actions. For more information on advanced mode, see Section 4.5.2, "How to Select the Advanced Mode Option".

Table 5-1 Decision Table Actions for Action Cells

Action Description

assert new

Assert a new fact

call

Call a function

retract

Retract a fact

modify

Modify a data value associated with a matched fact


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 checkbox. This checkbox 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 checkbox 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 follows
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 bucket), the second cell from condition 2 (the Driver.eye_test equals fail bucket), and the third cell from condition 3 (the Driver.has_training equals true bucket). 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 follows
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 bucket 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 Section 5.3.3, "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 follows
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 icon. 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 Decision Table 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 bucketset. For example, Figure 5-5 shows a "?" value for Driver.age.

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

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

In the Decision Table Actions area you can specify that an action cell "do nothing". In this case, deselect the action cell. When the action cell checkbox is unselected 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 bucket that has been removed from the bucketset, Rules Designer provides a validation warning such as the following:

RUL-05831: Decision table bucket 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 buckets from the list.

  • Add the missing bucket to the bucketset or associate the condition with another bucketset that contains the missing bucket.

5.1.3 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:

  • Create a Decision Table

  • Add conditions to the Decision Table

  • Add actions to the Decision Table

  • Use Decision Table operations to validate, correct, and modify the Decision Table

5.2.1 How to Create a Decision Table

To work with a Decision Table you 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 Ruleset....

  2. Click the Add icon and from the list select Create Decision Table, as shown in Figure 5-6. This creates a Decision Table.

    Figure 5-6 Adding a Decision Table

    Description of Figure 5-6 follows
    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 icon 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 follows
    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 icon to display the Expression Builder window. The Expression Builder lets you build expressions.

  5. Each condition row requires a bucketset from which to draw the values for each cell. When the value you select has an associated global bucketset, then by default the bucketset is associated with the condition row.

  6. Repeat Step 2 through Step 5, as required to add additional condition rows in the Decision Table.

To use a local bucketset or specify the bucketset for a decision table condition:

  1. Each condition row requires a bucketset from which to draw the values for each cell. When the value you select has an associated global bucketset, then by default the bucketset is associated with the condition row.

  2. If there is no global bucketset 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 bucketset to associate with the condition row, or specify an existing global bucketset. To add a bucketset for the condition, in the Conditions area select the condition and then select from the Bucketset list to associate a bucketset, as shown in Figure 5-8. The bucketset list includes available global bucketsets of the appropriate type.

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

    Description of Figure 5-8 follows
    Description of "Figure 5-8 Specifying a Bucketset For a Condition Row in a Decision Table"

  3. If you do not specify a global bucketset, then you can create and use a local bucketset by selecting either Local List of Values or Local List of Ranges to create and use the specified type of bucketset.

  4. Repeat Step 2 through Step 3, as required to define additional condition rows in the Decision Table.

For more information on creating bucketsets, see Section 3.6, "Working with Bucketsets".

5.2.3 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 you need to do the following:

  1. Add actions to a Decision Table.

  2. For each action cell, where specific values apply, set the values for the action cells.

  3. 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 icon 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 follows
    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 checkbox.

  6. Repeat Step 2 through Step 5, as required to define additional actions for the Decision Table.

To set values for action cells 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 specify action cell values.

  2. In the Actions area, check that the appropriate action cells are selected. If the Always Selected checkbox 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 checkbox.

  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 icon to use the Expression Builder dialog.

    For more information on referring to a bucketset from a Decision Table, see Section 3.6.2, "How to Define a List of Ranges Global Bucketset."

To deselect an action cell in a decision table:

  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 checkbox 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 icon or Move Up icon to change the order of actions.

5.2.4 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 icon, 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 bucket values in their defined order.

  4. Enter values for the action cells.

Ordering Rules by Bucket

The Order Rules By Bucket checkbox 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 bucket 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 buckets 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 buckets) are combined. So, you cannot add two rules without any buckets to a Decision Table, because in that case, the rules are duplicates and would immediately be combined. When Order Rules By Bucket is deselected, then duplicate rules are allowed.

In addition, the Move Left and Move Right buttons pertaining to a rule column is also enabled and you can reposition rules. The Span options also get enabled and you can also cut, copy, or paste rules.

5.2.5 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 Section 4.3, "Working with Rules".

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 Advanced Settings icon (double downward pointing arrows) next to the Decision Table name. If Advanced Mode is selected, deselect the checkbox.

  3. Just below the Decision Table name, click the <insert test> downward pointing arrow.

  4. Select any of the following options according to your requirement:

    • simple test

    • variable

    • nested test

    • not nested test

  5. Click the left and the right <operand> to enter the operand values, and the operator list to select an operator.

    The added test is displayed in Figure 5-10.

    Figure 5-10 Adding Test to a Decision Table

    Description of Figure 5-10 follows
    Description of "Figure 5-10 Adding Test to a Decision Table"

5.3 Performing Operations on Decision Tables

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 in a Decision Table

5.3.1 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.

5.3.1.1 Understanding Decision Table Split and Compact Operations

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

The split table operation creates a rule for every combination of buckets 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 bucket 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 bucket in the bucketset 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 bucketset. 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 buckets 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 buckets 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-11 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 checkboxes to allow you to select a single value for the action cell. As shown in the validation log in Figure 5-11, Rules Designer shows a validation warning until you select a single value.

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

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

5.3.1.2 Understanding Decision Table Move Operations

You can move the conditions or actions in a Decision Table. The Move icons 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 icon 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-12.

Figure 5-12 Rules in a Decision Table

Description of Figure 5-12 follows
Description of "Figure 5-12 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-13.

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

Description of Figure 5-13 follows
Description of "Figure 5-13 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.3 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 buckets, 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 icon, 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 deselect Allow Gaps in the Advanced Settings area, the Decision Table reports a validation warning when a gap is found. For more information, see Section 4.5, "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-14. Clicking OK with the checkboxes selected adds either all rules or the selected rules to the Decision Table (this example only shows a single rule to add).

Figure 5-14 Checking Gaps

Description of Figure 5-14 follows
Description of "Figure 5-14 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-15.

  • 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-16.

Figure 5-15 Gap Checking with Missing Sibling Rules

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

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

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

In both of these cases shown in Figure 5-15 and Figure 5-16 there are two missing buckets, but for sibling rules the multiple buckets 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 buckets 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.4 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 bucket 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 Section 4.5, "Using Advanced Settings with Rules and Decision Tables". For example, Figure 5-17 shows a Decision Table with conflicting rules that you resolve with the default manual conflict policy.

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

Description of Figure 5-17 follows
Description of "Figure 5-17 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-18 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-18 Using the Decision Table Conflict Resolution Dialog

Description of Figure 5-18 follows
Description of "Figure 5-18 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 Section 4.5, "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 checkbox 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 icons to compact or split cells in a Decision Table. For more information, see Section 5.3.1.1, "Understanding Decision Table Split and Compact Operations."

To compact a decision table:

  1. In Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table to compact.

  2. Click the Compact Table icon.

To split cells in a decision table:

  1. From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table to split.

  2. Click the Split Table icon.

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 Section 5.3.1.1, "Understanding Decision Table Split and Compact Operations."

To merge 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 merge a condition.

  2. In the Conditions area, select the condition you want to merge.

  3. Right-click, and from the list select Merge Condition.

To split 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 split a condition.

  2. In the Conditions area, select the condition you want to split.

  3. Right-click and from the list select Split Condition.

5.3.4 How to Merge, Split, and Specify Do Not Care for Condition Cells

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 Section 5.3.1.1, "Understanding Decision Table Split and Compact Operations."

To merge sibling cells 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 merge condition cells.

  2. Select the sibling condition cells to merge.

  3. Right-click, and from the list select Merge selected cells.

To split 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 split a condition cell.

  2. Select the cell to split.

  3. Right-click, and from the list select Split selected cell.

To specify 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.

To select all buckets to specify a "Do Not Care" value for a cell in a condition:

  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. Double-click, and from the list select all the available checkboxes 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 buckets, 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 Section 5.3.1.3, "Understanding Decision Table Gap Checking".

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

To perform decision table gap checking:

  1. From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to perform.

  2. Click the Gap Analysis icon.

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 bucket in common. For more information, see Section 5.3.1.4, "Understanding Decision Table Conflict Analysis".

To perform manual decision table conflict resolution:

  1. From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to check conflicts.

  2. Set the conflict policy to manual (this is the default conflict policy). For more information, see Section 5.3.1.4, "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 Section 5.3.1.4, "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 icon 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 Section 5.3.1.4, "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 icon 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 Bucketsets to the Data Model for Order Approval

  • Associate Bucketsets 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 Example 5-1 locally to make it available to Oracle JDeveloper.

Example 5-1 shows the order.xsd schema file.

Example 5-1 Order.xsd Schema

<?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-19.

    5. Click Next.

      Figure 5-19 Adding the Order Approval Application

      Description of Figure 5-19 follows
      Description of "Figure 5-19 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-20. If an item is missing, select it in the Available pane and add it to the Selected pane using the Add button.

      Figure 5-20 Adding a Project to an Application

      Description of Figure 5-20 follows
      Description of "Figure 5-20 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-21.

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

    Description of Figure 5-21 follows
    Description of "Figure 5-21 Adding a Business Rule Dictionary with the Create Business Rules Dialog "

  3. To add an input, from the list next to the Add icon select Input to enter input for the business rule.

  4. In the Type Chooser dialog, click the Import Schema File... icon. This displays the Import Schema File dialog, as shown in Figure 5-22.

    Figure 5-22 Import Schema File with Type Chooser

    Description of Figure 5-22 follows
    Description of "Figure 5-22 Import Schema File with Type Chooser"

  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.

    Figure 5-23 Importing the Order.xsd Schema File

    Description of Figure 5-23 follows
    Description of "Figure 5-23 Importing the Order.xsd Schema File"

  8. In the Import Schema File dialog, click OK.

  9. If the Localize Files dialog displays, click OK to copy the schema to the composite process directory.

  10. 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.

  11. 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 follows
    Description of "Figure 5-24 Create Business Rules Dialog with CustomerOrder Input"

  12. In a similar manner, add the output fact type OrderApproval from the imported order.xsd.

  13. 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 follows
    Description of "Figure 5-25 Create Business Rules Dialog with Input and OrderApproval Output"

  14. 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 follows
    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 follows
    Description of "Figure 5-27 Opening a Business Rules Dictionary with Rules Designer"

5.4.5 How to Add Bucketsets to the Data Model for Order Approval

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

To add OrderAmount bucketset to the data model:

  1. In Rules Designer, select the Bucketsets navigation tab.

  2. From the dropdown next to the Create BucketSet... icon, select List of Ranges.

  3. In the Name field, enter OrderAmount (In Rules Designer be sure to press Enter to accept the name).

  4. Double-click the OrderAmount bucketset icon to display the Edit Bucketset dialog.

  5. Click Add Bucket to add a bucket.

  6. Click Add Bucket again to add another bucket.

  7. In the Range Bucket Values area, in the top Endpoint field enter 1000 for the endpoint value.

  8. In the Range Bucket Values area, for the middle bucket in the Endpoint field enter 500 for the endpoint value.

  9. In the Included Endpoint field for each bucket ensure the checkbox is selected, as shown in Figure 5-28.

    Figure 5-28 Adding the OrderAmount Bucketset

    Description of Figure 5-28 follows
    Description of "Figure 5-28 Adding the OrderAmount Bucketset"

  10. Modify the Alias field for each value to High, Medium, and Low, as shown in Figure 5-29.

    Figure 5-29 Adding the OrderAmount Bucketset with Low Medium and High Aliases

    Description of Figure 5-29 follows
    Description of "Figure 5-29 Adding the OrderAmount Bucketset with Low Medium and High Aliases"

  11. Click OK.

To add CreditScore bucketset to data model:

  1. In Rules Designer select the Bucketsets navigation tab.

  2. From the dropdown next to the Create BucketSet... icon, select List of Ranges.

  3. In the Name field, enter CreditScore.

  4. Double-click the CreditScore bucketset icon to display the Edit Bucketset dialog.

  5. Click Add Bucket to add a bucket.

  6. Click Add Bucket again to add another bucket.

  7. In the top bucket, in the Endpoint field enter 750.

  8. For the middle bucket, in the Endpoint field enter 400.

  9. In the Included Endpoint field for each bucket, ensure the checkbox is selected as shown in Figure 5-30.

    Figure 5-30 Adding the CreditScore Bucketset

    Description of Figure 5-30 follows
    Description of "Figure 5-30 Adding the CreditScore Bucketset"

  10. Modify the Alias field for each endpoint value to solid for 750, avg for 400, and risky for -Infinity as shown in Figure 5-31.

  11. Click OK.

Figure 5-31 Adding the CreditScore Bucketset with Risky Avg and Solid Aliases

Description of Figure 5-31 follows
Description of "Figure 5-31 Adding the CreditScore Bucketset with Risky Avg and Solid Aliases"

5.4.6 How to Associate Bucketsets with Order and CreditScore Properties

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

Note that the OrderApproval.status property is associated with the Status bucketset 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 bucketset. Rules Designer creates the status bucketset. For more information, see Section 3.2.4, "What You Need to Know About XML Facts".

To associate bucketsets 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-32.

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

    Description of Figure 5-32 follows
    Description of "Figure 5-32 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 Bucketset column select the cell for the appropriate property and from the list select the bucketset you want to use. For example, for the property order select the OrderAmount bucketset, as shown in Figure 5-33.

    Figure 5-33 Associating the OrderAmount Bucketset with CustomerOrder.order

    Description of Figure 5-33 follows
    Description of "Figure 5-33 Associating the OrderAmount Bucketset with CustomerOrder.order"

  5. In a similar manner, for the property creditScore select the CreditScore bucketset.

  6. Click OK.

5.4.7 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 fix any associated problems.

To validate the dictionary:

  1. In the Business Rule Validation Log, check for validation warnings.

  2. If there are validation warnings, perform appropriate actions to correct the problems.

5.4.8 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 > WLS Server Name.

    Then the SOA Deployment Configuration dialog displays.

  3. Click OK.

  4. In the Authorization Request dialog, enter your authorization.

  5. Click OK.

5.4.9 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-34.

    Figure 5-34 Testing the Order Approval Application

    Description of Figure 5-34 follows
    Description of "Figure 5-34 Testing the Order Approval Application"

  2. Click Test.

  3. In the Input Arguments area, select XML View. Replace the XML with the contents of example Example 5-2.

    Example 5-2 Sample Input for Testing Order Approval Application

    <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 Example 5-2 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>