This document explains how to tune performance for Oracle Business Rules. 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.
This chapter includes the following sections:
Oracle Business Rules provides an 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.
For more information, see the User's Guide for Oracle Business Rules and "Getting Started with Oracle Business Rules" in Developing SOA Applications with Oracle SOA Suite.
This section describes recommended tuning strategies that may optimize performance.
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.
Table 15-1 Essential Business Rules Tuning Strategies
| Strategy | Description | Recommendation |
|---|---|---|
|
Use Java Beans |
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). |
|
Assert Child Facts instead of Multiple Dereferences |
Expressions like |
It is a best practice to flatten fact types as much as possible. If the fact type has a hierarchical structure, consider using |
|
Avoid Side Effects in Rule Conditions |
The tests in a rule condition may be evaluated a greater or lesser number of times than would occur in a procedural program. |
Methods or functions that have side effects such as changing a value or state should not be used in a rule condition. If a method or function has side effects, those side effects may be performed an unexpected number of times. |
|
Avoid Expensive Operations in Rule Conditions |
Expensive operations would include any operation that involves I/O (disk or network) or even intensive computations. These operations should be done external to the rules engine. |
Expensive operations should be avoided in rule conditions. In general, consider avoiding I/O or DBMS access from the rules engine directly. 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. |
|
Consider Pattern Ordering |
Reordering rule patterns can improve the performance of rule evaluation in time, memory use, or both. Finding the optimal order for your system will require some experimentation. |
If a fact is not expected to change (or will not change frequently) during rule evaluation, order the fact clauses by expected rate of change from least to greatest. 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, order the fact clauses from most restrictive (matches fewest facts) to least restrictive. |
|
Consider the Ordering of Tests in Rule Conditions |
Proper ordering can reduce the amount of computation required for facts that do not satisfy the rule condition. |
The tests in a rule condition should be ordered so that a more restrictive test occurs before a less restrictive test. If the degree of restrictiveness is not known, or estimated to be equal for a collection of tests, then simpler tests should be placed before more expensive tests. |
The assertXPath method asserts the whole hierarchy in one call, but also asserts some XLink facts for children facts to link back to parent facts. Though very convenient, it may have a performance impact.
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.
If XLink facts for children facts 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());
}