This chapter describes issues associated with Oracle Business Rules. It includes the following topics:
The issues and workarounds listed here are those that were known at the time of the product's initial release to the public. Additional issues and workarounds may have been discovered since the initial release. To view the latest known issues associated with Oracle SOA Suite, BPM Suite, and related SOA technologies, go to the Oracle Technology Network (OTN) at:
http://www.oracle.com/technetwork/middleware/docs/aiasoarelnotes-196861.html
.
This section describes general issues and workarounds. It includes the following topics:
Section 20.1.1, "Migration of Common Java Classes with Aliases Applied"
Section 20.1.2, "Alias and Visibility Settings Not Always Applied to Migrated Dictionary"
Section 20.1.3, "Manual Updates Required for Release 10.1.3.x Migrated Dictionaries"
Section 20.1.4, "Migrator Does not Migrate Certain Java Fact Type Properties"
Section 20.1.5, "Migrator Throws a RUL-05003 Warning in Some Cases"
Section 20.1.6, "Hiding Certain Properties When Using Classes with Misbehaving Methods"
Section 20.1.7, "Length of Rules Repository Path Should be Less Than 70 Characters"
Section 20.1.8, "Oracle Business Rules Expressions: New Options and Built-in Functions"
Section 20.1.9, "Audit Trail for Upgraded AS11 Rules Components Shows Only Basic Information"
Section 20.1.11, "Local LOVs in a Decision Table Throws an Error When a Name is Not Specified"
Section 20.1.12, "Issue Using Boolean Attribute in Decision Tables Conditions"
Section 20.1.13, "Oracle SOA Composer Provides Only a Subset of Rules Designer Functionality"
Section 20.1.14, "Number Formatting Does Not Work in Specific Cases in Oracle SOA Composer"
Section 20.1.15, "Split and Merge Selected Cells Operations Do Not Work in Oracle SOA Composer"
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: Object
, String
, BigInteger
, BigDecimal
, Calendar
, XMLGregorianCalendar
, List
, and JAXBElement
.
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.
Workaround:
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.
Workaround:
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.
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 compareTo
and 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 Bar
or Baz
as non-visible will fix this warning.
When asserting instances of some classes exceptions may be thrown because of misbehaving methods. When a fact is asserted, the fact is "shadowed" inside the rules engine. This shadowing requires the rules engine to invoke the accessors for all properties with the Visible checkbox selected (for all visible properties). If an accessor throws an exception when it is invoked, this exception propagates out of the rules engine.
A specific example of this limitation is the java.sql.Date
class. This class includes several deprecated methods, for example getYears
and setYears
. These methods always throw an IllegalArgumentException
when they are invoked. In Oracle Business Rules, if an instance of the Date
class is asserted, an exception is thrown. This exception is due to the getYears
method being called when the fact instances are shadowed inside the rules engine.
When using Oracle Business Rules, the Date
class should not be asserted, but this assert may be out of the control of the user. For example the Date
class is asserted when a large object graph contains a list of Date
instances and you are using assert tree on the object graph.
Workaround:
You must mark all properties that include misbehaving methods as non visible. To do this you must deselect the Visible checkbox for the properties that cause an exception. For example, in the java.sql.Date
class., the workaround is to deselect the Visible checkbox for the properties "years", "hours", and "minutes" for the java.sql.Date
fact type in the datamodel.
While configuring the rules repository path, it is recommended to limit the length of the path to 70 characters. If the length exceeds 70 characters, you would encounter problems after any DT/RT changes from Oracle SOA Composer.
So, as a best practice, after you design the rules, ensure that the repository path length is less than 70 characters.The following path taken from a sample rule.decs file fails after DT/RT changes at run time:
<path>OrderBookingComposite/oracle/rules/com/example/globalcompany/orderbooking/approvalrule/RequiresApprovalRule.rules</path>
Oracle Business Rules expressions used in Rules Designer and Oracle Oracle SOA Composer support the following:
Expressions support the new RL syntax. For example,
(assign new) Driver d = new Driver(name: "Tom", age: 45)
Expressions support the instanceof
keyword: For example,
if (vehicle instanceof Car) { (assign new) Car car = (Car)vehicle; } else if (vehicle instanceof Truck) { (assign new) Truck truck = (Truck)vehicle; }
Expressions support the list type built-in functions, including the following:
RL.list.intersect RL.list.reverse RL.list.insertBefore RL.list.concatenate RL.list.union RL.list.append RL.list.except RL.list.distinctValues RL.list.remove RL.list.indexOf RL.list.create
For more information, see the descriptions in oracle.rules.rl.extensions.RL
, in Oracle Fusion Middleware Java API Reference for Oracle Business Rules Javadoc.
Expressions can support a variable number of arguments. As in the Java Language, when the last parameter to a function or method is an array, then an expression can call the function or method with a variable number of arguments. For example, using the built-in RL.list.create
function in an expression:
RL.list.create(Object[] items) returns List
The built-in RL.list.create()
can be called as follows:
(assign new) List myList = RL.list.create(1, 2.0, "three")
In this example, the myList
result contains three Objects: an Integer, a Double, and a String.
Expressions support locale-sensitive formatted number strings.
For example, in English locales:
(assign new) BigDecimal i = "1,000,000.1"
In German locales:
(assign new) BigDecimal i = "1.000.000,1"
The locale-insensitive number format would have been:
(assign new) BigDecimal i = 1000000.1
After you upgrade AS11 Oracle Business Rules components to AS11 PS2, the audit trail for the composite instances created before upgrade shows only basic information. The decision trace includes only the name of the Decision Function invoked and the timestamp.
Workaround:
You can view other details of the trace, such as the values of input and output facts by using the BPELProcess Audit Trail.
If Oracle JDeveloper is started in native encoding (non-UTF8 encoding), when you create a business rule in a composite using non-English names, the non-English business rule name, which are part of the namespace in the newly generated decisionService type schema under the xsd folder, appear as garbled. This is because the business rule name is generated in the schema by using the native encoding of the client, and not using UTF-8.
Workaround:
Open the decisionService
type schema in Oracle JDeveloper, change the garbled words back to the non-English business rule name, and save. The non-English name is saved in UTF8 and business rule can work fine in both design time and run time.
In a Decision Table, local List Of Values (LOV) bucketsets throws the following error when a name is not specified:
Invalid name specified.
Workaround:
When you create local LOV bucketsets in a Decision Table, specify a name for the bucketset.
Consider the following schema:
<xs:complexType name="RulesObjectType"> <xs:sequence> <xs:element name="value" nillable="true" type="xs:int"/> <xs:element name="flag" nillable="true" type="xs:boolean"/> </xs:sequence> </xs:complexType>
When you use the nillable
boolean attribute in Decision Table conditions, editing the attribute bucketset does not yield a valid result. This is because Rules SDK is unaware of java.lang.Boolean
, so it does not know that it should map to the built-in bucketset.
Workaround:
Append .booleanValue()
to the condition, for example, RulesObject.flag.booleanValue()
.
In addition, you have to import java.lang.Boolean
.
Oracle SOA Composer provides only a subset of the functionality available in Rules Designer. Some of the features/tabs in Rules Designer are currently not available in Oracle SOA Composer. For example, the Functions tab functionality is missing and you cannot add new rulesets with Oracle SOA Composer.
In Oracle SOA Composer, you create an if-then
rule. In the "if" part, when you write some conditions based on numbers and leave the "then" part empty, the number formatting in "if" conditions does not work.
For example, create an if-then
rule, write the following "if" condition based on an integer
process.inputint is 111,111 (constant)
Leave the "then" part empty.
Save the rule, log out and and log on to Oracle SOA Composer in the fr_FR
locale.
The number formatting of the "if" condition is displayed as 111,222
.
Workaround:
Specify some action in the "then" part of the rule.
When using Oracle SOA Composer with German (de
), Italian (it
), or Portuguese (pt_BR
) locales, if you add an "if" condition based on integer, then the integer number formatting in this condition does not work.
Workaround:
Create the "if" condition based on integer in other locales such as en_US
.
Using Oracle SOA Composer with a Decision Table, the split and merge selected cells operations do not work.
There is no workaround for this issue.
In a Oracle SOA Composer Decision Table, when a row is selected, the Bucketset Editor, the Condition Browser, and the Action Editor buttons are displayed on the Decision Table toolbar.
However, when the rows and columns are switched, all these buttons are displayed on the column header.
There is no workaround for this issue.
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,
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6533291
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6485027
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6400872
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6456960
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6206485
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6446657
And a blog entry describes this issue at
http://coldfused.blogspot.com/2007/02/mystery-of-too-many-open-files.html
To increase per-process, per-user file descriptor limit on a Linux system, do the following:
Using 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 20-1 shows the limits.conf
file with the increased limit for all users to 4096.
Example 20-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