Complex event processing
Complex Event Processing (CEP) is software technology that enables the detection and processing of
Events derived from other events. A derived event is an event that your application generates as a result of applying a method or action to one or more other events.
Event sequences, often with temporal constraints.
CEP programs find patterns in event data that enable detection of opportunities and threats. Timely responses are then pushed to the appropriate recipients. The responses can be in the form of automated events, such as placing orders in algorithmic trading systems, or alerts to someone using Business Activity Monitoring (BAM) dashboards. The result is faster and better operational decisions
EPL and JMon provide the features needed to write applications that can perform CEP. The following example shows how EPL can concisely define event patterns and rules. While this example shows the implementation of an Apama monitor, an example that shows an implementation of an Apama query would also demonstrate complex event processing.
The NewsCorrelation monitor's onload() action defines a listener that specifies a complex event expression. The literal translation of the expression is “look for all news articles about any stock, followed by a 5% rise in the value of that stock within 5 minutes”. This is the kind of implied news impact that might be of interest to a trader or a market risk analyst.
monitor NewsCorrelation {
action onload() {
on all NewsItem() as news {
on StockTick(symbol=news.subject) as tick {
on StockTick(symbol=news.subject,
price >= (tick.price*1.05))
within(300.0) alertUser;
}
}
}
action alertUser() {
log "News to price movement Correlation for stock "
+news.subject+" has occurred";
}
}
The on keyword specifies a listener. The initial listener nests two additional listeners that define the event sequence of interest. The listeners do the following:
1. The initial listener watches for all NewsItem events.
2. Each time the correlator detects a NewsItem event, this listener captures it in a news variable.
3. The first nested listener then watches for a StockTick event for the stock that the news item was about. This listener uses the news variable to access the information from the previously detected event.
4. When the correlator detects a matching StockTick event, the first nested listener captures it in the tick variable.
5. The innermost listener then watches for another StockTick event for the same stock but with a price that is at least 5% higher than the price in the event captured by the tick variable. The within keyword indicates that the correlator must detect the second StockTick event within 300 seconds (5 minutes) of finding the initial NewsItem event.
6. If the correlator finds a second StockTick event that matches within 5 minutes, the monitor sends a message to the log file. The nested listeners terminate.
If the correlator does not find a second StockTick event that matches within the 5 minutes, the nested listeners terminate without sending a message to the log.