G Implementing Various Forms of Rule Actions With the Action Callback Procedure

The action callback procedure configured for a rule class acts as a common entry point for executing the actions for all the rules in the rule class. This procedure is called once for each rule matching an event (primitive or composite). At the time of execution, this procedure has access to the events that matched the rule and the complete list of action preferences associated with the matched rule. The user implementing the action callback procedure can rely on this information to determine the appropriate action for each rule. Rules Manager provides maximum flexibility by not restricting the types of action preferences used for a rule class. In the simplest case, the action preferences associated with a rule can be one or more scalar values that are used as arguments to a common procedure (OfferPromotion from the example in Section 2.4) that executes the appropriate action for each rule. Table G-1 represents one such rule class that is created with three types of action preference - PromoType, OfferedBy, and Discount.

If a single PL/SQL procedure in the database is implemented to offer all types of discounts by accepting appropriate arguments, the action callback procedure for the preceding rule class can make use of this procedure to execute appropriate actions, as follows:

CREATE or REPLACE PROCEDURE PromoAction (rlm$event  AddFlight,
                                         rlm$rule   TravelPromotion%ROWTYPE) is
BEGIN
   OfferPromotion(rlm$event.CustId,
                  rlm$rule.PromoType,
                  rlm$rule.OfferedBy,
                  rlm$rule.Discount);
END;

However, if the action for all the rules is not implemented with a single procedure but with a handful of procedures, the action callback procedure can be implemented to choose the appropriate procedure using one of the action preference values. For example, if the procedures used to offer hotel and rental car promotions are different, the preceding action callback procedure can be implemented as follows:

CREATE or REPLACE PROCEDURE PromoAction (rlm$event AddFlight,
                                         rlm$rule TravelPromotion%ROWTYPE) is
BEGIN
   CASE rlm$rule.PromoType
     WHEN 'RentalCar' then
       OfferRentalCarPromotion(rlm$event.CustId,
                               rlm$rule.OfferedBy,
                               rlm$rule.Discount);
     WHEN 'Hotel' then
       OfferHotelPromotion (rlm$event.CustId,
                            rlm$rule.OfferedBy,
                            rlm$rule.Discount);
     ELSE
       OfferPromotion(rlm$event.CustId,
                      rlm$rule.PromoType,
                      rlm$rule.OfferedBy,
                      rlm$rule.Discount);
   END CASE; 
END;

For complex rule applications requiring different actions for each rule, the PL/SQL commands that model the actions can be stored as the rule action preferences. For this purpose, the preceding rule class table can be configured to store the anonymous PL/SQL code blocks as the rule action preferences as described in Table G-2.

For the preceding rule class configuration, the action callback procedure can be implemented to execute the anonymous PL/SQL code blocks using the EXECUTE IMMEDIATE command shown as follows.

CREATE or REPLACE PROCEDURE PromoAction (rlm$event AddFlight,
                                         rlm$rule  TravelPromotion%ROWTYPE) is
BEGIN
  EXECUTE IMMEDIATE rlm$rule.ActionCommands USING rlm$event.CustId;
END;
/

A rules application in the database can use a combination of the previous three procedures to model complex action execution logic. For this purpose, the rule class can be created with as high as 997 action preference columns, each with any valid SQL data type (including RAW, CLOB, and XML).