|Oracle® Fusion Middleware User's Guide for Oracle Business Rules
11g Release 1 (11.1.1)
Part Number E10228-01
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.
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)
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:
Select the dictionary file and then select File > Rename to rename the dictionary file.
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".
In the project, rename the dictionaryName
.decs file to correspond with the new dictionary name.
In the project, open the dictionaryName
.decs file and change the <path> element value to match the renamed dictionary name.
In the project, rename the dictionaryName
.componentType file to correspond with the new dictionary name.
In the project, open
composite.xml, select the Source tab and edit the
name attribute to match the renamed dictionary.
composite.xml file, edit the
src attribute to match the renamed dictionary name, with a
Exception in thread "main" java.lang.NoClassDefFoundError:
java.lang.NoClassDefFoundError is very likely due to required classes not in classpath. Try checking the following:
xml.jar to your classpath when executing.
Add the directory where the generated and compiled JAXB classes are placed to the classpath.
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.
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,
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
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
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.
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
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
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.