D Converting Rules Applications

This appendix describes differences between Expression Filter and Rules Manager and how to convert an Expression Filter rules application to a Rules Manager rules application.

Differences Between Expression Filter and Rules Manager

Before converting your Expression Filter application to a Rules Manager application, you should understand the differences between each feature and some of the reasons why you should use Rules Manager. If you are ready to convert your Expression Filter application to a Rules Manager application, see AppendixD.

Expression Filter is best used to model simple rules-based systems. A simple rules-based system consists of a primitive event that may have a small-to-very large class of rules (hundreds to millions of rules).

Rules Manager is best used for modeling a wide range of rules-based systems from the simplest to the most complex. A simple rules-based system is again a primitive event having a small-to-very large class of rules (hundreds to millions of rules), while a very complex rules-based system may involve many sets of composite events (each consisting of two or more primitive events) each with a very large class of rules (millions of rules) that can represent very complex rule conditions and that enforce event management policies that require reusing primitive events and handling duplicate composite events, and so forth.

Table D-1 shows step-by-step differences between implementing and using the Expression Filter and Rules Manager features that uses a primitive (simple) event.

Table D-1 Implementation Differences Between Expression Filter and Rules Manager for Rules Applications That Use a Primitive (Simple) Event

Expression Filter	Rules Manager
1. Create the event structure and its set of attributes or use an existing object type definition.	1. Create the event structure and its set of attributes or use an existing object type definition.
2. Create a table to store the rule conditions and associated information.	2. Create the rule class for the event structure. o This implicitly creates the skeleton for a callback procedure to perform the action. o This implicitly creates a rules class table to store the corresponding rule definitions and rule action preferences. o This defines the results view, if specified in the rule class definition, to temporarily store the results of processing rules.
3. Assign the event structure that is captured as an Expression Filter attribute set to the condition column in the table.	Note: Rules Manager implicitly creates the Expression data type column (`rlm$rulecond`) in the generated rule class table.
4. Configure the default index parameters with the attribute set.	Note: Rules Manager implicitly creates the default index parameters with the attribute set.
5. Create an Expression Filter index on the Expression column in the user table.	Note: Rules Manager implicitly creates the Expression Filter indexes on the necessary Expression columns in the rule class table.
6. Implement a procedure to carry the action for the rules defined in the user table.	3. Replace the system generated callback procedure with the user implementation to perform the appropriate rule action for each matching rule.
7. Insert rule conditional expressions and accompanying information to the user table.	4. Insert rules into the rule class table.
8. Create the events table to store the past events if the rules in the user table rely on composite events.	Note: Rules Manager implicitly creates an events table to keep track of the past events until they are no longer required.
9. Apply the SQL `EVALUATE` operator to compare expressions stored in the Expressions column to the rows stored in the event table	5. Process the rules for an event. Note: Rules Manager automatically applies the SQL `EVALUATE` operator to compare rule conditions stored in the `rlm$rulecond` column of the rules class table to an event instance.
10. Execute the action procedure for one or more rows returned by the previous query.	Note: With the `PROCESS_RULES` call, Rules Manager implicitly executes the action for the matching rules by invoking the preconfigured action callback procedure.
11. Delete the events from the events table if the application calls for the consumption of the events immediately after executing the rule actions.	Note: Rules Manager can be configured to automatically consume the events by using the appropriate event management policies.

From Table D-1, Rules Manager automatically performs a number of operations (through subsumption of Expression Filter functionality) that normally had to be done manually using Expression Filter. Because many Expression Filter features are implicitly used by Rules Manager, Rules Manager is easier to use and is the recommended choice, especially for complex rules applications involving composite events.

If you have already modeled and implemented a rules-based system application that uses Expression Filter and you want to convert your application to a Rules Manager application, see AppendixD for a description of this process.

Converting an Expression Filter Application to a Rules Manager Application

Expression Filter is a component of Rules Manager. Rules Manager is the preferred feature to use for developing rules applications in release Oracle Database 10g Release 2 (10.2). Expression Filter applications developed in release Oracle Database 10g Release 1 (10.1) can be converted to Rules Manager applications once you understand the main differences between these two features relative to the tables storing the expressions or rules. These differences from an implementation perspective are the name of and structure of the user table containing the expression column for Expression Filter applications versus the name of and structure of the rules class table containing the rule condition column and action preference columns for a Rules Manager application.

The process of converting an Expression Filter application to a Rules Manager application is to complete Steps 1 through 3 as described in the Rules Manager column in Table D-1. Then, instead of populating the rules class table using a SQL INSERT statement as shown in Step 4, use the following SQL statement syntax to copy the rows from the Expression Filter user table to the Rules Manager rules class table:

SQL INSERT INTO <rules-manger-rules-class-table> (field1, field3, field4, field2)
    SELECT field1, field2, field3, field4 from <expression-filter-user-table>;

This SQL INSERT statement syntax populates the Rules Manager rules class table with the expression conditions from the condition Expression column in the Expression Filter user table along with the desired action preference columns. For example, the following SQL statements would perform this operation after executing SQL DESCRIBE statements to view the structure of each of these tables to determine which columns you want to copy and in what order to copy them:

--Assume the Expression Filter user table has the following structure:
SQL> DESCRIBE user_exprfiltertable;
 Name                                      Null?    Type
 ----------------------------------------- -------- ---------------------------
 ID                                                 VARCHAR2(100)
 CONDITION                                          VARCHAR2(200)
 POSTALCODE                                         VARCHAR2(10)
 PHONE                                              VARCHAR2(10)

--Assume the Rules Manager rules class table has the following structure:
SQL> DESCRIBE rm_rules_classtable;
Name            NULL?      TYPE
---------       -----      -------------
RLM$RULEID                 VARCHAR2(100)
PostalCode                 VARCHAR2(10)
Phone                      VARCHAR2(10)
RLM$RULECOND               VARCHAR2(4000)
RLM$RULEDESC               VARCHAR2(1000)

--Insert statement to use that copies rows from the Expression Filter user table
--to the Rules Manager rules class table:
INSERT INTO rm_rules_classtable (rlm$ruleid, PostalCode, Phone, rml$rulecond)
  SELECT ID, PostalCode, Phone, Condition FROM user_exprfiltertable;

Once the rules class table is populated with the rows of the Expression Filter user table, proceed to complete Steps 5 through 7 as described in the Rules Manager column in Table D-1. Upon completion of these steps, you will have a Rules Manager rules application.

Note that to adapt Rules Manager to one of your existing applications, you can use this same SQL INSERT INTO syntax to populate the rules class table with data residing within other tables of your application, but only after Rules Manager initially creates this table for you. This is the best way to populate the rules class table with the desired values for these same columns that are defined as part of the rule class creation process described in Step 2 in the Rules Manager column in Table D-1. Now you might just be beginning to realize that adapting your existing application to use Rules Manager is a straight-forward process and it is not too difficult to quickly produce results once you understand how to develop rules applications using Rules Manager. The conceptual approach of this development process is described in more detail in Chapter1.