Introduction
The integrated way to use Oracle Business Rules (OBR) from a BPEL process is via the Decision Service component through a Decide activity. Chapter 18 BPEL Process Integration with Business Rules of the Oracle BPEL Process Manager Developer's Guide explains the basic steps for doing this, but there's always more information than can go in the official documentation. This post explains in greater detail how to use the various decision service configurations.
Stateful vs. stateless
By default, the decision service is invoked as a stateful service. This allows the same decision service instance to be called more than once within the same BPEL process instance and maintain state between calls. For example, we may retrieve some data from a database, make a call to a stateful decision service, branch in our process based on the result, access the database again, and call the stateful decision service again with our additional data.
If you are only making one call to a decision service within a BPEL process using the "Assert facts, execute rule set, and retrieve results" operation type, consider changing the decision service to be stateless. This will improve performance because a stateful service invocation creates a new rule engine instance for each call, whereas a stateless service maintains a pool of services that can be reused. Thereby, the stateless service call has lower CPU overhead for creating the service instance and does not require additional memory because the rule engine instances already exist as part of the pool.
Ruleset invocation type
The Ruleset invocation type allows you to select from several Operation types, as described in section 18.4.3.1 "Mapping Input and Output Facts to BPEL Variables" of the BPEL Developer's Guide. The most common usage is the "Assert facts, execute rule set, and retrieve results" type as a stateless session. The other operation options are usually used for stateful sessions, whereby we want to maintain the state of the decision service between multiple calls, for example, if we wanted to use facts generated in the rules engine during one call as available to another call.
The primary advantage of using the Ruleset invocation type is it's simplicity, as the assert, execute, and retrieve operations are easily defined with in the Decide component. The primary disadvantage of using the Ruleset invocation type is that only rules from one ruleset will be evaluated. You cannot evaluate multiple rulesets against the same facts or use a pattern by which rules in one ruleset causes additional ruleset to be evaluated via the pushRuleset mechanism, because only the named ruleset is created in the rule engine instance.
Note that if you have multiple calls to the same decision service within a BPEL process, even these calls do not maintain state between them, it is preferred to use a stateful session. This way, if the rules are modified during the lifetime of the process, the process will still use the rules which existed when the process started. Otherwise, there is a possibility that different rules can be used for different invocations of the decision service. Multiple calls to a stateful decision service that do not (or should not) maintain state between them should be invoked with the operation "Assert facts, execute rule set, retrieve results, and reset the session", so any facts in the rule engine are removed between calls.
Function invocation type
The most useful invocation type in the decision service is to call a function defined in the rules dictionary. This allows the user greatest flexibility in how the rules are used. However, this pattern also requires the user to perform some actions which can be automatically performed with the Ruleset invocation type.
There are two operation types for the Function invocation type, "Execute function" and "Execute function and reset the session". These have equivalent functionality when called as part of a stateless decision service. When called from a stateful decision service, resetting the session will cause all facts to be retracted, as with the similar Ruleset operation type.
A function called from the decision service by this invocation type must meet the following requirements:
- return a XML Schema element type
- accept one or more XML Schema element types as parameters.
It is necessary that the return and parameter types be XML Schema element types rather than XML Schema complex types. If complex types are used, the functions will not appear in the dictionary browser and therefore cannot be selected.
The body of this function must do three things:
- assert the input parameters as facts
- push one or more rulesets onto the ruleset stack
- call the "run" method
An example of a function which can be called from the decision service is shown below:
Function body:
assertXPath("com.oracle.fmw.obr.test1", email, "//*");
pushRuleset("RULESET_1");
run();
return email;
This is a very simple function body. The function body can assert any number of parameters and push any number of rulesets onto the stack.
