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:
Section 18.1.1, "Migration of Common Java Classes with Aliases Applied"
Section 18.1.2, "Alias and Visibility Settings Not Always Applied to Migrated Dictionary"
Section 18.1.3, "Manual Updates Required for Release 10.1.3.x Migrated Dictionaries"
Section 18.1.4, "Migrator Does not Migrate Certain Java Fact Type Properties"
Section 18.1.5, "Migrator Throws a RUL-05003 Warning in Some Cases"
Section 18.1.6, "Need to Hide Certain Properties When Using Classes with Misbehaving Methods"
Section 18.1.7, "Oracle Business Rules Expressions: New Options and Built-in Functions"
Section 18.1.8, "Exceptions When Opening a Dictionary From BPEL/Composite After Rename"
Section 18.1.10, "SOA Composer Limitation: A Boolean Bucketset is Shown by Default"
Section 18.1.11, "SOA Composer Limitation: Working with Oracle Business Rules Dictionary"
Section 18.1.13, "SOA Composer Limitation: Split and Merge Selected Cells Operations Do Not Work"
Section 18.1.14, "SOA Composer Limitation: Composer Does Not Support Localized Number Formatting"
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.
Oracle Business Rules expressions used in Rules Designer and 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.
There can be errors, such as the following when you open a dictionary from a BPEL/composite after a 'Rename' from the Oracle JDeveloper menu option File -> Rename:
java.io.FileNotFoundException
This is due to Oracle JDeveloper not fully supporting name changes for an Oracle Business Rules dictionary.
There is no workaround for this issue.
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 SOA Composer. For example, the Functions tab functionality is missing, the Links tab functionality is missing, and you cannot add new rulesets with SOA Composer.
A Boolean bucketSet(LOV) is shown in the LOV list of bucketsets when you access a dictionary with SOA Composer. This bucketSet cannot be deleted. If you attempt to delete this bucketset, you will see the following exception:
javax.servlet.ServletException: Index: 0, Size: 0
Workaround: you can ignore this default built-in boolean bucketset.
In SOA Composer, when working with a reasonable sized Oracle Business Rules dictionary, there are some performance issues. For example, with SOA Composer there is a significant performance degradation if you attempt to open and view a dictionary with fifty (50) items in a Decision Table.
You cannot revert changes to a dictionary unless the dictionary is valid. For example, if you edit a dictionary and then make some changes such that dictionary is invalid, if you then try to revert the changes, you will see messages such as the following:
Please correct all the errors before saving!
Using SOA Composer you must correct all validation errors before you perform a revert operation.
Using SOA Composer with a Decision Table, the split and merge selected cells operations do not work.
There is no workaround for this issue.
SOA Composer does not support any number formatting. For example, you are using SOA Composer with U.S. English as the browser language. You enter a floating-point data, such as 34533223.2345, as a value. However, when you change the browser language to French, the value is still displayed as 34533223.2345. In French, the value should have been displayed as 34533223,2345.
Workaround:
Irrespective of the browser language, you need to enter any numeric value in the U.S. English language without any number separator such as ",".
SOA Composer does not display any dictionary if you deploy a dictionary that contains no rulesets.
Workaround:
You need to add at least one ruleset to all dictionaries, even if it contains no rules. To avoid conflicts, it is best to name this blank ruleset with a random name rather than the default name of "Ruleset_1".
In a ruleset, using SOA Composer, you can customize the rule effective date that contains the time zone information. However, the time zone information is not saved and is converted to the server time automatically when you re-editing the rule.
There is no workaround for this issue.
Using Rules Designer in JDeveloper, you can customize the date, time and time zone in a bucketset. However, in SOA Composer, you cannot specify the time zone, because the SOA Composer does not have any option to customize the time zone using the Choose Time & Date picker. So, the time displayed is, by default, the server time.
There is no workaround for this issue.
When new rule dictionaries are deployed, the list of dictionaries in the existing SOA Composer session does not automatically refresh to display the new list.
Workaround:
You need to click the Clear button in the search area of the Rules Navigator. This refreshes the list to display the newly added dictionaries along with the existing ones.