Indexes in rules

Use indexes to improve rule performance. Indexes enable the rule engine to find event or data instances more rapidly. When only a limited selection of instances is required, an index avoids iteration over all instances. You can also use an index to determine the order of iteration over a set of event or data instances.

A sorted index implements an order on the instances. If the goal is to determine the search order, use a sorted index. When the goal is mainly performance improvement, a hashed index (an index based on a hash table) will produce the best results.
You must define key slots when there is a need to enforce uniqueness on a combination of slots. Hashed indexes do not enforce uniqueness. Several instances can have the same value for all of their indexed slots, but with key slots, only one instance can have a certain combination of slot values. When there is no need to enforce a uniqueness, use hashed indexes rather than key slots for optimization.

Indexes are defined with in the MRL with a rule-like syntax. An index rule will not do any processing on an incoming event. Following is the syntax for an index definition within a rule:

index IndexName : CLASS ( sorted|hashed )
   Slot | '[' Slot { , Slot } ']'
END

You can define an index for an event class and for a data class.

You can define an index for a single slot or for a list of slots. On a list of slots, a sorted index will start sorting on the first slot. Instances with the same value in the first slot will be sorted on the second slot and so on. The slots in the slot list must be slots of the indicated class or of one of its superclasses.

You can define more than one index for the same class. A subclass inherits an index definition from its superclass if one is defined. An index definition for a subclass does not override an inherited index. All index definitions for a class remain effective whether they are defined directly for the class or inherited from a superclass.

The following example shows two index definitions. The first is a sorted index for two slots; the second is a hashed index for a single slot.

index Idx1 : EVENT_CLASS sorted [date_reception,data_handle] END
index Idx2 : BMC_Base_Element hashed Name END

Using indexes

You use an index in a usingclause. Instead of specifying a class name, you can specify an index name defined for that class.

The following example shows three general forms of an index using clause:

using index IndexName '[' ']' '(' $IndexVariable ')' [ where '[' ... ']' ]
using index IndexName '[' SlotVal [ { , SlotVal } ] ']' '(' $IndexVariable ')' 
[ where '[' ... ']' ]
using index IndexName '[' Slot=SlotVal [ { , Slot=SlotVal } ] ']' '(' $IndexVariable ')' [ where '[' ... ']' ]

The difference among these three forms is in the specification of the actual indexed slot values.

• The first form does not specify any slot value. 
• The second form specifies one or more values for indexed slots in the same order as in the index definition. 
• The third form specifies one or more values for indexed slots by name. In this case, it is not necessary to list the slots in the same order as in the definition.

A sorted index does not require you to provide an actual value for each of the indexed slots. However, all slots for which an actual value is specified must be at the beginning of the slot list in the definition. For example, if an index is defined for the slot list [slot1, slot2, slot3, slot4], it is valid to have an actual value for slot1 and slot2 and no values for slot3 and slot4. It is not valid to provide an actual value for slot2 and slot3 only, because the first slot, slot1, is left unspecified. It also valid to specify none of the indexed slots for a sorted index.

To use a hashed index, you must specify all indexed slots with an actual value.

The rule compiler will report invalid use of an index in error messages.

For these indexes:

index Idx1 : EVENT_CLASS sorted [date_reception,data_handle] END
index Idx2 : BMC_Base_Element hashed Name END

the following example illustrates their use in New rules:

new Rule1 : EVENT($EV) where [...]
     using ALL { index Idx1[]($E) where [...] }
     ...
 END
 new Rule2 : MY_EVENT($EV) where [...]
     using { index Idx2[$EV.ci_name]($D) }
     ...
 END

The rules use $E to refer to the EVENT_CLASS instances and $D to refer to the BMC_BaseElement instances that are retrieved through the indexes.

The first rule, Rule1 uses the sorted index Idx1 without specifying any of the indexed slots. As a result, it iterates over all EVENT instances in the order of the index (which can impact performance if there is a large number of instances). The additional where condition selects the desired data instances.

The second rule, Rule2 uses a hashed index. It provides the mandatory actual value for the indexed slot Name, assuming that the MY_EVENT instance has a slot ci_name that contains the Name of the relevant BMC_BaseElement instance.