Skip Headers
Oracle® Fusion Middleware User's Guide for Oracle Business Rules
11g Release 1 (11.1.1.5.0)
Part Number E10228-06
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Feedback page
Contact Us
Go to previous page
Previous		 Go to next page
Next
PDF · Mobi · ePub

1 Overview of Oracle Business Rules

Oracle Business Rules enable dynamic decisions at runtime allowing you to automate policies, computations, and reasoning while separating rule logic from underlying application code. This allows more agile rule maintenance and empowers business analysts with the ability to modify rule logic without programmer assistance and without interrupting business processes.

This guide describes how to:

This chapter includes the following sections:

For more information, see:

1.1 What are Business Rules?

Business rules are statements that describe business policies or describe key business decisions. For example, business rules include:

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

Description of intro_driver.gif follows
Description of the illustration intro_driver.gif

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

Description of intro_fyer.gif follows
Description of the illustration intro_fyer.gif

A financial institution could use a business rule such as:

Description of intro_loan.gif follows
Description of the illustration intro_loan.gif

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.

For the car rental example, you can name the rule the Driver Age Rule. Traditionally, business rules such as the Driver Age Rule are buried in application code and might appear in a Java application as follows:

public boolean checkDriverAgeRule (Driver driver) { 
   boolean declineRent = false;  
   int age = driver.getAge();
   if(  age < 21 ) { 
      declineRent = true; 
   }
   return declineRent; 
}

This code is not easy for nontechnical users to read and can be difficult to understand and modify. For example, suppose that the rental company changes its policy so that all drivers under 18 are declined using the Driver Age Rule. In many production environments the developer must modify the application, recompile, and then redeploy the application. Using Oracle Business Rules, this process can be simplified because a business rules application is built to support easily changing business rules.

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

A rule follows an if-then structure and consists of the following parts:

Alternatively, you can express rules in a spreadsheet-like format called a Decision Table (see Section 1.1.3, "What Are Decision Tables?").

You write rules and Decision Tables in terms of fact types and properties. Fact types are often imported from the Java classes, XML schema, Oracle ADF Business Components view objects, or may be created in Rules Designer. Fact properties have a name, value, data type, and an optional bucketset. A bucketset splits the value space of the data type into buckets that can be used in Decision Tables, choice lists, and for design time validation (see Section 1.1.4, "What Are Facts and Bucketsets?").

You group rules and Decision Tables in an Oracle Business Rules object called a ruleset (see Section 1.1.5, "What Are Rulesets?").

You group one or more rulesets and their facts and bucketsets in an Oracle Business Rules object called a dictionary (see Section 1.1.8, "What Are Dictionaries?").

For more information, see Section 1.2, "Oracle Business Rules Runtime and Design Time Elements".

1.1.1 What Are Rule Conditions?

The rule IF part is composed of conditional expressions, 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.

For more information, see:

1.1.2 What Are Rule Actions?

The rule THEN part contains the actions that are executed 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 execute a Java method or perform a function which may modify the status of facts or create facts.

Rules fire sequentially, not in parallel. Note that rule actions often change the set of rule activations and thus change the next rule to fire.

For more information, see:

1.1.3 What Are Decision Tables?

A Decision Table is an alternative business rule format that is more compact and intuitive when many rules are needed 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, see Chapter 5, "Working with Decision Tables".

1.1.4 What Are Facts and Bucketsets?

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.

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

In Rules Designer you can define a variety of fact types based on, XML Schema, Java classes, Oracle RL definitions, and ADF Business Components view objects. In the Oracle Business Rules runtime such fact type instances are called facts.

You can create bucketsets to define a list of values or a range of values of a specified type. After you create a bucketset you can associate the bucketset with a fact property of matching type. Oracle Business Rules uses the bucketsets that you define to specify constraints on the values associated with fact properties in rules or in Decision Tables. You can also use bucketsets to specify constraints for variable initial values and function return values or function argument values.

For more information, see:

1.1.5 What Are Rulesets?

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.

For more information, see:

1.1.6 What Are Decision Functions?

A decision function provides a contract for invoking rules from Java or SOA (from an SOA composite application or from a BPEL process). The contract includes input fact types, rulesets to run, and output fact types. For more information, see Chapter 6, "Working with Decision Functions".

1.1.7 What Are Decision Points?

Oracle Business Rules SDK (Rules SDK) provides APIs that let you write applications that access, create, modify, and execute rules in Oracle Business Rules dictionaries (and all the contents of a dictionary). The Rules SDK provides the Decision Point API to access and run rules or Decision Tables from a Java application. For more information, see Chapter 7, "Working with Rules SDK Decision Point API".

1.1.8 What Are Dictionaries?

A dictionary is an Oracle Business Rules container for facts, functions, globals, bucketsets, links, decision functions, and rulesets. A dictionary is an XML file that stores the application's rulesets and the data model. Dictionaries can link to other dictionaries. Oracle JDeveloper creates an Oracle Business Rules dictionary in a .rules file. You can create as many dictionaries as you need. A dictionary may contain any number of rulesets. For more information, see Section 2.2, "Working with a Dictionary and Dictionary Links".

1.2 Oracle Business Rules Runtime and Design Time Elements

Oracle Business Rules provides support for using business rules as a Decision component or as a library in a Java application. A Decision component is a mechanism for publishing rules and rulesets as a reusable service that can be invoked from multiple business processes. To create and use rules in the Oracle SOA Suite, or to create rules and integrate these rules into your applications, Oracle Business Rules provides the following runtime and design time elements:

1.2.1 Decision Component (Business Rules) in an SOA Composite Application

Oracle SOA Suite provides support for Decision components that support Oracle Business Rules. A Decision component is a mechanism for publishing rules and rulesets as a reusable service that can be invoked from multiple business processes.

A Decision Component is a SCA component that can be used within a composite and wired to a BPEL component. Apart from that, Decision components are used for dynamic routing capability of Mediator and Advanced Routing Rules in Human Workflow.

Oracle Business Rules Rules Engine (Rules Engine) is available in an SOA composite application using the SOA Business Rule service engine that efficiently applies rules to facts and defines and processes rules.

Rules Engine has the following features:

  • High performance: Rules Engine implements specialized matching algorithms for facts that are defined in the system.

  • Thread-safe execution suitable for a parallel processing architecture: Rules Engine provides one thread that can assert facts while another is evaluating the network.

For more information, see Section 1.3, "Oracle Business Rules Engine Architecture".

1.2.2 Using Rules Engine with Oracle Business Rules in a Java EE Application

Oracle Business Rules Rules Engine (Rules Engine) is available as a library for use in a Java EE application (non-SOA). Rules Engine efficiently applies rules to facts and defines and processes rules. Rules Engine defines a Java-like production rule language called Oracle Business Rules RL Language (RL Language), provides a language processing engine (inference engine), and provides tools to support debugging.

Oracle JDeveloper Rules Designer allows business rules to be specified separately from application code. Separating the business rules from application code allows business analysts to change business policies quickly with graphical tools. The Rules Engine evaluates the business rules and returns decisions or facts that are then used in the business process.

Rules Engine has the following features:

  • High performance: Rules Engine implements specialized matching algorithms for facts that are defined in the system.

  • Thread-safe execution suitable for a parallel processing architecture: Rules Engine provides one thread that can assert facts while another is evaluating the network.

A rule-enabled Java application can load and run rules programs. The rule-enabled application passes facts and rules to the Rules Engine (facts are asserted in the form of Java objects or XML documents). The Rules Engine runs in the rule-enabled Java application and uses the Rete algorithm to efficiently fire rules that match the facts.

For more information, see Section 1.3, "Oracle Business Rules Engine Architecture" and Section 1.2.4, "Oracle Business Rules SDK".

1.2.3 Oracle Business Rules RL Language

Oracle Business Rules supports a high-level Java-like language called Oracle Business Rules RL Language (RL Language). RL Language defines the valid syntax for Oracle Business Rules programs. RL Language includes an intuitive Java-like syntax for defining rules that supports the power of Java semantics, providing an easy-to-use syntax for application developers. RL Language consists of a collection of text statements that can be generated dynamically or stored in a file.

Using RL Language application programs can assert Java objects as facts, and rules can reference object properties and invoke methods. Likewise, application programs can use XML documents or portions of XML documents as facts.

Programmers can use RL Language as a full-featured rules programming language both directly and as part of the Oracle Business Rules SDK (Rules SDK).

Business analysts can use Rules Designer to work with rules. In this case, the business analyst does not need to directly view or write RL Language programs. For more information, see Section 1.2.5, "Rules Designer".

For detailed information about RL Language, see Oracle Fusion Middleware Language Reference Guide for Oracle Business Rules.

1.2.4 Oracle Business Rules SDK

Oracle Business Rules SDK (Rules SDK) is a Java library that provides business rule management features that a developer can use to write a rule-enabled program that accesses a dictionary, or to write customized rules programs that add rules or modify existing rules. Rules Designer uses Rules SDK to create, modify, and access rules and the data model using well-defined interfaces. Customer applications can use Rules SDK to access, display, create, and modify collections of rules and the data model.

You can use the Rules SDK APIs in a rule-enabled application to access rules or to create and modify rules. The rules and the associated data model could be initially created in a custom application or using Rules Designer.

This guide describes the Oracle Business Rules SDK Decision Point API. Using a Decision Point you can access a dictionary and run the rules in the dictionary. For complete Oracle Business Rules SDK API information, see Oracle Fusion Middleware Java API Reference for Oracle Business Rules.

For more information, see Chapter 7, "Working with Rules SDK Decision Point API".

1.2.5 Rules Designer

The Oracle Business Rules Designer (Rules Designer) extension to Oracle JDeveloper is an editor that enables you to create and edit rules as Figure 1-1 shows.

Figure 1-1 Oracle JDeveloper with Rules Designer

Description of Figure 1-1 follows
Description of "Figure 1-1 Oracle JDeveloper with Rules Designer"

Rules Designer provides a point-and-click interface for creating rules and editing existing rules. Using Rules Designer you can work directly with business rules and a data model. You do not need to understand the RL Language to work with Rules Designer. Rules Designer provides an easy way for you to create, view, and modify business rules.

Rules Designer supports several types of users, including the application developer and the business analyst. The application developer uses Rules Designer to define a data model and an initial set of rules. The business analyst uses Rules Designer either to work with the initial set of rules or to modify and customize the initial set of rules according to business needs. Using Rules Designer a business analyst can create and customize rules with little or no assistance from a programmer.

1.2.6 Oracle SOA Composer Application

When a dictionary is deployed in an SOA composite application, Oracle Business Rules lets you view the dictionary or edit and save changes to the dictionary. You can use the SOA Composer application (SOA Composer) to work with a deployed dictionary that is part of an SOA composite application, as Figure 1-2 shows.

Figure 1-2 Using Oracle SOA Composer to View or Edit a Dictionary at Runtime

Description of Figure 1-2 follows
Description of "Figure 1-2 Using Oracle SOA Composer to View or Edit a Dictionary at Runtime"

For more information, see Chapter 12, "Using Oracle SOA Composer with Oracle Business Rules".

1.3 Oracle Business Rules Engine Architecture

A rule-based system using the Rete algorithm is the foundation of Oracle Business Rules. A rule-based system consists of the following:

In Oracle Business Rules the rule-based system is a data-driven forward chaining system. The facts determine which rules can fire. When a rule fires that matches a set of facts, the rule may add facts. These facts are again run against the rules. This process repeats until a conclusion is reached or the cycle is stopped or reset. Thus, in a forward-chaining rule-based system, facts cause rules to fire and firing rules can create more facts, which in turn can fire more rules. This process is called an inference cycle.

1.3.1 Declarative Rules

With Oracle Business Rules you can use declarative rules, where you create rules that make declarations based on facts rather than coding. For an example of declarative rules,

IF a Customer is a Premium customer, offer them 10% discount
IF a Customer is a Gold customer, offer them 5% discount

In declarative rules:

  • Statements are declared without any control flow

  • Control flow is determined by the Rules Engine

  • Rules are easier to maintain than procedural code

  • Rules relate well to business user work methods

When a rule adds facts and these facts run against the rules, this process is called an inference cycle. An inference cycle uses the initial facts to cause rules to fire and firing rules can create more facts, which in turn can fire more rules. For example, using the initial facts, Rules Engine runs and adds an additional fact, and an additional rule tests for conditions on this fact creating an inference cycle:

IF a Customer is a Premium customer, offer them 10% discount
IF a Customer is a Gold customer, offer them 5% discount
IF a Customer spends > 1000, make them Premium customer

The inference cycle that Oracle Business Rules provides enables powerful and modular declarative assertions.

1.3.2 The RETE Algorithm

The Rete algorithm was first developed by artificial intelligence researchers in the late 1970s and is at the core of Rules Engines from several vendors. Oracle Business Rules uses the Rete algorithm to optimize the pattern matching process for rules and facts. The Rete algorithm stores partially matched results in a single network of nodes in working memory.

By using the Rete algorithm, the Rules Engine avoids unnecessary rechecking when facts are deleted, added, or modified. To process facts and rules, the Rete algorithm creates and uses an input node for each fact definition and an output node for each rule.

Fact references flow from input to output nodes. In between input and output nodes are test nodes and join nodes. A test occurs when a rule condition has a Boolean expression. A join occurs when a rule condition ANDs two facts. A rule is activated when its output node contains fact references. Fact references are cached throughout the network to speed up recomputing activated rules. When a fact is added, removed, or changed, the Rete network updates the caches and the rule activations; this requires only an incremental amount of work.

The Rete algorithm provides the following benefits:

  • Independence from rule order: Rules can be added and removed without affecting other rules.

  • Optimization across multiple rules: Rules with common conditions share nodes in the Rete network.

  • High performance inference cycles: Each rule firing typically changes just a few facts and the cost of updating the Rete network is proportional to the number of changed facts, not to the total number of facts or rules.

1.3.3 What Is Working Memory?

Oracle Business Rules uses working memory to contain facts (facts do not exist outside of working memory). A RuleSession contains the Oracle Business Rules working memory.

1.3.4 Rule Firing and Rule Sessions

A Rule Session consists of rules, facts and an agenda. An assert or retract adds or removes fact instances from working memory.

When facts in working memory are changed:

  • Conditions for rules are evaluated

  • Matching rules are added to the agenda (Activated)

  • Rules which no longer match are removed from agenda

  • Rules Engine runs and executes actions (fires), for activated rules

Figure 1-3 shows these parts of Oracle Business Rules runtime.

Figure 1-3 Rules in Rule Session with Working Memory and Facts

Description of Figure 1-3 follows
Description of "Figure 1-3 Rules in Rule Session with Working Memory and Facts"

A rule action may assert, modify, or retract facts and cause activations to be added or removed from the agenda. There is a possible loop if a rule's action causes it to fire again. Rules are fired sequentially, but in no pre-defined order. The rule session includes a ruleset stack. Activated rules are fired as follows:

  • Rules within top-of-the-stack ruleset are fired

  • Within a ruleset, firing is ordered by user-defined priority

  • Within the same priority, the most recently activated rule is fired first

Only rules within rulesets on the stack are fired, but all rules in a rule session are matched and, if matched, activated.

Go to previous page
Previous		 Go to next page
Next
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Feedback page
Contact Us