D Oracle Business Rules Troubleshooting

Workarounds and solutions for issues you may encounter when using Oracle Business Rules.

D.1 Getter and Setter Methods are not Visible

Rules Designer does not list the methods supporting a Java bean property in choice lists; only the bean properties are visible. For example, a Java bean with a property named Y must have at least a getter method getY() and may also have a setter method setY(y-type-param).

All of properties and methods (including getter and setter that compose the properties) are displayed when viewing the Java FactType. Only the properties of Java Classes (not the getter and setter methods) are displayed in choice lists. When attempting to control the visibility of the property it is best to use the properties visibility flag. Marking a getter or a setter method as not visible may not remove the properties from choice lists.

D.2 Java Class with Only a Property Setter

In Java the Java Bean introspector includes write-only properties. Oracle RL does not include such properties as Beans, because they cannot be reasoned on in a rule.

Thus, in order for Java fact type bean properties to be properly accessed in Oracle RL they must have both a getter and setter. Properties which have a setter but not a getter, that is write-only properties, are not allowed in the Oracle RL "new" syntax.

For example, if a bean Foo only has the method setProp1(int i), then you cannot use the following in Oracle RL:

Foo f = new Foo(prop1: 0)

D.3 Runtime NoClassDefFound Error

Sometimes when working with XML facts, you might receive an error.

You may receive an error of the form:

Exception in thread "main" java.lang.NoClassDefFoundError: 

The java.lang.NoClassDefFoundError is very likely due to required classes not in classpath. Try checking the following:

  • Add xml.jar to your classpath when executing.

  • Add the directory where the generated and compiled JAXB classes are placed to the classpath.

D.4 RL Specific Keyword Naming Conflict Errors

Oracle Business Rules escapes RL specific keywords when generating RL from Rules Designer.

In most cases, RL specific keywords can be used without causing errors. One exception is using a keyword as the name of a class. This is unlikely for Java classes because by convention they start with an upper case letter and RL specific keywords are all lowercase..

D.5 java.lang.IllegalAccessError from Business Rules Service Runtime

There may be errors

Problem: I receive an error such as the following:

java.lang.IllegalAccessError: tried to access class
com.sun.xml.bind.v2.runtime.reflect.opt.Const from class:...

Reason: This can be due to JAXB 2.1.6 issue 490 caused when unmarshalling incorrect letter characters when float is expected.

Workaround: the workaround for this problem is to assign a value to the appropriate element, as shown in Figure D-1 and Figure D-2 where approvalRequired is assigned a default value false().

Note that the screen shots reflect a previous version, however, the content is applicable to the current release.

Figure D-1 Adding an Expression to Initialize a Value for a Business Rules Service Input

Description of Figure D-1 follows
Description of "Figure D-1 Adding an Expression to Initialize a Value for a Business Rules Service Input"

Figure D-2 Expression Assigned to Input Variable for Business Rules Service

Description of Figure D-2 follows
Description of "Figure D-2 Expression Assigned to Input Variable for Business Rules Service"

D.6 JAXB 1.0 Dictionaries and RL MultipleInheritanceException

Dictionaries which have been migrated from 10.1.3 use JAXB 1.0 instead of JAXB 2.0, which is the default for Oracle Fusion Middleware 11g Release 1 (11.1.1) dictionaries. Because of this use of JAXB 1.0, the migrated dictionaries may contain Element types. If your dictionary has Element types marked as visible, generated RL may throw MultipleInheritanceException.

The solution to this issue is to mark the Element fact types non-visible or remove them from the datamodel. Only the Type classes generated by JAXB should be used to write rules, so there is no functionality loss from deleting the Element types.

D.7 Why Does XML Schema with Underscores Fail JAXB Compilation?

The defined behavior of JAXB is to fail when a name of the form '_' + number is found. In this case JAXB cannot generate an "obvious" Java class name from this string. The default behavior of JAXB for '_' + char is to treat it as a word boundary (underscoreBinding="asWordSeparator"), which means the underscore is stripped and the char is UpperCamelCased. For example, _fooBar is mapped to FooBar.

To fix this problem, you need to provide a schema customization to direct JAXB to generate the names differently. The default value for underscoreBinding is specified as "asWordSeparator", which does not allow an underscore to be used at the beginning of a name.

The global annotation underscoreBinding="asCharInWord" causes the '_' to be preserved in the classname and UpperCamelCase after the number:

<xsd:annotation><xsd:appinfo>
      <jaxb:globalBindings underscoreBinding="asCharInWord" />
</xsd:appinfo></xsd:annotation>

With this global annotation, the mapping for _1foo_bar_baz is _1Foo_Bar_Baz.

D.8 How Are Decision Service Input Output Element Types Restricted?

Using the Decision Service to run business rules with XML schema defining the input, for any given complexType "tFoo" in an XML-Schema file Foo.xsd there can only be one XML-Schema element "foo" of type "tFoo".

The Decision Service does not allow you to use two elements "foo" and "bar" of the same type "tFoo".

D.9 How Are Decision Service Input Output Schema Restricted?

When you use the Decision Service a schema must define a complexType or import another schema which defines a complexType.

You cannot use schemas which do not define complexType, such as the following:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns="http://www.example.org"
            targetNamespace="http://www.example.org"
            elementFormDefault="qualified">
  <xsd:element name="count" type="xsd:int"/>
</xsd:schema>

D.10 How Do I Handle Java Reserved Names in an Imported Fact Type?

In Oracle Business Rules, when you import fact type properties which would have the same name as a Java language reserved word are excluded.

For a complete list of Java reserved words, see

http://java.sun.com/docs/books/tutorial/java/nutsandbolts/_keywords.html

A workaround is to rename the getter and setter method pair that produce the excluded property. If these methods names cannot be changed, the methods should be used in rules instead of the properties.

For example, if a property named continue is excluded, you can create rules that use getContinue() and setContinue() methods instead of using the property.You can do this by rewriting a pattern. For example, replace:

fact IncrCount ic && ic.continue == "foo"

with:

fact IncrCount ic && ic.getContinue() == "foo"

For another example, in an action, replace:

[assert new] IncrCount(continue:"bar")

with:

[assign new] IncrCount ic = new IncrCount( )
[call] ic.setContinue("bar")
[assert] ic