Defining Monitors
Monitors define the processing logic for events. They communicate by sending and receiving events. A single CEP engine can accommodate the injection and simultaneous operation of hundreds of thousands of monitors, each designed to listen for and process different event streams concurrently.
Monitor Contents
Monitor(s) is defined using class, with the class name as the monitor name. A single monitor can contain:
-
Events to be monitored. A monitor must have information about any event types it processes.
-
Global variables. One or more global variables to store the event, which can be accessed by all operations.
-
A number of functions. A monitor can define a set of functions that will be invoked when a filtered event matches the specified conditions.
-
Event listeners. One or more event listeners can be included to listen for the event streams passed to the event matchers from the input queue.
-
The
onload
function. Every monitor must contain anonload()
function. When a monitor is injected into the CEP sub-engine, the engine executes theonload()
.
Monitors are injected into the CEP engine by passing them as an argument to the
createCEPEngine
function, using the monitors parameter.
When the CEP engine is created and started, it automatically executes the
onload
method declared within each injected monitor. This
onload
method initiates the monitor's listening action,
allowing it to start monitoring the specified event streams or sources.
Example of a Simple Monitor
The following script define a monitor "mainMonitor" to monitor the event "orders" defined before.
class mainMonitor{
ordersTable :: ANY // define data member ordersTable with ANY type
isBusy :: BOOL
def mainMonitor(busyFlag){
ordersTable = array(ANY, 0) // define ordersTable as a tuple
isBusy = busyFlag
}
// define a callback function
def updateOrders(event) {
ordersTable.append!([event.trader, event.market, event.code, event.price, event.qty])
}
// declare the onload function, which is invoked when the CEP engine is created
def onload(){
addEventListener(updateOrders, 'orders',,'all')
}
}
Spawning Monitor Instances
It is frequently necessary to enable a single monitor to concurrently listen for
multiple kinds of the same event type. For example, you might want one monitor to
listen for and process stock ticks that each have a different stock name. In such
cases, you can use spawnMonitor
to spawn additional monitor
instances within a single monitor instance. A spawned monitor instance is a
duplicate of the parent monitor instance. Each spawned monitor can listen for events
that have different values in particular fields.
spawnMonitor
implements the following steps:
-
Creates a new instance of the monitor that is spawning.
-
Deep copies all copyable attributes and functions from the spawning monitor instance.
-
Executes the the specified handler action in the new monitor instance.
Syntax
spawnMonitor(handler, arguments...)
Arguments
handler is the action to be invoked to process the events monitored by this spawned instance.
arguments is argument(s) passed to handler.
Terminating Monitor Instances
To terminate monitor instances, you can call destroyMonitor()
. When
a spawned monitor instance terminates, the engine invokes the monitor's
onDestroy
function, if it is defined.
After terminating the monitor instance, the event listeners defined within that instance will cease to be triggered. It will not be removed until the next event match processing cycle starts. Note that monitors injected into the CEP Engine cannot be destroyed until the engine is deleted.
Syntax
destroyMonitor()
Arguments
None