Monitorscript

New market-surveillance application

April 22nd, 2008

Built on the Apama platform, it’s called the Detica Market Surveillance Accelator. Designed as a sift, to survey all trades booked in a system for bad and/or illegal behavior, detect errors, and to aid in development of a more proactive support model.

In light of the Société Générale debacle, I expect to see more of these in development. Apama strikes me as a near-ideal match for this kind of application.

CEP coding: An event-cache for Apama

March 13th, 2008

CEP engines try to keep state-management out of the developers’ hands (or, if you prefer, out of your way), letting you concentrate on just the events. Inevitably, though, we end up needing just a little more state than we have in the current event stream; or we have an event that’s needed by several monitors (e.g., benchmark prices); or the event data’s needed in several monitors, but doesn’t actually trigger any action.

Enter the cache-monitor: a common Apama pattern we’ve used in our projects. It’s a simple pattern, but I’m posting it to illustrate Apama’s programming model which seems to be not common knowledge. What throws people for a loop at first is that in order to retrieve a value from a cache-monitor, we mimic a function call from typical procedural languages by routing a Request-event to that monitor, and listening for the matching Reply-event routed back to us by the cache. To see what I mean, consider the 3 snippets below. Read the rest of this entry »

CEP code fragment: Leapfrog queueing in Apama monitorscript

February 7th, 2008

The idea is to respond to incoming price events, but always process the latest event, skipping intermediate events. Here’s the way you can express that in Apama’s monitorscript language.

You can stage processing of an external event by caching an internal-version of the event, and enqueuing a ‘process-this-price’ event (putting it at the back of the queue). As more 3Y prices come in, they overwrite the cached event, and enqueue more ‘process-this-price’ events. When the ‘process-this-price’ events are reached, the latest price will be removed from the cache and the internal-version routed as the ‘real’ price event. Subsequent ‘process-this-price’ events result in no events because the 3Y was already removed from the cache. Here’s the code: Read the rest of this entry »