Oracle® Fusion Middleware User's Guide for Oracle Business Rules 11g Release 1 (11.1.1.5.0) E10228-06 |
|
![]() Previous |
![]() Next |
Using a Decision Table you can create and use business rules in an easy to understand format that provides an alternative to the IF/THEN rule format. 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.
This chapter includes the following sections:
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.
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".
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
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".
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 a new fact |
|
Call a function |
|
Retract a fact |
|
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
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.
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
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.
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
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.
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. |
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
To work with a Decision Table you start by creating a Decision Table in a ruleset.
To create a decision table:
From Rules Designer select an existing ruleset from the rulesets tab or create a ruleset by clicking Create Ruleset....
Click the Add icon and from the list select Create Decision Table, as shown in Figure 5-6. This creates 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. |
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:
From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to add conditions.
In the Decision Table area, from the list next to the Add icon select Condition.
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
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.
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.
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:
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.
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
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.
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".
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:
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:
From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to add actions.
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
In the Action Editor dialog select the action target in the Target area. This specifies the data model object the action applies to.
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. |
In the Action Editor dialog, to select action cells for all the rules, select the Always Selected checkbox.
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:
From Rules Designer, select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to specify action cell values.
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.
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:
From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want deselect an action cell.
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.
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:
From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to add the rule.
From the list next to the Add icon, select Rule.
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.
Enter values for the action cells.
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
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.
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, |
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, |
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-10 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-10, Rules Designer shows a validation warning until you select a single value.
Figure 5-10 Conflicting Properties to be Resolved for a Merged Action Cell
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-11.
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-12.
Figure 5-12 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.
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 Analysis 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-13. 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).
Gap analysis 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 analysis shows a single rule as shown in Figure 5-14.
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 analysis provides two rules, as shown in Figure 5-15.
Figure 5-14 Gap Analysis with Missing Sibling Rules
Figure 5-15 Gap Analysis with Missing Non-Sibling Rules
In both of these cases shown in Figure 5-14 and Figure 5-15 there are two missing buckets, but for sibling rules the multiple buckets are combined in a single new rule. Thus, in general gap analysis 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.
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-16 shows a Decision Table with conflicting rules that you resolve with the default manual conflict policy.
Figure 5-16 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-17 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-17 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.
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:
In Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table to compact.
Click the Compact Table icon.
To split cells in a decision table:
From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table to split.
Click the Split Table icon.
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:
From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to merge a condition.
In the Conditions area, select the condition you want to merge.
Right-click, and from the list select Merge Condition.
To split a condition in a decision table:
From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to split a condition.
In the Conditions area, select the condition you want to split.
Right-click and from the list select Split Condition.
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:
From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to merge condition cells.
Select the sibling condition cells to merge.
Right-click, and from the list select Merge selected cells.
To split a cell in a condition in a decision table:
From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to split a condition cell.
Select the cell to split.
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:
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.
Select the appropriate condition cell.
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:
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.
Select the appropriate condition cell.
Double-click, and from the list select all the available checkboxes for all possible values.
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 Analysis 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 Analysis".
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 analysis:
From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to perform.
Click the Gap Analysis icon.
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:
From Rules Designer select a ruleset from the Rulesets navigation tab and select the Decision Table where you want to check conflicts.
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".
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.
In the Conflict Resolution dialog, for each conflicting rule, in the Resolution field select a resolution from the list.
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:
Select the rule or Decision Table where you want to use ignore conflict policy.
Click the Show Advanced Settings icon next to the rule or Decision Table name.
From the Conflict Policy option select auto override.
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:
Select the rule or Decision Table where you want to use the ignore conflicts policy.
Click the Show Advanced Settings icon next to the rule or Decision Table name.
From the Conflict Policy option select ignore.
The Order Approval application demonstrates the integration of an 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
The source code for Oracle Business Rules-specific samples is available online at
https://www.samplecode.oracle.com/sf/go/page1497
For SOA samples online visit
https://www.samplecode.oracle.com/sf/projects/soasamples/
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>
To work with Oracle Business Rules, you first create an application in Oracle JDeveloper.
To create an application for order approval:
In the Application Navigator, click New Application.
In the Name your application dialog, enter the name and location for the new application.
In the Application Name field, enter an application name. For example, enter OrderApprovalApp
.
In the Directory field, specify a directory name or accept the default.
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.
For an SOA composite with Oracle Business Rules, in the Application Template area select SOA Application for the application template. For example, see Figure 5-18.
Click Next.
Figure 5-18 Adding the Order Approval Application
In the Name your project page enter the name and location for the project.
In the Project Name field, enter a name. For example, enter OrderApproval
.
Enter or browse for a directory name, or accept the default.
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-19. If an item is missing, select it in the Available pane and add it to the Selected pane using the Add button.
Figure 5-19 Adding a Project to an Application
Click Finish.
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:
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).
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-20.
Figure 5-20 Adding a Business Rule Dictionary with the Create Business Rules Dialog
To add an input, from the list next to the Add icon select Input to enter input for the business rule.
In the Type Chooser dialog, click the Import Schema File... icon. This displays the Import Schema File dialog, as shown in Figure 5-21.
Figure 5-21 Import Schema File with Type Chooser
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.
In the SOA Resource Lookup dialog, navigate to find the order.xsd
schema file and click OK.
In the Import Schema File dialog, make sure Copy to Project is selected, as shown in Figure 5-22.
Figure 5-22 Importing the Order.xsd Schema File
In the Import Schema File dialog, click OK.
If the Localize Files dialog displays, click OK to copy the schema to the composite process directory.
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-23.
Figure 5-23 Create Business Rules Dialog with CustomerOrder Input
In a similar manner, add the output fact type OrderApproval
from the imported order.xsd
.
In the Create Business Rules dialog, select Expose as Composite Service, as shown in Figure 5-24.
Figure 5-24 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-25.
Figure 5-25 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.
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:
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).
Double-click the selection box to launch Rules Designer.
In Rules Designer select the Facts navigation tab.
Select XML Facts tab in the Facts navigation tab as shown in Figure 5-26.
Figure 5-26 Opening a Business Rules Dictionary with Rules Designer
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:
In Rules Designer, select the Bucketsets navigation tab.
From the dropdown next to the Create BucketSet... icon, select List of Ranges.
In the Name field, enter OrderAmount
(In Rules Designer be sure to press Enter to accept the name).
Double-click the OrderAmount bucketset icon to display the Edit Bucketset dialog.
Click Add Bucket to add a bucket.
Click Add Bucket again to add another bucket.
In the Range Bucket Values area, in the top Endpoint field enter 1000 for the endpoint value.
In the Range Bucket Values area, for the middle bucket in the Endpoint field enter 500 for the endpoint value.
In the Included Endpoint field for each bucket ensure the checkbox is selected, as shown in Figure 5-27.
Figure 5-27 Adding the OrderAmount Bucketset
Modify the Alias field for each value to High, Medium, and Low, as shown in Figure 5-28.
Figure 5-28 Adding the OrderAmount Bucketset with Low Medium and High Aliases
Click OK.
To add CreditScore bucketset to data model:
In Rules Designer select the Bucketsets navigation tab.
From the dropdown next to the Create BucketSet... icon, select List of Ranges.
In the Name field, enter CreditScore
.
Double-click the CreditScore bucketset icon to display the Edit Bucketset dialog.
Click Add Bucket to add a bucket.
Click Add Bucket again to add another bucket.
In the top bucket, in the Endpoint field enter 750
.
For the middle bucket, in the Endpoint field enter 400
.
In the Included Endpoint field for each bucket, ensure the checkbox is selected as shown in Figure 5-29.
Figure 5-29 Adding the CreditScore Bucketset
Modify the Alias field for each endpoint value to solid for 750, avg for 400, and risky for -Infinity as shown in Figure 5-30.
Click OK.
Figure 5-30 Adding the CreditScore Bucketset with Risky Avg and Solid Aliases
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:
In Rules Designer select the Facts navigation tab.
Select the XML Facts tab in the Facts navigation tab as shown in Figure 5-31.
Figure 5-31 Opening a Business Rules Dictionary with Rules Designer
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.
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-32.
Figure 5-32 Associating the OrderAmount Bucketset with CustomerOrder.order
In a similar manner, for the property creditScore select the CreditScore bucketset.
Click OK.
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 icon 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 Section 4.4.2, "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:
In Rules Designer, select Ruleset_1 under the Rulesets navigation tab.
Click the Add icon and from the list and select Create Decision Table.
In the Decision Table, click the Add icon and from the list select Condition.
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.
Again, in the Decision Table, click the Add icon and from the list select Condition.
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
.
Again, in the Decision Table, click the Add icon and from the list select Condition.
In the Decision Table, double-click <edit condition>.
In the navigator expand CustomerOrder and select annualSpending. In the text entry area, add >2000
as shown in Figure 5-33.
Figure 5-33 Adding the Annual Spending Entry to a Decision Table
Type Enter to accept the value, as shown in Figure 5-34. If you view the rules validation log you should see the warning messages as shown in Figure 5-34. You remove these warning messages as you modify the Decision Table in later steps.
Figure 5-34 Adding Conditions to the CustomerOrder Decision Table
To create an action in a decision table:
In the Decision Table click the Add icon and from the list select Action > Assert New.
In the Actions area, double-click assert new(. This displays the Action Editor dialog.
In the Action Editor dialog, in the Facts area select OrderApproval.
In the Action Editor dialog, in the Properties table for the property status
select the Parameterized checkbox and the Constant checkbox. This specifies that each rule independently sets the status.
In the Action Editor dialog, select the Always Selected checkbox as shown in Figure 5-35.
Figure 5-35 Adding an Action to a Decision Table with the Action Editor Dialog
In the Action Editor dialog, click OK.
Next you need to add rules to the Decision Table and specify an action for each rule.
You can use the Decision Table split operation to create rules for the bucketsets associated with the condition rows in the Decision Table. This creates one rule for every combination of condition buckets. There are three order amount buckets, three credit score buckets, and two boolean buckets for the annual spending amount for a total of eighteen rules (3 x 3 x 2 = 18).
To split cells in a decision table:
Select the Decision Table.
In the Decision Table, click the Split Table icon 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-36.
These steps produce validation warnings for action cells with missing expressions. You fix these in later steps.
Figure 5-36 Splitting a Decision Table Using Split Table Operation
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.
In the Actions area, double-click the action cell for the rule you want to work with, as shown in Figure 5-37.
Figure 5-37 Adding Action Cell Values to a Decision Table
In the list, select and enter a value for the action cell. For example, enter Status.MANUAL
.
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.
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 |
|
R2 |
risky |
Low |
false |
|
R3 |
risky |
Medium |
true |
|
R4 |
risky |
Medium |
false |
|
R5 |
risky |
High |
true |
|
R6 |
risky |
High |
false |
|
R7 |
avg |
Low |
true |
|
R8 |
avg |
Low |
false |
|
R9 |
avg |
Medium |
true |
|
R10 |
avg |
Medium |
false |
|
R11 |
avg |
High |
true |
|
R12 |
avg |
High |
false |
|
R13 |
solid |
Low |
true |
|
R14 |
solid |
Low |
false |
|
R15 |
solid |
Medium |
true |
|
R16 |
solid |
Medium |
false |
|
R17 |
solid |
High |
true |
|
R18 |
solid |
High |
false |
|
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:
Select the Decision Table.
Click the Resize All Columns to Same Width icon.
Click the Compact Table icon 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-38.
Figure 5-38 Compacting a Decision Table Using Compact Table
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:
Select the Decision Table.
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-39.
Click Delete to remove a rule in the Decision Table. Be careful to click the delete icon in the Decision Table area to delete a rule in the decision table (there is also a delete icon shown in the Ruleset area that deletes the complete Decision Table).
Figure 5-39 Deleting Rules from a Decision Table
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-40.
Figure 5-40 Decision Table After Manual Actions Removed
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:
In the Decision Table, click the Add icon and from the list select Rule.
In the Conditions area, for the three conditions leave the "-" do not care value for each cell in the rule.
In the Actions area, enter Status.MANUAL
, as shown in Figure 5-41. Notice that the Business Rule Validation log includes the warning RUL-05851
for unresolved conflicts.
Figure 5-41 Decision Table with Conflicting Rules
Show the conflicting rules by clicking the Toggle Display of Conflict Resolution icon, as shown in Figure 5-42.
Figure 5-42 Adding a Rule to Handle Status Manual
To enable the auto override conflict resolution policy:
In the Decision Table click Show Advanced Settings (the icon next to the Decision Table name).
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-43.
Figure 5-43 Adding a Rule to Handle Status Manual with Auto Override Conflict Policy
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:
In the Business Rule Validation Log, check for validation warnings.
If there are validation warnings, perform appropriate actions to correct the problems.
Business rules created in an SOA application are deployed as part of the SOA composite when you create a deployment profile in Oracle JDeveloper. You deploy an SOA composite application to Oracle WebLogic Server.
To deploy and run the order approval application:
If you have not started your application server instance, then start the Oracle WebLogic Server.
In the Application Navigator, right-click the OrderApproval project and select Deploy > OrderApproval > to > WLS Server Name.
Then the SOA Deployment Configuration dialog displays.
Click OK.
In the Authorization Request dialog, enter your authorization.
Click OK.
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:
Open the composite application in Oracle Enterprise Manager Fusion Middleware Control Console, as shown in Figure 5-44.
Figure 5-44 Testing the Order Approval Application
Click Test.
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>
Replace the values in the input shown in Example 5-2 as desired for your test.
Click Test Web Service.
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>