Event rules

Rules specify which events are selected for processing and then determine how they are processed. Rules differ from policies in that as rules are manually edited, require more effort to implement, but provide more flexibility.

You write rules by using Master Rule Language (MRL) and then compile and store them in the cell's Knowledge Base (KB).

Rule files have an .mrl extension and are located in the rules subdirectory of a Knowledge Base. Rules must be compiled before they can be used by the cell. The compiled files have a .wic or .pkg extension and are also located in the rules subdirectory.

The order of loading into the cell at startup, which determines the order of evaluation, is specified in the .load and .loadwic files (files with the compiler extensions).

MRL conventions

The Knowledge Base Development Reference topics address the purpose of each rule phase with programming examples. This topic focuses on the general syntax of rules and the roles of the different objects and syntactic constructs. When writing rules, use the following conventions:

• Use single quotation marks for all literal strings. This convention is not mandatory for text without internal spaces but is required for text that does contain spaces.
• When a cell name contains a hyphen, the cell name must be enclosed within single quotation marks (').

• When a primitive contains an argument that is a list arg, such as the first argument of a concatenation string, the argument must be enclosed within square brackets.

  concat([this,is,a,quick,example],$CONCAT_STR);

  The compiler validates syntax on primitive arguments. For example, use of a SIMPLE type instead of a LIST will result in a compilation error.

• Literal strings can be no more than 65535 characters in length. If you attempt to compile a rule file containing a slot assignment of a string greater than 65535 characters, the compiler replaces it with the empty string.
• If the newline character, \n, is received as input for a slot value, it is stored as part of the slot value. Neither the cell nor the operators interpret slot values. Therefore, if the newline character is part of the slot value, any search for a match must contain the newline character. Otherwise, the match search is unsuccessful.
• MRL is case-sensitive. References to classes and slots must respect case.
• An event is referenced with a variable name within the rules. Variable names begin with $ and must contain only alphabetic characters. Slots belonging to a particular event are accessed by using the $eventVariable.slotName notation.
• Many rules contain an action block. The action block contains one or more actions that are executed by the rule. Braces ({}) delimit action blocks, and semicolons (;) separate actions within an action block.
• Rules end with the END keyword.

Rule syntax

All rules, in general, have the same structure, which includes the rule introduction, event selection criteria, and the rule body. The generic rule syntax presented in the following figure shows the syntax objects that can appear in a rule, and the following table describes those objects.

Rule syntax

RuleType RuleName:
     <ClassName> { ($<EventVariableName>)}
          { where [ <BooleanExpression> ]}
{  | using {ALL} | unless |
   '{'
     <ClassName> { ($<ObjectVariableName>)}
        {where [< BooleanExpression> ]}
     ...
    < ClassName> { ($<ObjectVariableName>)}
        {where [< BooleanExpression> ]}
  '}'
}
<RuleSpecific>
'{'
  <Call>;
  ...
  <Call>;
'}'
END

Syntax object description