Interfaces are used only in Refine rules. In a Refine rule you can either confirm the information contained in the incoming event or complete it with additional information. Interfaces are used in conjunction with programs to pass information back to the rule engine.
The refine rule is used to refine the information contained within the event. External information may be obtained for inclusion in the event through a call to the get_external() primitive. The first argument to
get_external() is the name of the script or executable to be run. The second argument is a LIST_OF_STRING defining the arguments that will be passed to the script or executable. The third argument is the type of interface and the fourth, and last, argument is the variable that will hold the results of the action run. An example is the following call to
get_external(’get_site’, [$EV.hostname], location, $LOC);
The name of the file in which the results of the action are to be written in the BAROC format defined by the interface is prepended to the list of arguments. The data type expected in the file is of type location, defined in the following example.
MC_INTERFACE : location DEFINES { site: STRING ; phone: STRING ; }; END
An example of the script or executable passed as the first argument follows.
For Microsoft Windows platforms the executable get_site.bat should be placed in the kb\bin\w4 directory.
echo location; > %1 echo site=Austin; >> %1
echo phone=555.555.555; >> %1 echo END >> %1
exit
For Unix environments the executable get_site.sh should be placed in the
kb/bin/A directory. #!/usr/bin/ksh echo location\; > $1 echo site=Austin\; >> $1 echo phone=512-219-5086\;>>$1 echo END >> $1 exit 0
Examples of Refine rules using this mechanism can be found in Chapter 5, “The Rule Phases.”
Types
Types used in rules are the same as those defined in the BAROC language. You should ensure that, in writing expressions, the types used in both sides of the expression are the same or at least compatible. Otherwise, the rule may fail to evaluate correctly. The compiler may not be able to detect an error when dynamic expressions from the dynamic data are computed at run time.
Some type conversions are performed automatically. An enumerated type is automatically converted to an integer if assigned to a variable of type integer. The reverse conversion works as well, but the compiler will issue a warning saying that it cannot guarantee the conversion at run time, as the integer value may not be one of the enumerated values.
The compiler checks the variable types and will flag all type
incompatibilities, such as a comparison of two enumerated values of different types.
Variables in MRL are declared automatically at the first occurrence in the text. The scope of a variable is from its declaration to the end of the rule. Apart from global records, there is no concept of global variables in MRL. A variable is an alphanumeric string that may include underscore are permitted) preceded by a dollar sign, such as $EV.
Note
BMC Impact Manager uses only short uppercase names, so you may want to use the same convention.
Most variables are used to point to MRL objects such as events, data, global records or interfaces, but they can also be used to refer to results returned by a primitive. Variables are valued at first occurrence. The value cannot change during the life of the variable. For example, you cannot assign another value to a variable after the first occurrence in a rule. They also obtain their type at the moment of assignment.
In the following construct, the variable $EV points to the event under analysis, so that $EV.<slotname> refers to that particular slot. The slot also must exist in the BAROC definition of that object class.
<ClassName> ($EV) where
[<expression> <op> <expression>, . . .,
<expression> <op> <expression>]
You then can use the variable in expressions later in the rule or in assignment statements.
In the following example, the variable $DATA refers to the data object retrieved by the Using clause, so that the $DATA.<slotname> refers to that particular slot. The slot also must exist in the BAROC definition of that object class.
using [ALL] where
<ClassName> ($DATA> where [booleanExpression], . . .,
<ClassName> ($DATA) where [booleanExpression] }
You then can use the variable in expressions later in the rule or in assignment statements.
The same principles apply to the interface objects where a variable points to the instance returned by the external program and allows the use of the individual slot values in subsequent expressions.
Global records are somewhat different, as their instances are predefined in the Knowledge Base. The scope of those variables is, then, the entire Knowledge Base. A variable $UNDER_MAINTENANCE will refer to the unique instance of the UNDER_MAINTENANCE global record. You can use variables in primitives to obtain the values they return. For example:
concat( [‘from top’, ‘to bottom’ ], $MSG); $EV.msg = $MSG ;
The concat builtin concatenates a list of strings into another string. In the preceding example the $MSG variable obtains the result, so it can be used in subsequent clauses. The preceding example uses the result as an assignment.
It is important to remember that variables can be assigned a value only once.