Application developers use rules to integrate business processes and automatically respond to events created by workflows. However, these rules are often embedded in code modules or a special purpose memory-based rules repository making maintenance of them challenging. Rules that are managed in Oracle Database keep pace with changing business conditions and are always up-to-date; rules are easily changed with SQL and are not hard-coded in your application or loaded into a memory-based rules repository. Rules can be evaluated efficiently with the complete business context stored in your Oracle Database as well as data provided by your application. Event response is flexible; rules can trigger actions in Oracle Database or in your application, or both.
Rules Manager application programming interface (APIs) define, manage, and enforce complex rules in the Oracle Database with better scalability and operational characteristics than a special purpose rules product. Additionally, Rules Manager as a database feature can be used in multiuser and multisession environments.
Rules Manager can model any event-condition-action (ECA)-based system ranging from the simplest single event-single rule system to rule-based systems that involve millions of events and millions of rules. Applications for Rules Manager include information distribution, task assignment, event-based computing, radio frequency ID (RFID), supply chain, enterprise application integration (EAI), business asset management (BAM), and business process management (BPM).
Rules Manager processes an event or a group of events for a set of rules that are based on ECA semantics. An event can be an individual entity (simple or primitive event) or a group of events (composite event). Rules Manager models complex event scenarios using SQL and XML based rule condition language. An event can be incoming application data or data stored as rows in one or more relational tables. Rules Manager supports the Oracle-supplied XMLType data type, which allows it to process XML events.
When an event happens, and if a rule condition evaluates to true for that event, then a prescribed rule action is performed, which can be either executed immediately or obtained as a list of rules that evaluate to true for the event for later execution by the application or some other component and that can be queried.
While processing a set of rules for an event, Rules Manager enforces various event management policies, including conflict resolution among composite events or groups of matching rules, ordering of events, lifetime of an event, and sharing events across multiple rule executions.
The concept of rules is briefly introduced in Section 1.1 followed by an overview of Rules Manager features. Section 1.2 describes some general concepts about developing rules applications using Rules Manager.
If you have an existing Expression Filter application and want to upgrade it to a Rules Manager application, first see Section D.1, which describes an implementation of Expression Filter and Rules Manager. Next, see Section D.2, which describes the process of upgrading an Expression Filter application to a Rules Manager application.
A rule is a directive to guide or influence a process behavior. A rule consists of a conditional expression that is specified using the attributes defined in a corresponding event structure and a rule action that takes place when the rule condition is satisfied by an instance of the event structure. Event management policies define how an event instance is handled once the rule action is executed. 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 some prescribed action is performed. 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')
An event structure that is defined as an object type with attributes that describe specific features of an event.
A rule consisting of a condition and action preferences.
A rule condition is expressed using the attributes defined in the event structure.
Rule action preferences determine the exact action for each rule and specify the details for the action.
A rule class that is a database table that stores and groups the rules defined for an event structure.
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.
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. Complex rule conditions are specified using XML tags within conditional expressions in the SQL
WHERE clause format. Rule class event management policies such as consumption, conflict resolution, and duration can be enforced 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.
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 is it executed in the application?
Once you determine the decision points in your application, you integrate the 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 that are used 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".