Apama Documentation : Developing Apama Applications : Developing Apama Applications in EPL : Defining Event Listeners : Defining event listeners for patterns of events
Defining event listeners for patterns of events
One way to search for an event pattern in EPL is to define an event listener to search for the first event, and then, in that listener action, define a second event listener to search for the second event in the pattern, and so on.
However, the on statement takes an event expression, and this can be more than just a single event template.
Consider the following very simple example: locate a news event about ACME followed by a stock price update for ACME.
With the EPL explored so far, one would write this as
event StockTick {
   string name;
   float price;
}
 
event NewsItem {
   string subject;
   string newsHeading;
}
 
monitor NewsSharePriceSequence_ACME {
   // Look for a news item about ACME, if successful execute the
   // findStockChange() action
   //
   action onload() {
     on NewsItem("ACME",*) findStockChange();
   }
 
   // Look for a StockTick about ACME, if successful execute the
   // notifyUser() action
   //
   action findStockChange() {
     on StockTick("ACME",*) notifyUser();
   }
 
   // Print a message, event sequence detected
   //
   action notifyUser() {
     log "Event sequence detected.";
   }
}
If, as in this example, you do not intend to express any custom actions after finding an event other than searching for another event, the whole pattern of events to look for can be encoded in a single event expression within a single on statement.
An event expression can define a pattern of events to match against. Each event of interest is represented by its own event template. You can apply several constraints on the temporal order that the events have to occur in to match the event expression.
In the more declarative syntax of an event expression, the above monitor would be written as follows:
event StockTick {
   string name;
   float price;
}
 
event NewsItem {
   string subject;
   string newsHeading;
}
 
monitor NewsSharePriceSequence_ACME {
   // Look for a NewsItem followed by a StockTick
   action onload() {
     on NewsItem("ACME",*) -> StockTick("ACME",*)
      notifyUser();
}
 
   // Print a message, event sequence detected
   //
   action notifyUser() {
     log "Event sequence detected.";
   }
}
Here, instead of just one event template, the on keyword is now followed by an event expression that contains two event templates.
The primary operator in event expressions is ->. This is known as the followed-by operator. It allows you to express a pattern of events to match against in a single on statement, with a single action to be executed at the end once the whole pattern is encountered.
In EPL, an event pattern does not imply that the events have to occur right after each other, or that no other events are allowed to occur in the meantime.
Let A, B, C and D represent event templates, and A', B', C' and D' be individual events that match those templates, respectively. If a monitor is written to seek (A > B), the event feed {A',C',B',D'} would result in a match once the B' is received by Apama.
Followed-by operators can be chained to express longer patterns. Therefore one could write,
on A -> B -> C -> D executeAction();
Notes:
*An event template is in fact the simplest form of an event expression. All event expression operators, including ->, actually take event expressions as operands. So in the above representation, A, B, C, D could in fact be entire nested event expressions rather than simple event templates.
*It is useful to think of event expressions as being Boolean expressions. Each clause in an event expression can be true or false, and the whole event expression must evaluate to true before the event listener triggers and the action is executed.
Consider the above event expression: A -> B -> C -> D
The expression starts off as false. When an event that satisfies the A event template occurs, the A clause becomes true. Once B is satisfied, A -> B becomes true in turn, and evaluation progresses in a similar manner until eventually all of A -> B -> C > D evaluates to true. Only then does the event listener trigger and cause execution of the listener action. Of course, this event expression might never become true in its entirety (as the events required might never occur) since no time constraint (see Defining event listeners with temporal constraints) has been applied to any part of the event expression.
Copyright © 2013-2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback