|Oracle® Fusion Middleware Release Notes
11g Release 1 (11.1.1) for Linux x86
Part Number E10133-05
This chapter describes issues associated with Oracle Business Rules. It includes the following topics:
This section describes general issues and workarounds. It includes the following topics:
MigrateRuleRepository utility is used with an existing migrated dictionary structure in the destination path, the following error is returned:
oracle.rules.tools.migrator.MigrationException: failed to connect to destination repository C:\migration\FooRepository-migrated/Foo/INITIAL
This error should report a message indicating that a migrated dictionary structure already exists in the destination location.
The workaround is to delete the migrated dictionary structure in the destination path, and run the
MigrateRuleRepository utility again.
In Oracle Fusion Middleware 11g Release 1 (11.1.1), there is the concept of the "built-in" dictionary which is linked to by all other dictionaries. The built-in dictionary includes fact types for several common Java classes, including:
There is a limitation when you are migrating a Release 10.1.3.x dictionary to Oracle Fusion Middleware 11g Release 1 (11.1.1). In Oracle Business Rules Release 10.1.3.x, all classes had to be imported into each dictionary, including
Object which was imported by default. Thus, a user could import the common Java class fact types and change the aliases for properties, methods, and fields. In Oracle Fusion Middleware 11g Release 1 (11.1.1), for such classes users cannot specify custom aliases and these fact types are not migrated from a Release 10.1.3.x dictionary that is being migrated to Oracle Fusion Middleware 11g Release 1 (11.1.1). Thus, if an alias is applied for a common Java class that is part of the built-in dictionary, in Oracle Fusion Middleware 11g Release 1 (11.1.1) these aliases are discarded and the aliases are not available to use in rules.
There is no workaround for this issue.
During dictionary migration from Oracle Business Rules Release 10.1.3.x, Java classes are imported into the new Oracle Fusion Middleware 11g Release 1 (11.1.1) dictionary and then aliases and visibility settings are applied. A bug in the migration prevents the identification of some methods so that alias and visibility settings can be applied.
In such cases, the alias and visibility settings that applied for the Oracle Business Rules Release 10.1.3.x dictionary must be manually applied to the destination Oracle Fusion Middleware 11g Release 1 (11.1.1) dictionary.
Restricted Simple Types
Oracle Business Rules Release 10.1.3.x uses JAXB 1.0. In JAXB 1.0 restricted simple types do not have any special support in the generated Java classes, and are mapped to a property with the same type as the simple type. Oracle Business Rules for Oracle Fusion Middleware 11g Release 1 (11.1.1) uses JAXB 2.0. In JAXB 2.0, restricted simple types of string type are transformed into Java enum values. Because of this difference, after migrating a Release 10.1.3.x dictionary, places in the dictionary that previously used raw strings to represent the restricted values must be manually updated to use the Java enum values.
xsd:dateTime in Migrated Dictionaries
Oracle Business Rules Release 10.1.3.x uses JAXB 1.0. In JAXB 1.0,
xsd:dateTime types are mapped to
java.util.Calendar. Oracle Business Rules for Oracle Fusion Middleware 11g Release 1 (11.1.1) uses JAXB 2.0. In JAXB 2.0,
xsd:dateTime types are mapped to
XMLGregorianCalendar, which more accurately contains the values of an
xsd:dateTime element. Thus, in a dictionary migrated from Release 10.1.3.x, comparisons between properties may no longer function correctly because
Calendar implements a method
XMLGregorianCalendar implements a method
compare. Manual changes are required in the dictionary to change the comparisons. Alternatively, in Oracle Fusion Middleware 11g Release 1 (11.1.1) you can use a
Duration to compare most common date and time formats. Making this change in a migrated dictionary requires manual changes to the data model and to the rules that use the imported fact types.
Invalid Expressions in Migrated Dictionary
Oracle Business Rules for Oracle Fusion Middleware 11g Release 1 (11.1.1) supports rich type-checking that invalidates some expressions migrated from Release 10.1.3.x. For example, if an instance of
Integer is referenced to call the
intValue() method, this may produce a validation warning if
Integer has not been imported into the data model. The solution to this issue is to import
Integer into the data model.
Index-based or Iterator-based Iteration in Collections with RL Functions
In Release 10.1.3.x, it was necessary in functions and RL actions to use index-based or iterator-based iteration over collections with raw RL. In Oracle Fusion Middleware 11g Release 1 (11.1.1), the pre-defined action type "for" implements the for-each iteration loop construct and can replace most uses of these older iteration constructs.
Calling Functions to Return New Variable Instances
In Release 10.1.3.x, it was not possible to invoke a constructor in the initialization expression for a variable. In Oracle Fusion Middleware 11g Release 1 (11.1.1) variables are called globals. Due to this Release 10.1.3.x limitation, in some Release 10.1.3.x dictionaries, there are function calls to initialize expressions and to invoke the constructor and return the new instance. In Oracle Fusion Middleware 11g Release 1 (11.1.1), you can use the
new operator in initialization expressions.
In Release 10.1.3.x, a property was created for a fact type if the fact type had either a setter or getter. In Oracle Fusion Middleware 11g Release 1 (11.1.1), a property is created only if there is both a setter and a getter for the property.
In Oracle Fusion Middleware 11g Release 1 (11.1.1), there is a requirement that Java and XML fact types in a dictionary have a single-inheritance chain as determined by visible fact types. This limitation prevents multiple-inheritance chains, including interfaces, from causing runtime exceptions in the engine. The user must specify a single-inheritance chain by marking classes which should not be considered in an inheritance chain as non-visible. When a multiple-inheritance chain is detected during validation, the follow warning is returned:
RUL-05003: The visible fact type "Foo" should only inherit from one visible fact type, but inherits from visible fact types "Bar" and "Baz".
In this case, marking either
Baz as non-visible will fix this warning.
Saving any dictionary in a repository causes all decision points using that repository to refresh their rule session pools, even if the dictionary which they use did not change. This degrades performance, but will not cause errors in general.
Performing an action which causes a "delete" notification to occur will cause the decision point to attempt to refresh its rule session pool. An example of this is RuleRepository.saveAs, which first deletes the dictionary with the target name and then saves the new dictionary with that name. This results in a race condition if the decision point attempts to load the dictionary after it has been deleted but before the new one has been saved.
In a decision table where sibling cell values overlap in any condition row except for the last, the rules recommended by the "gap analysis" feature may be incorrect. A sibling cell is a cell in the same row and with the same parent cell or no parent cell. An example of overlap is one cell with "true" and a sibling with "-".
The Business Rules Service Engine throws an exception for some XML Schemas. This issue only occurs for schemas where the root element is a named
complexType instead of an anonymous
complexType.Workaround: Modify the schema to use an anonymous
complexType instead of a named
complexType for the root element.
In XML Schema, one can use multiple namespaces in schemas which import other schemas. The Oracle Business Rules Service Engine forces the JAXB objects generated upon deployment to use the root schema's namespace as their package name, instead of allowing the namespaces to default to those defined in the imported schemas. When a schema is imported into a rules dictionary using Rule Designer, the schemas are allowed to use their individual namespaces to generate the JAXB class package names. This conflict causes a runtime exception when the application is deployed because classes with the appropriate package name cannot be found.
To fix this, use JAR command and place all the types under the ./rulesdesigner/jaxb_classes and then put that jar into the project SCA-INF/lib folder and redeploy. You may have to restart the SOA_Server WLS instance once the deployment is finished.
It is not possible cut and paste an entire decision table if it has more than one condition row. This results in an exception and a malformed pasted decision table.
The cut and paste of a decision table produces the following exception:
java.lang.IllegalStateException: extra dim nodes in rules
There is no workaround for this problem.
This section describes configuration issues and their workarounds. It includes the following topics:
If you see the error "Too Many Open Files" while deploying an Oracle Business Rules Decision Component, you might need to increase the file descriptor limit.
The "Too many open files" issue is due to JDK6 bugs. These bugs could occur at runtime or at compile time, depending on the number of JAR files used and a few other variations around the use of file descriptors by the JDK/JRE.
Workaround for this issue is to increase the limit of file descriptors. Per-process, per-user file descriptor limit can be preconfigured by default to the value 1024. If you increase this limit to 4096 or larger, the new value should resolve this issue.
These are the potentially relevant JDK6 bugs,
And a blog entry describes this issue at
To increase per-process, per-user file descriptor limit on a Linux system, do the following:
limit (csh) or
ulimit (bash) command, find out what the value of descriptors are.
If the descriptors value is 1024, this value may be too low. As a root user, using the
sudo command, edit
/etc/security/limits.conf to increase the descriptor limit.
After changing the configuration, restart the machine with the updated larger value. For example using the
4096 value setting.
Example 18-1 shows the
limits.conf file with the increased limit for all users to 4096.
Example 18-1 Sample limits.conf file
#<domain> <type> <item> <value> # #* soft core 0 #* hard rss 10000 #@student hard nproc 20 #@faculty soft nproc 20 #@faculty hard nproc 50 #ftp hard nproc 0 #@student - maxlogins 4 # End of file svrtech soft memlock 500000 svrtech hard memlock 500000 * soft nofile 4096 * hard nofile 4096