Developing Apama Applications > Developing Apama Applications in EPL > Defining What Happens When Matching Events Are Found > Sample financial application
Sample financial application
This section describes a complete financial example, using the techniques discussed earlier in this chapter.
This example enables users to register interest, for notification, when a given stock changes in price (positive and negative) by a specified percentage.
Users register their interest by generating an event, here termed Limit, of the following format:
Limit(userID, stockName, percentageChange)
For example:
Limit(1, "ACME", 5.0)
This specifies that a user (with the user ID 1) wants to be notified if ACME’s stock price changes by 5%. Any number of users can register their interests, many users can monitor the same stock (with different price change range), and a single user can monitor many stocks.
In EPL, the complete application is defined as:
event StockTick {
   string name;
   float price;
}
 
event Limit {
   integer userID;
   string name;
   float limit;
}
 
monitor SharePriceTracking {
 
   // store the user’s specified attributes
   Limit limit;
 
   // store the initial price (this may be the opening price)
   StockTick initialPrice;
 
   // store the latest price – to give to the user
   StockTick latestPrice;
 
   // when a limit event is received spawn; creating a new
   // monitor instance for each user’s request
   action onload() {
      on all Limit(*,*,>0.0):limit spawn setupNewLimitMonitor();
   }
 
   // If an identical request from a user is discovered
   // stop this monitor and die
   // if a StockTick event is received for the stock the
   // user specified, store the price and call setPrice
   action setupNewLimitMonitor() {
      on Limit(limit.userID, limit.name, *) die;
      on StockTick(limit.name, *):initialPrice setPrice();
   }
 
   // Search for StockTick events of the specified stock name
   // whose price is both greater and less than the value
   // specified – also converting the value to percentile format
   action setPrice() {
      on StockTick(limit.name, > initialPrice.price * (1.0 +
         (limit.limit/100.0))):latestPrice notifyUser();
     
      on StockTick(limit.name, < initialPrice.price * (1.0 -
        (limit.limit/100.0))):latestPrice notifyUser();
   }
 
   // display results to user
   action notifyUser() {
      log  "Limit alert. User=" +
        limit.userID.toString() +
        " Stock=" + limit.name +
        " Last Price=" + latestPrice.price.toString() +
        " Limit=" + limit.limit.toString();
      die;
   }
}
The important elements of this example lie in the life-cycle of different monitor states. Firstly a monitor instance is spawned on every incoming Limit event where the limit is greater than zero. Within setupNewLimitMonitor, the first on command listens for other Limit events from the same user, upon detection of which the monitor instance is killed. This effectively ensures that there is a unique monitor instance per user per stock. This scheme also allows a user to send in a Limit event with a zero limit to indicate that they actually no longer want to monitor a particular stock. While this will not be caught by the original monitor instance’s event listener and will not cause spawning, it will trigger the event listener in the monitor instance of that user for that stock and cause it to die.
Then a single on command (without an all) sets up an event listener to look for all StockTick events for that stock type for that user. Once a relevant StockTick is detected, new event listeners start seeking a specific price difference for that user. If such a price change is detected it is logged. Note that the log command exploits data from variables used before and after the spawn command (that is, limit and latestPrice, respectively).
This example also demonstrates how mathematical operations may be used within event expressions. Here, two on commands create event listeners that look for StockTicks with prices above and below the calculated price. The calculated price in this case is based on the initial price multiplied by the percentage specified by the user. The first event listener is looking for an increase in the share price to 105% of its original value, while the second is looking for a decrease to 95% of its original value.
Copyright © 2013 Software AG, Darmstadt, Germany and/or Software AG USA Inc., Reston, VA, USA, and/or Terracotta Inc., San Francisco, CA, USA, and/or Software AG (Canada) Inc., Cambridge, Ontario, Canada, and/or, Software AG (UK) Ltd., Derby, United Kingdom, and/or Software A.G. (Israel) Ltd., Or-Yehuda, Israel and/or their licensors.