VIATRA/CEP/Language

VIATRA-CEP User Documentation

VIATRA-CEP supports two main aspects of the typical event processing workflow:

• modeling atomic and complex event patterns;
• detecting the modeled patterns on streams of events by its own event processing stack.

One of the great features of VIATRA-CEP is the tight integration with EMF-IncQuery, an incremental query engine for EMF models, which enables defining event patterns essentially describing elementary or compound changes in EMF models.

An event processing example

Case study

A server-side cluster consists of two servers: the Primary (P) and the Backup(B). The cluster works in a failover fashion, that is, it is the Primary server by default providing the service, but in any case of potential failure (e.g. memory overload, CPU overload, etc), the service is switched to the Backup server.

A monitoring framework is employed to detect the following threats in the cluster:

• there is a problem with the Primary server (CPU load is above 0.9);
• there is a problem with the Backup server (CPU load is above 0.9).

The framework sends notifications if any of the above problems arises. Notifications are also generated if the threat is over.

In case both servers experience problems, the administrator should be alerted. In case of a threat is over on the Primary server, a failback action should be executed; that is after switching from the Primary server to the Backup, now it must be switched back to the Primary.

Our task is to model the events generated by the monitoring framework and thus detect threads using the VIATRA-CEP complex event processing engine.

Step 1: Defining event patterns

AtomicEvent primaryThreat(){ }

AtomicEvent backupThreat(){ }

AtomicEvent primaryOK(){ }

AtomicEvent backupOK(){ }

ComplexEvent bothServersAreInThreat(){ definition: primaryThreat -> backupThreat }

ComplexEvent failbackRequired(){ definition: primaryThreat -> backupThreat -> primaryOK }

Step 2: Defining rules for executable actions

Rule notifyAdmin{ events: bothServersAreInThreat action{ System.out.println("NOTIFYING ADMIN...") } }

Rule executingFailback{ events: failbackRequired action{ System.out.println("EXECUTING FAILBACK ACTION...") } }

Step 3: Execution

public class Application { private CEPEngine engine; private EventStream eventStream;

@Before public void setUp() { engine = CEPEngine.newEngine(EventContext.CHRONICLE); eventStream = engine.getStreamManager().newEventStream();

engine.addRule(CepFactory.getInstance().createNotifyAdmin()); engine.addRule(CepFactory.getInstance().createExecutingFailback()); }

@After public void tearDown() { eventStream = null; engine = null; }

@Test public void test() { engine.setCepEngineDebugLevel(Level.DEBUG);

eventStream.push(CepFactory.getInstance().createPrimaryThreat_Event(null)); eventStream.push(CepFactory.getInstance().createBackupThreat_Event(null)); } }

0 [main] DEBUG org.eclipse.viatra.cep - EventModelManager: Event org.eclipse.viatra.cep.examples.cluster.model.events.PrimaryThreat_Event captured... 10 [main] DEBUG org.eclipse.viatra.cep - EventModelManager: Event org.eclipse.viatra.cep.examples.cluster.model.events.BackupThreat_Event captured... NOTIFYING ADMIN...

@Test public void test() { engine.setCepEngineDebugLevel(Level.DEBUG);

eventStream.push(CepFactory.getInstance().createPrimaryThreat_Event(null)); eventStream.push(CepFactory.getInstance().createPrimaryOK_Event(null)); }

0 [main] DEBUG org.eclipse.viatra.cep - EventModelManager: Event org.eclipse.viatra.cep.examples.cluster.model.events.PrimaryThreat_Event captured... 16 [main] DEBUG org.eclipse.viatra.cep - EventModelManager: Event org.eclipse.viatra.cep.examples.cluster.model.events.PrimaryOK_Event captured... EXECUTING FAILBACK ACTION...

Adding EMF models into the mix

//TODO modify the above example appropriately