Skip Headers
Oracle® Fusion Middleware User's Guide for Oracle Business Rules
11g Release 1 (11.1.1.6.2)

Part Number E10228-09
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

6 Working with Decision Functions

This chapter describes how to use a decision function to call rules from a Java application, from a composite, or from a BPEL process.

The chapter includes the following sections:

6.1 Introduction to Decision Functions

A decision function is a function that is configured declaratively.

A decision function contains the following declarations:

A decision function performs the following operations:

You can create a decision function to simplify the use of Oracle Business Rules from a Java application or from a BPEL process. In a decision function the rules you want to use can be organized into several rulesets, and those rulesets can be executed in a prescribed order. Facts may flow to the first ruleset, and this ruleset may assert additional facts that flow to the second and subsequent rulesets until finally facts flow back to the decision function as decision function output.

6.2 Working with Decision Functions

A decision function is a function that is configured declaratively.

6.2.1 How to Add or Edit a Decision Function

You use Rules Designer to add a decision function.

To add a decision function:

  1. In Rules Designer, select the Decision Functions navigation tab.

  2. In the Decision Functions area, click Create....

  3. Enter the decision function name in the Name field, or use the default name as Figure 6-1 shows.

    Figure 6-1 The Decision Functions Area in Rules Designer

    Description of Figure 6-1 follows
    Description of "Figure 6-1 The Decision Functions Area in Rules Designer"

  4. In the decision functions table, double-click the decision function icon. For example, double-click the decision function icon for DecisionFunction_1. This displays the Edit Decision Function dialog, as shown in Figure 6-2.

    Figure 6-2 Edit Decision Function Dialog

    Description of Figure 6-2 follows
    Description of "Figure 6-2 Edit Decision Function Dialog"

  5. In the Name field, enter a name or accept the default value.

  6. In the Description field, optionally enter a description.

  7. In the Rule Firing Limit field, select unlimited. In some cases when you are debugging a decision function, you may want to enter a value other than unlimited for the rule firing limit. For more information, see Section 6.3.1, "What You May Need to Know About Rule Firing Limit Option for Debugging Rules".

  8. Select the appropriate decision function options:

    • Will be invoked as a Web Service: select whether the decision function will be invoked as a Web Service and provide the Web Service name.

    • Check Rule Flow: when selected, this option specifies that the rule flow is checked to ensure that facts of the appropriate type are either explicit inputs to the decision function or are asserted by rules in the rule flow. However, when this is selected this does not always produce useful information; there are cases where facts can be asserted in Java code that uses the decision function, but this code might not be available at design time. In this case, validation warnings may produced with Check Rule Flow selected may not be useful.

    • Stateless: when selected specifies the decision function is stateless. For more information, see Section 6.3.3, "What You May Need to Know About the Decision Function Stateless Option".

  9. In the Inputs tab, click Add to add inputs. For each input in the Inputs Table, select the appropriate options:

    • Name - enter an input name and press Enter or accept the default name.

    • Fact Type - select the appropriate fact type from the list.

    • Tree - When unselected, the input is asserted using the assert function. When selected, the input is asserted using the assertTree function. When selected it is expected that the input object or objects are the root of an object tree that is connected in one-to-many relationships with other objects using List properties. For more information, see Section 4.8, "Working with Tree Mode Rules".

    • List - When unselected, the input must be a single object and the assertion applies only to that single input object. When selected, the input must be a List of objects and the assertion applies to each object in the input List (java.util.List).

    • Description - Description of the input.

  10. In the Outputs tab, click Add to add outputs. For each output in the Outputs Table, select the appropriate options:

    • Name - enter an output name and press Enter or accept the default name.

    • Fact Type - select the appropriate fact type from the list.

    • Tree - When selected, this option sets a flag that enables certain design-time decision function argument checking. For an output argument, this option has no effect on runtime behavior. However, at design time in the case where several decision functions are called in a sequence, it is useful to notate explicitly that the output of one decision function is a tree. This implies that the input of another decision function in the sequence is expecting a tree as an input. For more information, see Section 4.8, "Working with Tree Mode Rules".

    • List - When unselected the output is a single object. When selected the output is a group of objects. For more information on the behavior of the List option on an output argument, see Section 6.3.2, "What You May Need to Know to About Decision Function Arguments".

    • Description - Description of the output.

  11. In the Initial Actions tab, you can add actions that could be used to change input facts before they are asserted, change the ruleset stack, set the effective date, or even assert output facts. These actions could be used instead of rules, or to "set up" the environment for running rules.

    Consider a situation where a decision function (DF1) calls another decision function (DF2) using the Initial Actions tab. DF1 is configured to push Ruleset1 to the ruleset stack. DF2 is configured to push Ruleset2. In DF1, before the initial actions are executed, Ruleset1 is pushed to the ruleset stack. Then, when DF2 is called, Ruleset2 is also pushed. So when rules start running, rules from both rulesets fire because of the ruleset stack. If you want to push Ruleset2 (because in the initial actions, you are calling DF2), you can use initial actions in DF1 to clear the ruleset stack before calling DF2, and push Ruleset1 on the stack after calling DF2.

    You can add any required action ranging from assert, call, modify to even conditional actions such as if, else, elseif, while, for, if (advanced), and while (advanced) as shown in Figure 6-3.

    Figure 6-3 Adding Initial Actions

    Description of Figure 6-3 follows
    Description of "Figure 6-3 Adding Initial Actions"

    Note:

    If decision function DF1 contains DF2 in the Rulesets & Decision Functions tab, then DF2 may not have any initial actions.

    The if (advanced) and while (advanced) conditional actions accept only boolean values. For each of the action conditions, you can add different test form types.

  12. In the Rulesets and Decision Functions area, use the shuttle to move items from the Available box to the Selected box.

  13. Select an item in the Selected box, and click Move Up or Move Down as appropriate to order the rulesets and the decision functions.

To edit an existing decision function:

  1. In Rules Designer, select the Decision Functions navigation tab.

  2. Select the decision function to edit and click the Edit icon or double-click the decision function icon.

  3. Edit the appropriate decision function fields in the same manner as you would when you add a decision function.

To change the order of inputs:

  1. In Rules Designer, select the Decision Functions navigation tab.

  2. Select the decision function to edit and click the Edit icon or double-click the decision function icon.

  3. Select the input argument you want to move. Click either Move Up or Move Down to reorder the input argument.

To change the order of outputs:

  1. In Rules Designer, select the Decision Functions navigation tab.

  2. Select the decision function to edit and click the Edit icon or double-click the decision function icon.

  3. Select the output argument you want to move. Click either Move Up or Move Down to reorder the output argument.

6.3 What You Need to Know About Decision Functions

A decision function is a function that is configured declaratively.

6.3.1 What You May Need to Know About Rule Firing Limit Option for Debugging Rules

The Rule Firing Limit allows you to set the maximum number of steps (rule firings) that are allowed at runtime. Using this option and specifying a value other than unlimited can help you debug certain rule design problems and in some cases might help prevent java.lang.OutOfMemoryError errors at runtime. This is can be useful when debugging infinitely recursive rule firings.

6.3.2 What You May Need to Know to About Decision Function Arguments

Oracle Business Rules generates a corresponding RL Language function for each decision function.

The signature of a generated decision function is similar to:

function <name>(InputFactType1 input1, ... InputFactTypeN inputN) returns List

In a decision function, each parameter is generated depending on the List option, with the decision function input, as follows:

  • Input argument, List option unselected: for FactTypei the input must be a single object and the assertion applies only to that single input object.

  • Input List option selected: List<FactTypei> the input must be a List of objects and the assertion applies to each object in the input List (java.util.List).

The generated RL Language function includes calls either to assert or assertTree for each argument, depending on the decision function Input option, Tree. When Tree is unselected the input is asserted using the assert function. When Tree is selected, the input is asserted using the assertTree function. When Tree is selected it is expected that the input object or objects are the root of an object tree that is connected in one-to-many relationships with other objects using List or array type properties.

For the decision function selected rulesets, as specified in the Rulesets and Decision Functions area Selected box, the generated RL Language function includes a call to run() with the selected rulesets in the selected ruleset stack order.

The generated RL Language function returns a list. The list has an element for each decision function output in order. If the output is declared to be a list, then the corresponding element is a list. However, if the output is not declared to be a list, then the corresponding element is the output fact or null (if there is no output fact of the declared type). If an output is not declared to be a list, and more than one output fact of the specified type is found in the working memory of Oracle Business Rules Engine, then an exception is thrown.

After you edit a decision function, for example, to change or add inputs and outputs, the changes are visible in BPEL for new Business Rule activities. However, the changes are not visible to existing Business Rule activities. For more information, see "Getting Started with Oracle Business Rules" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

6.3.3 What You May Need to Know About the Decision Function Stateless Option

A decision function supports either stateful or stateless operation. The Stateless checkbox in the Edit Decision Function dialog provides support for these two modes of operation.

By default the Stateless checkbox is selected which indicates stateless operation. With stateless operation, at runtime, the rule session is released after each invocation of the decision function.

When Stateless is deselected the underlying Oracle Business Rules object is kept in the memory of the Business Rules service engine, so that it is not given back to the Rule Session Pool when the operation is finished. A subsequent use of the decision function re-uses the cached RuleSession object, with all its state information from the previous invocation. Thus, when Stateless is deselected the rule session is saved for a subsequent request and a sequence of decision function invocations from the same process should always end with a stateless invocation.