4 Rule Conditions

Support for Incremental Evaluation of Rules

To enable incremental evaluation of rules and support complex rule applications, the conditional expressions in the SQL WHERE clause are extended with meaningful XML tags. The XML tags are provided to identify different parts of a conditional expression and add special semantics to these expressions.For example, the conditional expression (Flt.Airline = 'Abcair' and Flt.ToCity = 'Orlando' and Flt.CustId = Car.CustId and Car.CarType = 'Luxury') in the travel services rule has three parts, as follows:

• Predicates defined on the primitive event AddFlight (Flt.Airline = 'Abcair' and Flt.ToCity = 'Orlando')

• A predicate defined on the primitive event AddRentalCar (Car.CarType = 'Luxury')

• A join predicate between the two primitive events (Flt.CustId = Car.CustId)

Rules Manager provides XML tags to identify various parts of a complex conditional expression and support additional semantics. For example, the previous rule condition can be represented using XML tags as follows^Foot 1 :

<condition>
  <and join="Flt.CustId = Car.CustId">
    <object name="Flt"> Airline='Abcair' and ToCity='Orlando' </object>
    <object name="Car"> CarType = 'Luxury' </object>
  </and>
</condition>

In this representation, the object elements capture the predicates specified for individual primitive events and one join attribute of the <and> element captures the join predicate behavior between two primitive events. The rule condition in this format can be inserted into the rlm$rulecond column of the corresponding rule class table. XML tags are provided to support more complex rule constructs. These tags are summarized in Figure 4-1 and Table 4-1 and are described in Chapter4 through Chapter4.

Figure 4-1 describes a hierarchical view of the supported XML tag elements and their attributes for the rule condition XML schema definition that is described in detail in Appendix F in the Rule Condition section. Table 4-1 shows a relational view of the same supported XML tag extensions showing the XPath and some notes about the elements and attributes.

Figure 4-1 Hierarchical View of the XML Tag Extensions

Description of "Figure 4-1 Hierarchical View of the XML Tag Extensions"

Rule Conditions with Sequencing

The rules defined for a composite event (consisting of two or more primitive events) may specify a condition on the order in which the primitive events should occur. This is called sequencing and it can be partial on a subset of primitive events, or it can be complete based on all the primitive events. Sequencing in rule applications is supported using the implicit timestamp attribute (rlm$crtTime) that is included in each primitive event participating in a composite event.

The event creation times in the primitive events are used to enforce and detect sequencing in rule applications. For example, the rule considered in the travel services application can specify an additional predicate to offer the promotion only if the AddRentalCar event is generated after the AddFlight event. The rule condition can be extended to include this sequencing predicate, as follows:

<condition>
  <and join="Flt.CustId = Car.CustId" sequence="yes">
    <object name="Flt"> Airline='Abcair' and ToCity='Orlando' </object>
    <object name="Car"> CarType = 'Luxury' </object>
  </and>
</condition>

The sequence attribute in the preceding example ensures that the rule condition evaluates to true only if the matching primitive events occur in the order in which they are specified within the <and> element. The sequence attribute can be replaced with a join predicate on the corresponding event creation times, shown as follows:

<condition>
  <and join="Flt.CustId = Car.CustId and Car.rlm$CrtTime >= Flt.rlm$CrtTime">
    <object name="Flt"> Airline='Abcair' and ToCity='Orlando' </object>
    <object name="Car""> CarType = 'Luxury' </object>
  </and>
</condition>

Sequencing can be used to detect partial ordering among primitive events (for example, using a join predicate on only two primitive events when there are three of them in the composite event). The rlm$CrtTime attribute in the primitive event type can also be used to apply additional time constrains in the rule conditions. For example, the travel services rule may be valid only when the car reservations is made within 24 hours of making the flight reservation. This is indicated in the bolded text of the following example where the value 1 means one day. See Oracle Database Application Developer's Guide - Fundamentals for more information about performing date/timestamp arithmetic.

<condition>
  <and join="Flt.CustId = Car.CustId and
                                 Flt.rlm$CrtTime >= (Car.rlm$CrtTime - 1)"
                                 sequence="Yes">
    <object name="Flt"> Airline='Abcair' and ToCity='Orlando' </object>
    <object name="Car"> CarType = 'Luxury' </object>
  </and>
</condition>

Optionally, the call to the DBMS_RLMGR.PROCESS_RULES procedure may pass an event with a specific event creation time. Within a primitive event, the rlm$CrtTime attribute is treated as any other attribute in the event structure. However, when a value is not specified for this attribute, it is assigned a default value of SYSTIMESTAMP (in the database). If an application is sensitive to the difference between the times at which the events are detected (in the application layer) and the times at which they are added to Rules Manager, it may choose to set the values for event creation times and add fully specified events to the rules class.

Rule Conditions with Negation

Rules with negation in their conditions are typically used to raise exceptions in business processes. For example, a rule using negation could be "If an order is placed by a Gold customer and the items are not shipped within 24 hours of the order placement, alert the representative". In this case, the rule is defined for a composite event consisting of two primitive events PlaceOrder and ShipOrder and the type created for the composite event structure is shown as follows:

CREATE or REPLACE TYPE OrderTrack AS OBJECT (
                order PlaceOrder, -- primitive event type --
                ship ShipOrder); -- primitive event type --

For a composite event, a rule defined with negation evaluates to true when one of the primitive events does not happen within a time delay of the other. So, negation always accompanies a time delay that is relative to the other primitive event or events in the composite event. For example, the rule condition for the order tracking rule can be captured as follows, where the bolded text in the following example, "sysdate +1", means by the end of the next day because the SQL datetime function SYSDATE returns the current date and time of the operating system on which the database resides (taking into account the time zone of the database server's operating system that was in effect when the database was started).

<condition>
  <and equal="order.orderId, ship.orderId">
    <object name="order"> Type = 'Gold' </object>
    <not by="sysdate+1"> 
      <object name="ship"/> -- empty elem: no conditions on the primitive event --
    </not>
  </and>
</condition>

The <not> XML element in the rule condition has the following semantics:

• There can be only one <not> element in a rule condition.

• The <not> element can only appear within an <and> element (as a conjunction to other primitive events) and it should be the last element within the <and> element.

• The <not> element is activated only when all the other primitive events in the composite events are detected.

• The <not> element can contain only one <object> element that represents a primitive event.The <notany> element can be used in place of the <not> element to support a notion of disjunction within the negation rule.

• At the time of activation, the by attribute of the <not> element is executed to compute the deadline for the primitive events in the <not> element. The value for the by attribute can be expressed using the (database) SYSTIMESTAMP (to be set to the time of activation) or any date attribute in the other primitive events (including the event creation time attributes discussed in Chapter4), or both. The SQL datetime function SYSTIMESTAMP returns the system date including fractional seconds and time zone of the system on which the database resides. So, the rule condition in the preceding example can also be expressed as follows:

  <condition>
    <and equal="order.orderId, ship.orderId">
      <object name="order"> Type = 'Gold' </object>
      <not by="order.rlm$CrtTime+1">
        <object name="ship"/>
      </not>
    </and>
  </condition>
  
  

  Another variant of the preceding rule is one that uses a user-supplied date in the deadline computation. For example, a ShipBy attribute in the PlaceOrder event can hold the time by which the shipment is expected and the deadline can be computed using this attribute, such as shown here:

  <condition>
    <and equal="order.orderId, ship.orderId">
      <object name="order"> Type = 'Gold' </object>
      <not by="order.ShipBy-1">
        <object name="ship"/>
      </not>
    </and>
  </condition>
  
  

Rules with negation involving a deadline other than SYSTIMESTAMP are not allowed in a rule class with the AUTOCOMMIT property turned off (see Chapter3). This also includes the rule classes configured for DMLEVENTS (see Chapter3).

Rules involving negation constructs can be used to raise alerts (in corresponding rule actions) when a set of primitive events are generated out of order. In applications such as Workflow, rules are often used to enforce sequencing among various business events. The action of such rules is to raise an exception (alert an agent) when the events are detected out of order. A <not> element without a hard deadline (no by attribute) can be used to define such rules.

Consider a composite event with three primitive events: PlaceOrder, PaymentReceived, and ShipOrder. A rule can be used to alert an agent (action) if the ShipOrder event is generated before the PaymentReceived event is detected. (Note that there are alternate ways to model this application in a Workflow system, but this approach is used to explain the negation concept). For this example, the composite event structure and the rule condition are represented as follows:

CREATE or REPLACE TYPE OrderTrack AS OBJECT (
                  order PlaceOrder, -- primitive event type –-
                  pay PaymentReceived, -- primitive event type --
                  ship ShipOrder); -- primitive event type --

<condition>
  <and equal="order.OrderId, pay.OrderId, ship.OrderId">
    <object name="order"/> -- no conditions on the primitive events --
    <object name="ship"/>
    <not>
      <object name="pay"/>
    </not>
  </and>
</condition>

The previous example uses a <not> element with no deadline specification (by attribute) and thus this value defaults to SYSTIMESTAMP (the time at which all other primitive events in the rule condition are detected). The sequence="yes" (Chapter4) property, such as shown in the following example, can be used to ensure ordering among the detected events.

<condition>
  <and equal="order.OrderId, pay.OrderId, ship.OrderId" sequence="yes">
    <object name="order"/> -- no conditions on the primitive events --
    <object name="ship"/>
    <not>
      <object name="pay"/>
    </not>
  </and>
</condition>

In the previous rule condition, the deadline for the PaymentReceived event is determined by the occurrence of the ShipOrder event, which follows the corresponding PlaceOrder event. In effect, the action associated with the preceding rule condition will be executed if the ShipOrder event is detected before the PaymentReceived event for a particular order.

The negation construct can often be used to detect the non-occurrence of two or more primitive events. For example, a rule such as "If an order is placed by a Gold customer and the items are not shipped within 24 hours of the order placement or if the order is not cancelled, alert the representative" uses negation on the two events, ShipOrder and CancelOrder. Such rule conditions can be expressed using a <notany> element in the place of the <not> element as shown in the following example:

<condition>
  <and equal="order.orderId, ship.orderId, cancel.orderId">
    <object name="order"> Type = 'Gold' </object>
    <notany count=1 by="order.rlm$CrtTime+1">
       <object name="ship"/>
       <object name="cancel"/> -- assuming a CancelOrder event --
    </notany>
  </and>
</condition>

The primitive events appearing within the <not> or <notany> element should not be referenced in the join attribute specification of the <and> element. However, they (primitive events) can be used within the EQUAL property specifications. If there is a need to specify a join condition (other than those already captured by the EQUAL property specifications), the join attribute for the <not> element can be used. The conditional expression specified for this join attribute can reference all the primitive events that appear in the rule condition, including those appearing within the <not> element, such as shown in the following example:

<condition>
  <and equal="order.orderId, ship.orderId">
    <object name="order"> Type = 'Gold' </object>
    <not by="order.rlm$CrtTime+1"
        join="order.Address_zipcode = ship.Address_zipcode">
      <object name="ship"/>
    </not>
  </and>
</condition>

The rule condition with a negation is considered true only if the join condition in the <and> element evaluates to true and the join condition in the not condition evaluates to false (or there is no event that matches this criteria within specified deadline).

Rule Conditions with Set Semantics

In some applications, the primitive events that constitute a composite event can be the same structure. For example, AddItem could be a primitive event that is generated when a customer adds an item to his shopping cart. Rules can be defined to monitor multiple items added to the shopping cart and suggest new items based on the past customer experiences (association rules generated by a data mining tools).

Consider an electronics Web store that sells accessories for camcorders. A typical rule in their application could be "If a customer adds a camcorder lens worth more than $100, a lens filter, and a IR light to the shopping cart, suggest a tripod to him". This rule consists of three simple conditions to be checked on every AddItem event generated in the system, such as shown in the following example:

Accessory = 'Lens' and Price > 100
Accessory = 'Lens Filter'
Accessory = 'IR Light'

To support the application described previously, the composite event structure can be modeled as an object type with multiple embedded types of the same primitive event type (AddItem) as shown in the example that follows. If required, the same composite event structure may also include other primitive event types.

CREATE or REPLACE TYPE AddItem AS OBJECT (
                  Accessory VARCHAR(30),
                  Make VARCHAR(20),
                  Price NUMBER);
CREATE or REPLACE TYPE CrossSellEvent AS OBJECT (
                  Item1 AddItem,
                  Item2 AddItem,
                  Item3 AddItem,
                  Item4 AddItem,
                  Item5 AddItem);

The preceding composite event is created to accommodate rules that are monitoring at most five primitive events in the shopping cart. (Note that the shopping cart may still contain more than 5 items.) In this rule application, the events can be configured for SESSION duration (see Chapter3) such that only the primitive events generated within a user session are considered for rule matches. Using the composite event rule condition syntax, the preceding condition can be expressed as follows:

<condition>
  <and>
    <object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
    <object name="Item2"> Accessory = 'Lens Filter' </object>
    <object name="Item3"> Accessory = 'IR Light' </object>
  </and>
</condition>

Note that the element names Item1, Item2, and Item3 are used to assign the matching events to appropriate attributes of the CrossSellEvent instance. Also, this assignment allows (join) predicates across primitive events in a rule condition as follows:

<condition>
  <and join="Item1.Price+Item2.Price+Item3.Price > 300">
    <object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
    <object name="Item2"> Accessory = 'Lens Filter' </object>
    <object name="Item3"> Accessory = 'IR Light' </object>
  </and>
</condition>

Rule Conditions with Any n Semantics

The examples discussed so far use rules that match all the primitive events specified in a rule condition. This is achieved with the use of an <and> element as the parent of all the primitive event conditions. Some rule applications require rules that could match a subset of primitive events specified in the rule condition. For example, consider a composite event CE1 consisting of three primitive events PE1, PE2, and PE3. Now, a rule condition defined for the composite event may need to match only one of the three primitive events. For this example, the composite event structure and the rule condition are represented as follows:

-- Composite event structure --
CREATE or REPLACE TYPE CE1 AS OBJECT (
              pe1Inst PE1,
              pe2Inst PE2,
              pe3Inst PE3);
-- Sample Rule condition --
<condition>
  <any>
    <object name="pe1Inst"/>
    <object name="pe2Inst"/>
    <object name="pe3Inst"/>
  </any>
</condition>

When the rule condition should match any two of the three primitive events, the count attribute of the <any> element can be used, as shown in the example that follows. By default, the count attribute has a value of 1, which is equivalent to a disjunction (OR) of all the primitive events specified within the <any> element.

<condition>
  <any count=2>
    <object name="pe1Inst"/>
    <object name="pe2Inst"/>
    <object name="pe3Inst"/>
  </any>
</condition>

The Any n semantics in the rule conditions are very common in applications using set semantics. The rule considered in the cross-selling application of Chapter4 can be extended to suggest the tripod to the customer if the shopping cart has any two of the three items specified. The condition for this rule can be represented using the Any n syntax as follows:

<condition>
  <any count=2>
    <object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
    <object name="Item2"> Accessory = 'Lens Filter' </object>
    <object name="Item3"> Accessory = 'IR Light' </object>
  </any>
</condition>

In a rule condition, some of the primitive events specified within an <any> list may be mandatory for the condition to evaluate to true. For example, in the preceding rule condition, the Lens (Item1) may be mandatory and it should always count for one item in two items matched with the <any count=2> specification. This new rule condition can be represented using the join attribute of the <any> element as follows:

<condition>
  <any count=2 join="Item1 IS NOT NULL">
    <object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
    <object name="Item2"> Accessory = 'Lens Filter' </object>
    <object name="Item3"> Accessory = 'IR Light' </object>
  </any>
</condition>

Within an <any> list, often there is a need to correlate the primitive events that occur. For example, the preceding rule can be extended to suggest the tripod to the customer only if the Make attribute of the two items matched is same. When using an <and> element (to match all three items), this can be posed as a join predicate on the Make attribute of each primitive event, such as shown in the following example:

<condition>
  <and join="Item1.Make=Item2.Make and Item2.Make=Item3.Make">
    <object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
    <object name="Item2"> Accessory = 'Lens Filter' </object>
    <object name="Item3"> Accessory = 'IR Light' </object>
  </any>
</condition>

However, similar join predicates cannot be used to correlate primitive events in an <any> list because the missing primitive events (the one left out in 2 out of 3) are represented as NULLs and any predicate (other than IS NULL) on a NULL value is always false. For this purpose, when using the <any count=2> specification, the rule should use the following join condition:

(Item1.Make is null and Item2.Make = Item3.Make) or
  (Item2.Make is null and Item1.Make = Item3.Make) or
    (Item3.Make is null and Item1.Make = Item2.Make)

Within an <any> element, the preceding join condition can be represented in an abbreviated form using an equal clause. With this syntax, the join condition works well with any value assigned to the count attribute of the <any> element, such as shown in the following example:

<condition>
  <any count=2 equal="Item1.Make, Item2.Make, Item3.Make">
    <object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
    <object name="Item2"> Accessory = 'Lens Filter' </object>
    <object name="Item3"> Accessory = 'IR Light' </object>
  </any>
</condition>

The equality joins among primitive events of a composite event are very common and thus this abbreviated syntax is supported for <and> element as well, as shown in the following example:

<condition>
  <and equal="Item1.Make, Item2.Make, Item3.Make">
    <object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
    <object name="Item2"> Accessory = 'Lens Filter' </object>
    <object name="Item3"> Accessory = 'IR Light' </object>
</condition>

When both equal and join attributes are used in an <and> or an <any> element, the join predicates represented by the equal specification are combined (using logical AND) with the join predicates listed with the join attribute. For example, the following condition matches any two specified items which are of same make and whose total value is greater than 300. (Note the use of NVL functions in the join predicates).

<condition>
  <any count=2 equal="Item1.Make, Item2.Make, Item3.Make"
       join="NVL(Item1.Price,0) + NVL(Item2.Price,0) + NVL(Item3.Price,0) > 300">
    <object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
    <object name="Item2"> Accessory = 'Lens Filter' </object>
    <object name="Item3"> Accessory = 'IR Light' </object>
  </any>
</condition>

The use of equal attribute at the rule class level (instead of each rule) is discussed in Chapter3.The sequence attribute (Chapter4) can be used in an <any> element to ensure that the matching primitive events happen in the specified order for the rule condition to evaluate to true.

<condition>
  <any count=2 sequence="yes">
    <object name="Item1"> Accessory = 'Lens' and Price > 100 </object>
    <object name="Item2"> Accessory = 'Lens Filter' </object>
    <object name="Item3"> Accessory = 'IR Light' </object>
  </any>
</condition>