10-8 Oracle Fusion Middleware Users Guide for Oracle Business Rules
The inputs, when working with an application using ADF Business Components fact types, are the ADF Business Components view objects used
in your rules.
When you use the setViewObject method with a Decision Point, the List attribute should be unselected. Each Input fact type should have the List
attribute selected when you are using addInput or setInputs methods with the Decision Point. Optionally, depending on the usage of the view
objects, select the Tree attribute:
– List
: defines that a list of ADF Business Components fact types are passed to the decision function.
– Tree
: defines that all objects in the master-detail hierarchy should be asserted, instead of only the top-level object.
For more information, see Section 10.2.1, How to Call a Decision Point with
ADF Business Components Facts .
■
Output Fact Types : defines the fact types that the caller returns.
When calling a decision function using the Java Decision Point interface for a decision function that uses ADF Business Components fact types, Output Fact
Types should be left empty. The view object is updated using an
ActionType . For more information, see
Section 10.1.2, Understanding Oracle Business Rules Decision Point Action Type
.
■
RuleSets and Decision Functions : an ordered list of the rulesets and other
decision functions that this decision function executes. The rulesets DecisionPointDictionary.Preprocessing
and
DecisionPointDictionary.Postprocessing from the DecisionPoint dictionary
must be added so that they run before and after, respectively, the application-specific rulesets and decision functions.
10.2.3 What You Need to Know About Decision Function Configuration with ADF Business Components
Both rulesets and decision functions may be included in the definition of a decision function. It is common for an application to require some rules or decision functions
which act as plumbing code. Such applications include components that perform transformations on the input data, assert auxiliary facts, or process output facts. The
plumbing code may need to run before or after the rules that contain the core business rules of the application. You can separate these application concerns and their
associated rules from the application functional concerns using nested decision functions. Using nested decision functions, the inner decision function does not contain
the administrative, plumbing-oriented concerns, and thus only presents those rules which define the core logic of the application. This design eliminates the need for the
user to understand the administrative rules and prevents a user from inappropriately modifying these rules and possibly rendering the system inoperable due to these
changes.
To create a configuration using multiple rulesets and nested decision functions, create two decision functions and add one to the other. A good naming scheme is to suffix
the nested inner decision function with the name Core. The user specified rulesets can be added to the inner Core decision function. For example, DecisionFunction_1 can
be defined to run the DecisionPointDictionary.Preprocessing decision function, the DecisionFunction_1Core
decision function, and the
DecisionPointDictionary.Postprocessing decision function. For this example,
DecisionFunction_1Core contains the core business logic rulesets.
Working with Oracle Business Rules and ADF Business Components 10-9
It is also common for the input of a Decision Point to be an ADF Business Components fact type that is the root of a tree of ADF Business Components objects. However, the
user might only write business rules that match on a subset of the types found in the tree. In this case, it is a good practice to define the inputs of the nested decision
functions to be only the types which are actually matched in the contained rulesets. For example, consider a Decision Point calling a decision function whose input is an
Employee
fact type with the Tree option selected; if this decision function includes a
nested decision function with rulesets that only matched on the Department fact type. In this case, the nested decision function could either have as its input specified
as an Employee fact type with the Tree option selected, or a Department fact type with the List option selected. For this example, the Tree option causes the children of
the Employee instances, including the Department instances to be asserted due to the one-to-many relationship between these types. If Employee is an input to the
outer decision function and the Tree option is selected, the then Department fact type instances are asserted, and you can identify the signature on the inner decision
function as a list of Department instances these are the exact types which are being matched on for this decision function.
10.3 Creating a Business Rules Application with ADF Business Components Facts
