8 Oracle Business Rules

This chapter describes issues associated with Oracle Business Rules. It includes the following topics:

• Section 8.1, "Using RL Reserved Words in Java Package Names"

• Section 8.2, "Ancestor Methods are not Visible from Sub-Classes"

• Section 8.3, "New and Deleted Patterns are not Immediately Available"

• Section 8.4, "Changes to the Bind Variable Name are not Immediately Reflected"

• Section 8.5, "Refreshing Imported Java Facts After Changing the Underlying Classes"

• Section 8.6, "RL serviceDateValidation Error: Fact Class Should Be Declared Earlier"

8.1 Using RL Reserved Words in Java Package Names

Invalid RL Language is generated if an RL Language reserved word (for example, the word rule in mypkg.rule.com) is part of the Java package name. If an RL Language reserved word is used in a Java package name, an error message like the following appears:

Oracle RL 1.0: syntax error PareseException: encountered 'rule' when expectingone of: <XML_IDENTIFIER> ...<IDENTIFIER> ... "*" at line 11 column 19 in main

There is no workaround for this issue; do not use RL Language reserved words in Java package names.

8.2 Ancestor Methods are not Visible from Sub-Classes

The properties of a superclass are visible in the appropriate choice lists, but the methods of the ancestor classes are not visible.

There is no workaround for this issue.

8.3 New and Deleted Patterns are not Immediately Available

When you use Rule Author to add a pattern to a rule, the list of actions does not immediately reflect the existence of the new pattern instance. Similarly, when you use Rule Author to delete a pattern from a rule, the list of actions does not immediately reflect this change.

To work around this issue, you can do either of the following:

1. Update the rule by clicking either OK or Apply, then re-select the rule from the navigation pane.

2. Create a new action.

8.4 Changes to the Bind Variable Name are not Immediately Reflected

If you change the bind variable name on the Pattern Definition page, this change is not immediately reflected on the parent page (the Rule Author Rule page). In order to see your changes, you must close the Pattern Definition page before continuing your work on the Rule Author Rule page.

There is no workaround for this issue.

8.5 Refreshing Imported Java Facts After Changing the Underlying Classes

To refresh imported Java Facts after the underlying classes are changed, re-import the Java classes. The JavaFact is updated with the new methods and properties.

If you want to change the property name in the Java class, you must recreate any rules that use the property whose name you want to change.

If you want to change the property type or visibility, you must:

1. Remove any references to that property in the rules (but not necessarily the fact type itself).

2. Remove the property entirely from the Java class.

3. Re-import the Java class without the property.

4. Add the property back to the class with the new type or visibility.

5. Re-import the Java class again.

Methods can always be re-imported regardless of whether or not the return type is changed. However, if the return type is changed, any rule patterns that use this function will be invalid. However, you will not see that they are invalid until you attempt to validate or save the rule, so you should exercise caution when changing the return type.

8.6 RL serviceDateValidation Error: Fact Class Should Be Declared Earlier

In certain cases, you can receive the following RL generation error:

"Fact class should be declared earlier ...".

For example, with the following generated RL for a data model:

ruleset DM {
 function CreateDataAndTestRules()
 {
 servOrders.ServiceOrderTypeImpl sot = new
servOrders.ServiceOrderTypeImpl();
.
.
.

This causes the implemented Impl class to be autofactclassed before the Type is factclassed. When the Type is then referred to in the rules, the following error is thrown:

ClassName: A syntax error is found. Error:fact class should be declared earlier at line 5 column 3 in serviceDateValidation

To fix this problem:

Classes with complex type hierarchies, for example they both extends a class and implements an interface must have classes referenced in a particular order. If the classes are not referenced in the correct order, then the rules engine cannot correctly determine the class hierarchy.

There are two ways to fix this problem:

• Check "supports XPath" for the ServiceOrderType class; this introduces a slight performance cost.

• Change the code in the CreateDataAndTestRules function. For example, change the instance creation to:

  servOrders.ServiceOrderType sot = new servOrders.ServiceOrderTypeImpl();
  

  This parses in the right order such that the superclass is created before the implementing class.