D Oracle Business Rules Troubleshooting

This appendix contains workarounds and solutions for issues you may encounter when using Oracle Business Rules. The following topics are covered:

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 Renaming a Dictionary or Dictionary Package

When renaming a dictionary or dictionary package, using JDeveloper Refactor > Rename has no affect on the dictionary or dictionary package name. To change the name of a dictionary or a dictionary package name, you use File > Rename. Do not use Refactor > Rename. The refactor option does not apply to dictionaries or dictionary packages.

Note that this the rename operation changes the name of the dictionary but not the alias. The alias can be changed through the Dictionary Settings dialog. In general, these should be set to the same value. For more information, see Section 2.2.4, "How to View and Edit Dictionary Settings".

For more information, see Section 2.2.5, "How to Rename a Dictionary or Rename a Dictionary Package".

To rename a dictionary that is part of a composite application that uses a Business Rules component, as part of a non-BPEL composite, you can rename a dictionary with the following steps.

To rename a dictionary in a composite application that does not use BPEL, do the following:

To rename a dictionary that is in a composite application with business rules:

  1. Select the dictionary file and then select File > Rename to rename the dictionary file.

  2. Open the dictionary and change the alias to match the dictionary name, using the Dictionary Settings dialog. For more information, see Section 2.2.4, "How to View and Edit Dictionary Settings".

  3. In the project, rename the dictionaryName.decs file to correspond with the new dictionary name.

  4. In the project, open the dictionaryName.decs file and change the <path> element value to match the renamed dictionary name.

  5. In the project, rename the dictionaryName.componentType file to correspond with the new dictionary name.

  6. In the project, open composite.xml, select the Source tab and edit the <component> element name attribute to match the renamed dictionary.

  7. In the composite.xml file, edit the <implementation.decision> element src attribute to match the renamed dictionary name, with a .decs extension.

D.4 Runtime NoClassDefFound Error

Sometimes when working with XML facts, you might 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.5 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. For more information, see Oracle Fusion Middleware Language Reference Guide for Oracle Business Rules.

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

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, for example letter characters when float is expected, data as described at the following site,

https://jaxb.dev.java.net/issues/show_bug.cgi?id=490

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().

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.7 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.8 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.9 How Are Decision Service Inputs and Outputs 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.