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 an onload() function. When a monitor is injected into the CEP sub-engine, the engine executes the onload().

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:

  1. Creates a new instance of the monitor that is spawning.

  2. Deep copies all copyable attributes and functions from the spawning monitor instance.

  3. 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