Jump to: navigation, search

VIATRA/CEP/Language/0.8

< VIATRA‎ | CEP‎ | Language

Atomic event patterns

atomicEvent name (parameters) (with list of traits)? {
     check{
           boolean expression(s) as constraints on the parameters
     } //optional
}
  • 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.
  • Multiple traits can be mixed in into atomic 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.) Parameters of traits can be checked as well.

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.

Query result change event patterns

queryEvent name (parameters) as
     name of the referred model query (found | 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 or 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.

Complex event patterns

complexEvent name (parameters) {
     as complex pattern definition
     context chronicle | immediate | strict  //optional
}

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.
"infinite" multiplicity p{*} The pattern can appear 0 to infinite times.
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{
     as 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{
     as 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{
     as atomic1{10}
}
complexEvent ce3b{
    as atomic1{10}[100]
}

These are considered as the normal cases.

Traits

Traits provide abstraction mechanism to Atomic event patterns. Currently, it supports abstraction of event parameters.

trait name {
    list of parameters with optional default values
}

Example

trait position {
     coordinateX : double = 0.0, //definition with default value
     coordinateY : double
}
atomicEvent object with position {
     check{
           coordinateX>0 && coordinateY>0
     }
}

Rules

rule name on comma separated list of complex patterns {
     executable code block using Xbase syntax
}

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. Actions can be defined using Xbase.

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: 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.

Contexts

As from version 0.9, contexts can be specified in the event model, per complex event pattern. The default context can be set via the context keyword, after the import section.