Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

VIATRA/CEP/Language

< VIATRA‎ | CEP
Revision as of 12:33, 27 August 2015 by Davidi.inf.mit.bme.hu (Talk | contribs) (Atomic event patterns)

Atomic event patterns

AtomicEvent name (parameters) {
     check {
           boolean expression(s) as constraints on the parameters
     }
}
  • The name of the atomic event must be unique among the model.
  • The parameters are typed and use the JVM type hierarchy. An example parameter list could be (name:String, id:int). Parameters are evaluated at runtime. To see the main motivation behind this, see the Complex event patterns.
  • The check expression is used to filter the observed event instances based on logical constraints on the parameters specified in the pattern header. (See the Bugzilla entry.)

From this structure, two types of source code is generated: atomic events and atomic event patterns. The former ones are used by applications to be instantiated and forwarded to the engine; while the latter ones are actual patterns which can be reused in Complex event pattern definitions or Rules.

Complex event patterns

ComplexEvent name (parameters) {
     definition: complex pattern definition
}

The definition block holds the actual pattern. It is built up using Atomic event patterns, Query result change event patterns and other Complex event patterns, which are chained together by Complex event operators. The definition can be nested using parentheses, although, for the sake of clarity, we recommend avoiding too complex patterns by breaking them into separate Complex event patterns and reusing these patterns in the original definition.

Complex event operators

Operator name Denotation Meaning
followed by p1 -> p2 Both patterns have to appear in the specified order.
or p1 OR p2 One of the patterns has to appear.
and p1 AND p2 Both of the patterns has to appear, but the order does not matter. Rule: p1 AND p2 === ((p1 -> p2) OR (p2 -> p1)).
negation NOT p On atomic pattern: event instance with the given type must not occur. On complex pattern: the pattern must not match.
multiplicity p{n} The pattern has to appear n times, where n is a positive integer. Rule: p{n} === p1 -> p1 -> ... p1, n times.
"at least once" multiplicity p{+} The pattern has to appear at least once.
within timewindow p[t] Once the first element of the pattern is observed (i.e. the patterns "starts to build up"), the rest of the pattern has to be observed within t milliseconds.


It is possible to combine the multiplicity and the timewindow operators, although the following rules hold.

1. Single atomic event pattern in a complex event definition.

ComplexEvent ce1(){
     definition: atomic1
}

This will result in a warning, since does not add anything to the atomic definition and therefore, it is considered as an anti-pattern.

2. Single atomic event pattern with a timewindow operator, but without a multiplicity operator.

ComplexEvent ce2(){
     definition: atomic1[100]
}

This will result in an error, since it is not meaningful to specify constraints over elements with point-semantics in a given dimension. (In this case: the time dimension of an atomic event pattern.)

3. Single atomic event pattern with a multiplicity operator and an optional timewindow operator.

ComplexEvent ce3a(){
     definition: atomic1{10}
}
ComplexEvent ce3b(){
    definition: atomic1{10}[100]
}

These are considered as the normal cases.

Query result change event patterns

QueryResultChangeEvent name (parameters) {
     query: name of the referred model query
     (resultChangeType: NEW_MATCH_FOUND or EXISTING_MATCH_LOST)?
}

Query result change event patterns are specific types of Atomic event patterns. They arise from an underlying EMF model observed by a query engine. When the referred query is found (NEW_MATCH_FOUND) or lost (EXISTING_MATCH_LOST), a generated bridge component between the query engine and the CEP engine generates an event and forwards it to the CEP engine. Query result change event patterns can be reused in Complex event patterns, just like simple Atomic event patterns. The default query engine supporting this feature is EMF-IncQuery.

Rules

Rule name {
     events: comma separated list of complex patterns
     action {
          executable code block using Xbase syntax
     }
}
Rule name {
     events: comma separated list of complex patterns
     actionHandler: reference to an action handler, i.e. a class implementing the IActionHandler interface
}

Rules connect defined event patterns with executable actions. If any of the event patterns in the events block is observed, the related action is executed. One can define actions either by the action block and write the executable code snippet in-place; or by using the actionHandler, which gives a reference to an external class implementing the IActionHandler interface. In the former case, the action is defined using Xbase, in the latter case via Java, Scala, or any other JVM language.

Accessing parameter bindings and observed event instances

The bound parameters can be obtained as follows:

ruleInstance.atom.parameterTable.parameterBindings

Atomic event instances building up the matched event pattern can be obtained as follows:

ruleInstance.atom.observedAtomicEventInstances

Packages and Imports

package name

VEPL allows the model to be organized into different packages and reuse those packages in other ones by usages. Every model begins with a package declaration, which is a hierarchical identifier. For example: package com.company.cepproject.

import package name with wildcard or a specific class in a package
import-queries model query pattern package

The import keyword imports other VEPL packages or source code packages; the import-queries keyword imports model queries to be used in Query result change event patterns.

Back to the top