Page tree
Skip to end of metadata
Go to start of metadata

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

Object

Description

RuleType

Specifies the phase for which the rule is written.
Following are the rule types:

  • Refine
  • Filter
  • Regulate
  • New
  • Abstract
  • Correlate
  • Execute
  • Threshold
  • Propagate
  • Timer
  • Delete

RuleName

Specifies the unique, descriptive name of the rule, by using alphanumeric characters (it can include underscores).

The name must be unique across the entire Knowledge Base, and it must be descriptive because you need to identify it easily in tracing and log output files.

Event condition formula

Event condition formula (ECF) begins with ClassName.
The ECF specifies the conditions that the event currently being processed must match for the rule to be evaluated. ClassName specifies the event class that the event must match. The class of the event instance can be a subclass of ClassName.

Note

To apply the rule to all incoming event instances, specify ClassName as EVENT.

Optional clause

The optional clause is enclosed within the curly braces. It begins with {{{ | using}} and ends before <RuleSpecific>.

This portion of the syntax contains a query clause that directs the rule engine to retrieve data or events from the dynamic data repository to be used in the remainder of the rule.

This example includes the Using clause qualified by an Unless clause.

The object that matches the specified conditions is retrieved by the Using query clause and can be used in the body of the rule.

If the query has no matches, then the Unless clause is applied.

The body of the rule (see below) is executed for every match to these queries when the optional keyword "ALL" is specified after the "using" keyword.

For more information about the use of clauses, see MRL event selection clauses.

{ }

Optional clause indicators (curly braces)

'{'

The actual character '{'

| using {ALL} | unless> |

Using either {ALL} or unless

<EventVariableName>

Name of a variable representing an event

<ObjectVariableName>

Name of a variable representing an event or data

< BooleanExpression>

An expression whose value is  Boolean

<Call>

An assignment or a primitive call

<RuleSpecific>

The body of the rule, specifying actions to be performed on events, slots to be modified, and primitives to be used

The syntax of the rule body and meaning of the primitives depend on the rule type to which the rule belongs.