About monitor contents
A file that defines a monitor has the following form:
1. An optional package declaration
2. Followed by
a. Zero or more using declarations
b. Zero or more custom aggregate function definitions
c. Zero or more event type definitions
3. One or more monitor definitions
When you define monitors that are closely related, it is your choice whether to define them in the same file or different files.
A monitor must have information about any event types it processes. Hence, the correlator must receive and parse all of the event types used by the monitor before it is able to correctly parse the monitor itself.
A monitor can contain one or more global variables. A global variable declaration appears inside a monitor but outside any actions. The variable is global within the scope of the monitor.
A monitor can also contain a number of actions. Actions are similar to procedures. Finding an event, or pattern of events, of interest can trigger an action. You can also trigger an action by invoking it from inside another action.
Any construct that you declare inside a monitor is available only from within that monitor. In other words, its use is restricted to the scope of the monitor.
Below is a minimal monitor:
monitor EmptyMonitor {
action onload() {
}
}
The monitor above does not do anything; it does not register interest in any event or event pattern, it does not have variables, and it does not do anything in its single action statement. However, it does show the minimum structure of a monitor:
It specifies the
monitor keyword followed by the name of the monitor. In the example, the name of the monitor is
EmptyMonitor. The name of the monitor and the name of the file that contains the monitor do not need to be the same. A single file can contain multiple monitors.
It declares the
onload() action. When you inject a monitor into the correlator, the correlator executes the monitor's
onload() action. Every monitor must contain an
onload() action. The
onload() action is similar to the
main() function in C/C++.
If you define two or more monitors in the same file, the correlator executes the
onload() actions of the monitors in the order in which you define the monitors. If there is an
onload() action whose execution is dependent on the results of the execution of the
onload() action of another monitor, but sure you define that other monitor earlier in the same file. If you define that other monitor in a separate file, be sure you inject that file first. Tip: it is better to avoid these dependencies as much as possible by using initialization events. See
Using
events to control processing.
EPL provides a number of actions, such as
onload(),
onunload(), and
ondie(). You can define additional actions, and assign a name of your choice that is not an EPL keyword. See also
Keywords.
Do not create EPL structures in the com.apama namespace. This namespace is reserved for future Apama features. If you do inadvertently create an EPL structure in the com.apama namespace, the correlator might not flag it as an error in this release, but it might flag it as an error in a future release.
