1 Introduction to Rules Manager

1.1 What is a Rule?

A rule is a directive to guide or influence a process behavior. A rule consists of a conditional expression that you specify using the attributes you define in a corresponding event structure. When an instance of the event structure satisfies a rule condition, a rule action takes place. When the rule action executes, event management policies define how to handle an event instance. This, in a nutshell, describes how a typical rules-based system works.

Typically, rules follow Event-Condition-Action (ECA) rule semantics where an event happens and if a rule condition evaluates to true for this event, then it performs some prescribed action. The ECA components are defined as:

• Event -- the state information for the process

• Condition -- the Boolean condition that evaluates to true or false for the event

• Action -- the action to be carried out if the rule condition evaluates to true for the event

The standard notation for ECA rules is:

ON    <event structure>
IF    <condition> 
THEN  <action> 

where, the ON clause identifies the event structure for which the rule is defined, the IF clause specifies the rule condition, and the THEN clause specifies the rule action.

An example of a rule is the following: If a customer chose to fly Abcair Airlines to Orlando and if his stay in Orlando is more than 7 days, then offer an Acar rental car promotion to him. Using the ECA notation, this rule is:

ON
      AddFlight  (Custid, Airline, FromCity, ToCity, Depart, Return)
IF
      Airline = 'Abcair' and ToCity = 'Orlando' and Return-Depart >= 7
THEN
      OfferPromotion  (CustId, 'RenralCar', 'Acar')

where:

The ON clause identifies the event structure for this rule.
The IF clause defines the rule condition using variables in the event structure.
The THEN clause defines the commands that represent the action for this rule.

Rules Manager

Rules Manager, a feature of Oracle Database, offers interfaces to define, manage, and enforce complex rules in the database. The five elements of a Rules Manager application are:

1. An event structure you define as an object type with attributes that describe specific features of an event.

2. A rule consists of a condition and action preferences.

   • A rule condition you express using the attributes defined in the event structure.

   • Rule action preferences to determine the exact action for each rule and to specify the details for the action.

3. A rule class that is a database table that stores and groups the rules defined for an event structure.

4. An action callback PL/SQL procedure that implements the rule actions for the rule class. The implementation can rely on some attributes of the event structure and the action preference associated with the rules.

5. A results view that configures a rule class for external rule action execution.

Rules Manager supports XML-based condition language, SQL commands for rule specification, automated tracking of events, declarative management of event policies, rule actions, and an application programmatic interface (API).

Rules Manager supports primitive (simple) and composite events. Rules Manager is appropriate for any rules-based applications requiring composite events. Rules Manager supports complex rule conditions involving negation, set semantics, Any n construct, sequencing, and collections. Rules Manager supports incremental evaluation of rules involving composite events. You can specify complex rule conditions using XML tags within conditional expressions in the SQL WHERE clause format. You can enforce rule class event management policies, such as consumption, conflict resolution, and duration, for each rule application. Figure 1-1 shows the process steps for creating and implementing a Rules Manager rules application. Section 2.3 describes these steps in more detail.

For more information about creating, using, and maintaining Rules Manager applications, see Part I, "Rules Manager", Chapter 2 through Chapter 10.

1.2 Developing Rules Applications

Developing a rules application using Rules Manager requires a somewhat different approach toward application development. Typically, you would scan through a new API and other reference material, then create some sample scripts based on the examples to get a feel for how the feature works. Next, you might begin to apply these methods learned to your own application. However, this is where you might get bogged down in the detail of the implementation because the approach to Rules Manager application development uses a somewhat different focus. The focus is on the decision points that already exist in your application and that is all. You need not focus on all the supporting parts of your application that do not necessarily pertain to these decision points.

As an application developer you must ask yourself the following questions:

• Where are the decision points in my application?

• What are the decisions that each decision point is making?

• How is each decision being made?

• Once a decision is made how does it execute in the application?

Note that each decision point may use one or more rules that may involve one or more events happening in some sequence.

Once you determine the decision points in your application, you integrate Rules Manager into your application by using the standard notation for ECA rules to model each decision point as described in Section 1.1. It is best to keep your approach as simple as possible.

For example, using Rules Manager for the simplest case, if your application has a decision point that uses one or more rules each relying on a single instance of an event structure that happens in the application, you would define a primitive event structure to model this event activity. In a complex event scenario, if your application has another decision point that uses one or more rules, each relying on multiple instances of the same or different event structures that happen in some sequence, define a composite event structure consisting of separately defined primitive event structures for each individual event that happens. The composite event structure couples these primitive events together to model the composite event activity. Next, create the rule class. Creating the rule class implicitly creates the rule class table containing an expression column to store the rule conditions and one or more action preferences columns you use to determine the appropriate action when the rule evaluates to true. In addition to the rule class table, the previous step also creates an action callback procedure that you can modify to execute the action for the matching rules.

This unique approach lets you quickly integrate Rules Manager into existing applications as easily as if it were a new application because you only need to focus on the decision points contained in your application or in your data analysis for a new application. Remember Rules Manager stores, processes, and matches rules with instances of either incoming single events or groups of events to resolve the rules concentrated around each decision point. The object then becomes how best to model these decision points using Rules Manager. This is explained in Part I, "Rules Manager".