Oracle Business Rules allow process analysts to change policies that are expressed as business rules, with little or no assistance from a process developer. Applications using Oracle Business Rules support continuous changes that allow the applications to adapt to new government regulations, improvements in internal company processes, or changes in relationships between customers and suppliers.

Use business rules to define key decisions and policies for a business, including:

• Business policies such as spending policies and approval matrices.

• Constraints such as valid configurations or regulatory requirements.

• Computations such as discounts or premiums.

• Reasoning capabilities such as offers based on customer value.

For example, a car rental company might use the following business rule:

IF
Rental_application.driver age < 21
THEN
modify Rental_application(status: "Declined")

An airline might use a business rule such as the following:

IF
Frequent_Flyer.total_miles > 10000
THEN
modify Frequent_Flyer (status : "GOLD")

A financial institution could use a business rule such as:

IF
Application_loan.income < 10000
THEN
modify Application_loan (deny: true)

These examples represent individual business rules. In practice, you can use Oracle Business Rules to combine many business rules or to use more complex tests.

Oracle Business Rules provides multiple approaches to writing rules:

• IF/THEN rules - expressed as IF/THEN statements.

  There are two ways of modeling IF/THEN rules. General rules use a pseudo-code language to express rule logic. Verbal rules use natural language statements to express rule logic.

• Decision Tables, which display multiple related rules in a single spreadsheet-style view.

Business phrases are used to provide a natural language vocabulary for the construction of verbal rules' tests and actions. They are not used in general rules.

General rules, verbal rules, and Decision Tables are grouped in an Oracle Business Rules object called a ruleset. (See Working with Rulesets.)

You group one or more rulesets and their facts and valuesets in an Oracle Business Rules object called a dictionary.

For a complete discussion of the concepts behind general and verbal rules, Decision Tables, and business phrases, see the "Working with Rulesets and Rules" chapter in Designing Business Rules with Oracle Business Process Management

Rules

Rules follow an IF-THEN structure and consist of two parts:

• IF part: A condition or pattern match.

  The rule IF part is composed of conditional expressions and rule conditions that refer to facts. For example:

  IF Rental_application.driver age < 21
  

  The conditional expression compares a business term (Rental_application.driver age) to the number 21 using a less than comparison.

  The rule condition activates the rule whenever a combination of facts makes the conditional expression true. In some respects, the rule condition is like a query over the available facts in the Rules Engine, and for every row returned from the query the rule is activated.

• THEN part: A list of actions.

  The rule THEN part contains the actions that are run when the rule is fired. A rule is fired after it is activated and selected among the other rule activations using conflict resolution mechanisms such as priority. A rule might perform several kinds of actions. An action can add facts, modify facts, or remove facts. An action can run a Java method or perform a function which may modify the status of facts or create facts.

  Rules fire sequentially, not in parallel. Rule actions often change the set of rule activations and therefore change the next rule to fire.

Decision Tables

A Decision Table is an alternative business rule format that is more compact and intuitive when many rules are required to analyze many combinations of property values. You can use a Decision Table to create a set of rules that covers all combinations or where no two combinations conflict.

For more information about decision tables, see Working with Decision Tables. and the "Working with Rulesets and Rules" chapter in Designing Business Rules with Oracle Business Process Management

The Business Rules Editor allows you to create, view and edit facts, functions, globals, value sets, links, decision functions, and business phrases within a business rules dictionary.

From the Project Welcome Page, go to the Components pane and select Rules. Click the name of the dictionary you want to open.

When you open a business rules dictionary, Oracle Business Process Composer displays the Rulesets page, as shown in Figure 17-1.

A ruleset is an Oracle Business Rules container for rules and Decision Tables. A ruleset provides a namespace, similar to a Java package, for rules and Decision Tables. In addition you can use rulesets to partially order rule firing.

The Business Rules Editor page provides the tools for you to view rulesets and the data model, including:

• Value Sets

• Globals

• Business Phrases

• Explorer

• Facts

• Decision Functions

• Links

• Translations

To edit elements such as the value sets, and globals contained within the opened business rule dictionary, ensure that the project is in edit mode.

The Business Rules Editor page also provides the tools for you to perform the following actions:

• Viewing and Editing Dictionary Settings

• Synchronizing Business Objects

These are accessed from the Actions menu, shown in Figure 17-2

A business rule dictionary is an Oracle Business Rules container for facts, functions, globals, value sets, links, decision functions, and rulesets. A business rule dictionary is an XML file that stores the application's rulesets and the data model.

Dictionaries can link to other dictionaries. Using Oracle Business Process Composer you can create as many dictionaries as you require. A dictionary may contain any number of rulesets.

Using a dictionary with links to another dictionary is useful for data model sharing.

• Data Model Sharing: Share portions of a data model within a project. When you link to a dictionary in another project it is copied to the local project.

  For example, consider a project where you would like to share some Oracle Business Rules functions. You can create a dictionary that contains the functions, and name it DictCommon. Then, you can create two dictionaries, DictApp1 and DictApp2 and link them both to DictCommon. Both can use the same Oracle Business Rules functions and when you want to change one of the functions, you only change the version in DictCommon. Both dictionaries uses the updated function the next time RL Language is generated from either DictApp1 or DictApp2.

In Oracle Business Rules a fully qualified dictionary name is called a DictionaryFQN and this consists of two components:

• Dictionary Package: The package name.

• Dictionary Name: The dictionary name

A dictionary refers to a linked dictionary using its DictionaryFQN and an alias. Oracle Business Rules uses the DictionaryFQN to find a linked dictionary.

The following are the naming constraints for combined dictionaries:

• The full names of the dictionaries, including the package and name, must be distinct.

  In addition, the dictionary aliases must be distinct.

• The aliases of data model definitions of a particular kind, for example, function, Oracle RL class, or value set, must be unique within a dictionary.

• A definition may be qualified by the alias of its immediately containing dictionary.

  Definitions in the top and built-in dictionaries do not have to be qualified. Definitions in other dictionaries must be qualified and this qualification is controlled by the prefix linked names property of the dictionary link.

• Ruleset names must be unique within a dictionary.

  When RL Language for a ruleset is generated, the dictionary alias is not part of any generated name. For example, if the dictionary named DictApp1 links to DictApp2 to create a combined dictionary, and DictApp1 contains ruleset_1 with rule_1 and DictApp2 also contains ruleset_1 with rule_2, then in the combined dictionary both of these rules, rule_1 and rule_2 are in the same ruleset (ruleset_1).

• All rules and Decision Tables must have unique names within a ruleset.

  For example, within a combined dictionary that includes dictionary DictApp1 links to DictApp2, dictionary DictApp1 may have a ruleset named Ruleset_1 with a rule rule_1. If dictionaryDictApp2 also has a ruleset named Ruleset_1 with a rule_2, then when Oracle Business Rules generates RL Language from the combined, linked dictionaries, both rules rule_1 and rule_2 are in the single ruleset named Ruleset_1. If you violate this naming convention and do not use distinct names for the rules within a ruleset in a combined dictionary, a validation warning is reported, similar to the following:

  RUL-05920: Rule Set Ruleset_1 has two Rules with name rule_1

Using Oracle Business Process Composer you can edit, add, and delete rulesets.

Note that when you create a new business rule dictionary, a default ruleset is automatically created

A Decision Table displays multiple related rules in a single spreadsheet-style view. In Business Rules Editor, a Decision Table presents a collection of related business rules with condition rows, rules, and actions presented in a tabular form that is easy to understand. Business users can compare cells and their values at a glance and can use Decision Table rule analysis features by clicking icons and selecting values in Business Rules Editor to help identify and correct conflicting or missing cases.

To help understand Decision Table concepts, consider a set of IF/THEN rules that determine if a loan application is approved or rejected.

The IF/THEN rules follow:

if loanAmount < 10,000 and creditRating = poor then loanApprovalStatus = manual_approval
if loanAmount < 10,000 and creditRating = good then loanApprovalStatus = auto_approved
if loanAmount [100,000..500,000] and creditRating = poor then loanApprovalStatus = auto_rejected

Figure 17-8 shows a Decision Table representation that includes these rules and shows areas for Decision Table conditions and actions.

A ruleset contains a Decision Table; this provides a way to group the Decision Table along with IF/THEN rules. When rules and Decision Tables are grouped in a ruleset, the IF/THEN rules and the Decision Table rules all execute as a set of interrelated rules.

A rule in a Decision Table is not named. Although Business Rules Editor shows rules in a Decision Table with labels, for example, R1, R2, and R3, these rule labels are not names for individual rules but are labels derived from the current ordering of the rules in the Decision Table. Therefore, a rule with the label R1 can be moved to position 3 and then Business Rules Editor relabels this rule R3.

Decision Table Conditions

The Conditions area in a Decision Table includes one or more condition rows. Each condition row has a condition expression and, for each rule, a condition cell. A condition expression is an expression that you build in Business Rules Editor. The condition expression is often a fact property or a function result, but it can be any expression that has a type that can be associated with a value set. The value or the range for a given condition cell takes its value or its range from one or more values or ranges in the associated LOV or Ranges value set.

Decision Tables show rules in value order, and to change the order of rules you must change the order of values in the value sets. Therefore, the order of the values in the value set associated with a condition row determines the order of the condition cells, and therefore the order of the rules. You can control rule ordering in a Decision Table by changing the relative position of the values in an LOV value set associated with a condition row; however, you cannot reorder range values.

By default, when you create a condition row, Business Rules Editor creates a single condition cell and assigns the "?" value to the cell. A condition cell with the value "?" indicates that the value of the cell is undefined in the value set.

Decision Table Actions

Actions are associated with rules in a Decision Table. At runtime, when facts match for condition cells, the Rules Engine prepares to run the actions associated with the rule.

Table 17-1 shows the types of actions you can choose in the Actions area. Therefore, in an action you can call a function, assert a new fact, retract a fact, or modify a fact, and so on. In the Actions area the cells corresponding to an individual action for a rule are called action cells.

When you add multiple actions the actions that you add in the Actions area are ordered; actions appearing in the higher rows run before actions in the following rows.

The Decision Table actions such as modify can refer to facts matched in the condition cells. Certain types of actions in the Actions area include a Parameterized check box. This check box specifies that a property from the action can have its value set in the action cell associated with a rule in the Decision Table. When the parameterized check box is selected, the value you supply for the expression value in the action, in the Actions area, becomes the default value for the property if a value is not supplied in the action cell. For example, see Figure 17-9 where the value GOOD is assigned as the default value for the action property loanApprovalStatus.

In the Decision Table Actions area you can specify that an action cell do nothing. In this case, clear the action cell. When the action cell check box is cleared, this means do not perform this action when the pattern matches for the specified condition values in the Decision Table. Therefore, for each action cell you can specify whether the rule associated with the action cell should activate the action, or do not perform the action.

In Oracle Business Rules, facts are the objects that rules reason on. Each fact is an instance of a fact type. You must import or create one or more fact types before you can create rules. Facts are created and edited in BPM Studio. You can view facts in Composer.

In Oracle Business Rules a fact is an asserted instance of a class. The Oracle Business Rules runtime or a developer writing in the Oracle Rule Language (RL) uses the RL Language assert function to add an instance of a fact to the Oracle Business Rules Engine.

Using the Business Rules Editor you can view facts, as shown in Figure 17-11.

Fact types can be based on the following:

• XML Facts: XML Facts are imported from existing sources by specifying XML Schema.

  In BPM Studio, you can add aliases to imported XML Facts or use XML Facts with RL Facts to change the data model according to your business requirements.

• Java Facts: Java Facts are imported from existing sources.

  In BPM Studio, you can add aliases to Java Facts or use them with RL Facts to target the data model to business requirements. Java Facts are also used to import supporting Java classes for use with the rules or Decision Tables that you create.

• RL Facts: RL Facts are the only kind of facts that you can create directly and do not have an external source.

  All other types of Oracle Business Rules facts are imported. An RL Fact is similar to a relational database row or a JavaBean with properties. An RL Fact contains a set of named, typed properties. Property values can be primitives such as String, another structured fact, or a list. RL Facts are useful for rapid and independent development and testing of decision logic. Input data that ultimately comes from an imported fact type (for example, an XML Schema) can be modeled using RL Facts before the imported schema is available or stable. Intermediate decisions that should not be returned to the application (for example, sub-decisions that categorize a customer as GOOD or BAD). It is usually best to import the fact types that are used for the input and output data of a decision. You can use RL Facts to extend a Java application object model by providing virtual dynamic types.

• ADF Business Components Facts: ADF Business Components Facts allow you to use ADF Business Components as Facts in rules and in Decision Tables.

  By using ADF Business Components Facts you can assert view object graphs representing the business objects upon which rules should be based, and let Oracle Business Rules deal with the complexities of managing the relationships between the various related view objects in the view object graph.

In the Oracle Business Rules runtime such fact type instances are called facts.

You can create value sets to define a list of values or a range of values of a specified type. After you create a value set you can associate the value set with a fact property of matching type. Oracle Business Rules uses the value sets that you define to specify constraints on the values associated with fact properties in rules or in Decision Tables.

You can also use value sets to specify constraints for variable initial values and function return values or function argument values.

Using Business Rules Editor you can add, edit, or delete value sets to a business rule dictionary.

Using Business Rules Editor you can add, edit, or delete global variables to a business rule dictionary. You can use global definitions to share information among several rules and functions.

For example, if a 10% discount is used in several rules you can create and use a global Gold Discount, so that the appropriate discount is applied to all the rules using the global.

Verbal rules work hand in hand with business phrases to provide a flexible way author rules using natural language statements to express rule logic in domain specific sentences that are similar to spoken language. Business phrases provide the logic behind conditions that are used in the composition of the verbal rule.

You can write verbal rule tests and actions using derived business phrases as well as user-defined business phrases. Derived business phrases are automatically created using facts, globals and other information in the dictionary while user-defined phrases can be explicitly authored to augment derived phrases. Further, user-defined phrases can either be pre-created or created as required while composing the verbal rule.

As you write a verbal rule, you can use suggested business phrases, or instantiate your own on the fly and provide their implementation details later. Alternatively, you can create the business phrases you require for your verbal rule first, and then complete the verbal rule.

For more information about business phrases and how they work with verbal rules, as well as sample scenarios, see the "Working with Rulesets and Rules" chapter in Designing Business Rules with Oracle Business Process Management.

A decision function is a mechanism for publishing rules and rulesets as a reusable service that can be invoked from multiple business processes. It is the only gateway into the business logic held in business rules because neither business rules nor rulesets are accessible from the outside.

1. Open the business rule dictionary.
2. Go to the toolbar and click Decision Properties.
3. Select a decision function, as shown in Figure 17-15.

   Figure 17-15 Business Rules Editor - Decision Functions

   
   Description of "Figure 17-15 Business Rules Editor - Decision Functions"
4. Enter a name for the Decision Function in Name field.
5. If desired, modify a description in the Description field.
6. Select unlimited or an integer value in the Rule Firing Limit field.

   In some cases when you are debugging a decision function, you may want to enter a value for the rule firing limit. The Rule Firing Limit can also be used in primary rules processing when you want the execution to stop after a specified number of rules fire.

7. Enter the service name in the Service Name field if this decision function is to be invoked as a rule service.
8. The following controls are not editable from Composer:

   • Name

   • Rule Firing Limit

   • Service Name

   • Invoke as a rule service: Is the decision function is to be invoked as a rule service.

   • Check rule flow: Verifies the following to generate validation warnings:

     Types required by rules executed by the decision function are either inputs to the decision function or asserted by other rules.

     Types generated by rules executed by the decision function are either inputs to other rules or outputs to the decision function.

     Note that rule flow checking might not identify rule flow issues spanning Java code that is used in rules. In such cases, the warnings can be ignored by turning off rule flow checking.

   • Stateless: Specifies that the decision function is stateless

     When this check box is selected, which indicates stateless operation. With stateless operation, at runtime, the rule session is released after each invocation of the decision function.

   • Rulesets are on stack once: If selected, Rulesets are not evaluated further once they are popped from the Ruleset stack. When this check box is selected, which indicates stateless operation. With stateless operation, at runtime, the rule session is released after each invocation of the decision function.

9. In the Initial Actions tab, click Add to add initial actions for the decision function. Select from the list, which includes:

   • assertions

   • assignations

   • if, while, for, and so on

   • expression

   • synchronized

   • throw

10. These tabs are not editable from Composer:

    • Inputs Enter an input name and press Enter or accept the default name.

    • Outputs Select the appropriate fact type from the list.

    • Rulesets Decision Fucntions

Use the Explorer tab to view business rules dictionary items.

1. Open the business rule dictionary where you want to edit items.
2. Go to the toolbar and click Explorer.

   The items included in the selected business rules dictionary are listed, as shown in Figure 17-16.

   Figure 17-16 Business Rules Editor - Explorer

   
   Description of "Figure 17-16 Business Rules Editor - Explorer"
3. Select the Show Hidden Items to include hidden items in the list.

Use the Translations tab to view the phrases included in the selected dictionary and their translated strings.

1. Open the business rule dictionary where you want to translate phrases.
2. Go to the toolbar and click Translations.

   The phrases included in the selected dictionary are listed. The languages specified for this project are also listed, as shown in Figure 17-17.

   Figure 17-17 Business Rules Editor - Translations

   
   Description of "Figure 17-17 Business Rules Editor - Translations"
3. Click on the phrase that you want to translate and enter the translated sling in the appropriate language column.

The business rules task is an Oracle BPMN element enables you to incorporate Oracle Business Rules within a process model. When editing a project based on a project template containing business rules in the business catalog, you can assign business rules to business rules task.

1. Open the process containing the business rules task you want to edit.
2. Right-click the business rules task, then select Properties.
3. Select the Implementation tab.
4. Click Change. The displays the business rules browser containing a table of available business rules.
5. Double-click a rule from the table.
6. Click OK.

You can use Business Process Composer to open deployed Oracle BPM projects. Opening a deployed project enables you to edit the Oracle Business Rules contained in the project and deploy your changes back to Oracle BPM runtime.

1. From the Project menu select Open a Deployed Project.

   If you are currently editing a project, your changes are automatically saved.

2. Select Deployed Projects, then select the project you want to open from the project list.
3. Expand Repository, then select the deployed project you want to open.
4. Click Ok.
5. In the Project Navigator, expand Business Rules then expand the rules dictionary where whose Oracle Business Rules you want to edit.
6. Click Edit in the rules editor.
7. Edit the rules as required, then click Save.
8. Click Validate to ensure the changes you made to the business s made are valid.
9. Click Commit to commit the changes to Oracle BPM runtime.
10. Click Yes.
11. From the Project menu, select Close Project.