Oracle Business Rules technology enables automation of business rules; it also enables extraction of business rules from procedural logic such as Java code or BPEL processes.
The chapter includes the following sections:
Oracle Business Rules provides high performance and easy to use implementation of Business Rules technology. It provides easy to use authoring environment as well as a very high performance inference capable rules engine. Oracle Business Rules is part of the Oracle Fusion Middleware stack and will be a core component of many Oracle products including both middleware and applications.
In most cases, writing of Rules should not require a focus on performance. However, as in any technology, there are tips and tricks that can be used to maximize performance when needed. Most of the considerations are focused on the initial configuration of the data model.
Section 12.2.2, "Assert Child Facts instead of Multiple Dereferences"
Section 12.2.4, "Avoid Expensive Operations in Rule Conditions"
Section 12.2.6, "Consider the Ordering of Tests in Rule Conditions"
The rule engine is most efficient when the facts it is reasoning on are Java Beans (or RL classes) and the associated tests involve bean properties. The beans should expose get and set methods (if set is allowed) for each bean property. If application data is not directly available in Java Beans, flatten the data to a collection of Java Beans that will be asserted as facts (and used in the rules).
Expressions like Account.Contact.Address involve more than one object dereference. In a rule condition, this is not as efficient as expressions with single dereferences. It is a best practice to flatten fact types as much as possible. If the fact type has a hierarchical structure, consider using assertXPath or other means to assert object hierarchy; that is for the preceding example, assert both Account and Contact as Fact Types.
Methods or functions that have side affects such as changing a value or state should not be used in a rule condition. Due to the optimizations performed when the rule engine builds the Rete network, and the Rete network operations that are performed as facts are asserted, modified (and re-asserted), or retracted, the tests in a rule condition may be evaluated a greater or lesser number of times than would occur in a procedural program. If a method or function has side effects, those side effects may be performed an unexpected number of times.
Expensive operations should be avoided in rule conditions. Expensive operations would include any operation that involves I/O (disk or network) or even intensive computations. In general, consider avoiding I/O or DBMS access from the rules engine directly. These operations should be done external to the rules engine. For other expensive operations or calculations, consider performing the computations and assert the results as a Java or RL fact. These facts are used in the rule conditions instead of the expensive operations.
Reordering rule patterns can improve the performance of rule evaluation in time, memory use, or both. There are two main guidelines for ordering fact clauses (patterns) within a rule condition.
If a fact is not expected to change (or will not change frequently) during rule evaluation, place its fact clause before fact clauses that change more frequently. That is, order the fact clauses by expected rate of change from least to greatest. Ordering fact clauses in this way can improve the performance (time) of rule evaluation.
If a fact clause (including any tests that involve only that fact) is expected to match fewer facts than other fact clauses in the rule condition, place that fact clause before the others. That is, order the fact clauses from most restrictive (matches fewest facts) to least restrictive. This can reduce the amount of memory used during rule evaluation. It may also improve the performance.
Sometimes these two guidelines conflict and it may require some experimentation to arrive at the best ordering.
Similar to the recommendations for fact clauses, the tests in a rule condition should be ordered such that a test that will be more restrictive is placed before a test that is less restrictive. This can reduce the amount of computation required for facts that do not satisfy the rule condition. If the degree of restrictiveness is not known, or estimated to be equal for a collection of tests, then the simpler tests should be placed before more expensive tests.
Note:
AssertXPath is only relevant for 10g rules usage or for 10g projects migrated to 11g. In 11g Release 1 and later, AssertXPath was replaced by AssertTree. In 11g, no XLink facts are asserted as the linkage is now handled in a different manner. AssertTree has the same performance, by default, as the special check box for 10g rules.
Most of the work done by the rules engine is done during assert, retract, or modify operations. In particular, the assertXPath method, though very convenient, may have a performance impact. The power of this method is not only that it asserts the whole hierarchy in one call, but also asserts some XLink facts for children facts to link back to parent facts. However, if these features are not needed, and you need to assert only a few levels as facts, it is better to turn off the "Supports XPath" for the relevant fact types and then use a function to do custom asserts.
Instead of using assertXPath the following example uses a function to assert ExpenseReport and ExpenseLineItems:
function assertAllObjectsFromList(java.util.List objList)
{
java.util.Iterator iter = objList.iterator();
while (iter.hasNext())
{
assert(iter.next());
}
}
function assertExpenseReport (demo.ExpenseReport expenseReport)
{
assert(expenseReport);
assertAllObjectsFromList(expenseReport.getExpenseLineItem());
}
To improve performance of assertXPath, select the "Enable improved assertXPath support for performance" check box in the Dictionary Properties page in Rule Author. Taking advantage of this will require that the following conditions are met:
assertXPath is only invoked with an XPath expression of "//*". Any other XPath expression will result in an RLIllegalArgumentException.
XLink facts should not be used in rule conditions as the XLink facts will not be asserted.