18 Tuning Oracle Business Rules

You can tune Oracle Business Rules to optimize its performance in enabling automation of business rules and extraction of business rules from procedural logic, such as Java code or BPEL processes.

• About Oracle Business Rules
  Oracle Business Rules provides an easy-to-use authoring environment as well as a very high-performance inference-capable rules engine.
• Tuning Oracle Business Rules
  You can tune Oracle Business Rules to optimise performance.

About Oracle Business Rules

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 is a core component of many Oracle products including both middleware and applications.

See Designing Business Rules with Oracle Business Process Management and Getting Started with Oracle Business Rules in Developing SOA Applications with Oracle SOA Suite.

Tuning Oracle Business Rules

You can tune Oracle Business Rules to optimise 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 18-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 the 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 are asserted as facts (and used in the rules).
Assert child facts instead of multiple dereferences	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 the assertXPath method or other means to assert object hierarchy.
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, which 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 externally 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 requires some experimentation.	If a fact is not expected to change or does not change frequently during rule evaluation, order the fact clauses by the 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.

• Exerting assertXPath Support
  

Exerting assertXPath Support

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 the performance of the assertXPath method, select the Enable improved assertXPath support for performancecheck box in the Dictionary Properties page in Rule Author. Taking advantage of this requires that the following conditions are met:

• The assertXPath method is only invoked with an XPath expression of "//*". Any other XPath expression results in an RLIllegalArgumentException.

• XLink facts should not be used in rule conditions as the XLink facts are not 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 XPathfor the relevant fact types and then use a function to do custom asserts. Instead of using the assertXPath method, 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());
}