Oracle Business Rules

Phil Varner & Chris Cowell-Shah

Oracle Business Rules was first released as part of the Oracle Fusion Middleware 10.1.3.x stack. Since it was released, we’ve gained valuable knowledge about its use, and in particular about the use of the Rule Author rule development tool, in various customer environments. Understanding how other customers have successfully used Rule Author in OBR version 10.1.3.x can help make your own rules development experience more efficient and can make harnessing the power of rules that much easier.

Note that in many cases the tips provided below are obviated by changes made in OBR version 11 and in Rules Designer, the authoring tool that that replaces Rule Author in version 11.

Updating the datamodel to reflect changes to XML schema

Issue: XML fact types are based on XML schemas, and Java fact types are based on Java classes. When XML schemas are changed, you should re-import them to the datamodel in order to update the XML fact types. This updating happens automatically when Java classes change, but when XML schemas change, you need to take extra steps to update XML fact types.

Action in 10: When an XML schema changes, remove the schema from the schemas list and then re-add it to force the JAXB classes to regenerate and the import tree to be updated. Then select and import the changed elements.

Action in 11: Rules Designer contains a button that re-imports all XML schemas on command, updating all XML fact types automatically.

Removing a fact type property, method, or field

Issue: Removing fact type properties, methods, or fields can be tricky in Rule Author. Removing one of these items invalidates any rules that use it, which blocks dictionary updates. Unfortunately, Rule Author allows you to edit only one rule between dictionary updates. This means that whenever multiple rules are affected by the removal of a fact type element, you will find yourself in a catch-22: you must modify all rules before the dictionary can be updated successfully, but only one rule can be edited between updates.

Action in 10: To remove a property, method, or field from a fact type, first remove all references to it in all rules, then remove the fact type element. If there are references in any rules to a missing fact type element, a validation warning appears when that rule is next saved. Unfortunately this warning doesn’t describe where the reference to the missing item is, so you must manually search the rules for it. If the item occurs in more than one rule, another validation error appears when you update the dictionary. In that case, you must re-add the item to the data model, remove references to the item from all rules, and then try again to remove the item from the data model.

Action in 11: When you remove an element from a version 11 fact type, rules that use it return validation warnings, but you can still save the dictionary.

Renaming a fact type property, method, or field

Issue: Changing the name of a fact type property, method, or field takes several steps.

Action in 10: To rename a fact type property, method, or field, you need to both remove the original fact type element and create a new one with a different name. Here’s how to do this. First, add the new item. Next, change all references in rules from the old item to the new item. Finally, remove the old item according to the directions in “Removing a fact type property, method, or field” above.

Action in 11: Follow the same general procedure of adding a new item and deleting the old item. However, if you give the new item the same alias as the old item, Rules Designer will automatically replace any references in rules to the old item with references to the new item. You can then change the alias of the new item, and rules will maintain their references to the new item.

Changing the signature of an RL function

Issue: Changing the signature of an RL function does not update the expression table for each usage of the function. This can cause invalid RL to be generated.

Action in 10: When the signature of an RL function is changed (i.e., parameters are added or removed), perform the following steps for each use of the RL function:

1. Open the usage in the action editor.
   
2. Copy and paste all parameter values to a text document.
   
3. Select a function other than the one that is changing. This clears the expression table.
   
4. Select the original function. The expression table contains the correct parameters, but the parameter values are blank
   
5. Copy and paste the parameter values from the text document into the expression table.

Action in 11: Changing the signature of a function creates validation warnings for any references to the function. This makes it easy to see where to change the function call parameters.

Adding an Action other than to the end of the action list

Issue: Adding an action anywhere other than the end of the action list.

Action in 10: This is not possible.

Action in 11: You can create actions in, or move actions to, any position within the action list.

Complex rule actions

Issue: The limited number of rule action types and limited action management capability make it difficult to write complex rule actions.

Action in 10: Write complex rule actions as RL functions, and call them via a Call rule action.

Action in 11: A greatly expanded number of predefined actions and better action management mean that most rule actions should not need to call RL functions.

Writing RL functions

Issue: Writing RL functions in Rule Author is difficult

Action in 10:

1. The bodies of RL functions are not validated for correctness at design-time. It is therefore possible to write an RL function body that will generate invalid RL code. When writing RL functions in Rule Author, we recommend that you frequently go to the “RL” tab, select the “DM” ruleset, click “Check RL Syntax,” and correct any errors shown.
   
2. You must refer to all Java classes by their fully qualified names. Classes used only in the body of the function (not in the parameters list) do not need to be imported into the datamodel, but must be on the JVM classpath at runtime.

Action in 11: You can construct functions in version 11 in the same way that you construct rule actions, with validation checks at design time. There are several new types of predefined actions, including modify, assign new, for, and while. Free-form functions are allowed in 11 in order to preserve backwards compatibility with 10, but their use is discouraged. They are more difficult to use because the SDK automatically generates RL-compliant names for most items, and these names are difficult for you to determine even though you need to use the names (rather than aliases) while writing free-form functions. However, the predefined action types cover the vast majority of use cases, so free-form functions are rarely necessary.

JAXB derived types

Issue: The Oracle XDK JAXB implementation has a bug that prevents the proper functioning of “unbounded” elements in derived types. For example, the following XML schema snippet demonstrates the creation of a derived complexType:

    <xs:complexType name="base-type">
        <xs:sequence>
            <xs:element name="foo" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
    </xs:complexType>

    <xs:complexType name="derived-type">
        <xs:complexContent>
            <xs:extension base="tns:base-type">
                <xs:sequence>
                    <xs:element name="bar" type="xs:string" minOccurs="1" maxOccurs="1"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

If this schema is used to generate JAXB classes and unmarshall XML documents, the resulting JAXB object graph will not contain any “foo” elements. This is a bug in the Oracle XDK.

Action in 10: Do not use complexType inheritance in schemas which will be used as the basis for XML Fact Types.

Action in 11: The Sun JAXB 2.0 reference implementation, which is used by default, does not have this issue.

Writing RL functions that can be called from a BPEL Decision Service

Issue: RL functions that can be called from a BPEL Decision Service must conform to a specific signature. If they don’t, the functions won’t appear when creating the decision service.

Action in 10: The RL function must return an XML fact type that represents an element (not a complexType) and must only have parameters of element type. XML fact types representing complexTypes typically have the suffix “Type” while element XML fact types typically do not this prefix.

Action in 11: Version 11 introduces the more robust concept of a “decision function,” which is the only thing a decision service can call.

Defining a Pattern

Issue: When creating a pattern, Rule Author presents three options: blank, “there is a case where.” and “there is no case where.” It is not always clear which option to use. If you choose “there is a case where,” the pattern variable does not appear as a valid option in the action part of the rule.

Action in 10: The blank option is the default and is a valid choice. It means “for each case” and will execute the rule’s actions for each instance of a fact matching the pattern. The other two options involve existential quantifiers. A rule defined with “there is a case where” will fire if there is at least one match, but the rule’s action does not get a reference to any specific fact instance that matched. Since the rule has no reference to a specific instance, the pattern variable doesn’t appear in the action option lists.

A rule defined with “there is no case where” will only fire if no fact matches the rule’s pattern. In this case, the rule’s action would not be able to reference a fact instance.