8.1 Introduction to Oracle Business Rules and Rule Author

8.1.1 What Are Business Rules?

Business rules are statements that describe business policies. For example, a car rental company might use the following underage driver business rule:

If the age of a driver is younger than 21, then decline to rent.

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

If a frequent flyer account has total miles for the year that are greater than 100,000, then status is Gold.

A company that sells electronics might use a business rule such as:

If a customer has Platinum status, or an order is less than $1,000, then approve the order without manual intervention

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

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

public boolean checkUnderAgeRule (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 revises its policy to "Under 19", so that all drivers under 19 cannot rent a car. 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 rules application supports easily changing business policies.

8.1.2 Oracle Business Rules Terminology

To use the BPEL Decision Service and Oracle Business Rules, you should first understand terminology related to business rules, including the following:

• Facts: data or objects on which expressions are to be evaluated. For example, facts can represent a Loan Application, a Customer Credit History, or Income Data. In this chapter, the rules operate over facts containing customer data that describes the status of a customer: Gold status, Silver status, or Platinum status, based on the amount of business for the customer in a given year.

• Rules: expressions on the facts:

  If (<condition involving Facts>) then <actions>
  

  For example,

  If customer status is Gold then discount is 20%
  

• Rule Sets: groups of rules that are generally executed as one unit.

• Actions: describe an activity that is performed if a rule matches in the current knowledge base, or set of facts.

• Data Model: In Oracle Business Rules, facts are data objects that are asserted in the Rules Engine. Rules, such as an underage driver rule, constrain and support facts. In Oracle Business Rules, a data model specifies the types of facts or business objects that you can use to create business rules. For example, for a car rental company that needs to create a rule to match the age of a driver, the driver information represents the facts used in the rule. Using Rule Author, you can define a data model and then use the objects in the data model when you create rules.

• Dictionary: a collection of rule sets and their associated data model that is stored in a repository with a name and a version, or multiple versions. Rule Author stores rules in a dictionary that is saved to a repository. You can create as many dictionaries as necessary, and each dictionary can have multiple versions. A BPEL Decision Service accesses a dictionary and uses the rules in the dictionary when it invokes a Decide activity.

8.1.3 Using Existing Rules and Facts

To use existing rule definitions and facts (those not created with Rule Author and stored in a repository as described in this chapter) it is helpful to understand how the Decision Service works with rules and facts.

BPEL and a Decision Service

The Decision Service enables you to model common operations that might be performed against a set of rules and XML facts that have been written to the Oracle Rules Repository. The Decision Service simplifies the design experience by enabling you to wrap rule sets as a web service that can be invoked from a business process. The Decision Service does not provide a user interface for modifying the rules (to modify the rules, use Rule Author).

When you develop other types of rules applications, you can pass information to and from the rules engine using either Java objects or XML documents.

You can leverage Java facts with BPEL by:

1. Building Java interfaces and using the WebServiceAssembler to expose them to BPEL

2. Using RuleAuthor to point to a local JDeveloper classes folder (Java facts will be part of a JDeveloper project).

Using Rules from BPEL:

To use Rules from BPEL, you:

1. Create a Rules Repository with JDeveloper or the Rule Author and modeling the facts using XML.

2. Create a Decision Service Partner Link in BPEL that references the Rules Repository.

   
   

   Note: If the fact model is edited in the Rule Author, the service definition is affected and the BPEL partner link must be re synchronized. See Section 7.8.1, "How to Use the Decision Service Wizard to Create a Decision Service Partner Link"

   
   

Integrating applications with Rules

You can integrate applications with the Rules engine using the Java API to the Rules Engine (RulesSession):

1. Build the inference engine using Java Rules, Rules RL and a runtime RulesSession.

2. Use JDeveloper to expose the inference engine as a web service, and have BPEL consume this service.

The Oracle Rules Engine implementation is itself 100% Java, and at the lowest level always operates on Java facts. To work with XML, the Rule Author uses JAXB to compile XSD into Java objects. At runtime, all Rules Engine facts are Java facts. As a developer, you can choose to:

• Model facts with XML, and have them compiled into Java seamlessly, behind the scenes, or

• Model facts using Java and expose them as a web service, where the Java-to-XML marshaling is managed by the web services stack.

In Figure 8-1, XMLFacts are bound to JavaFacts using JAXB. It is always JavaFacts that execute in the underlying RulesSession. You can interface to the RulesSession through the DecisionService (by the XMLFact route), or, if integration at a lower level is necessary, then you can wrap the RulesSession/JavaFacts with a JAX-RPC WebService). The preferred method is to model using XMLFacts and use the DecisionService.