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

Difference between revisions of "VIATRA/CEP/Language"

< VIATRA‎ | CEP
(Complex event patterns)
(Complex event operators)
Line 53: Line 53:
 
|-
 
|-
 
|}
 
|}
 +
 +
It is possible to combine the multiplicity and the timewindow operators, although the following rules hold.
 +
#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.
 +
 +
#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.)
 +
 +
#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.
  
 
====IncQuery event patterns====
 
====IncQuery event patterns====

Revision as of 13:17, 11 January 2015

VIATRA-CEP User's guide

The following contents introduce the VIATRA-CEP complex event processing stack and its main features. Basic knowledge on complex event processing is advised, although not strictly required. Should this guide prove to be insufficient, please do not hesitate to ask your question on our mailing list.

Getting started

The VIATRA-CEP stack

//TODO

Language essentials

This section is a brief overview on the features of the VIATRA Event Processing Language (VEPL).

Atomic event patterns

AtomicEvent name (parameters) {body}
  • 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 body is currently not in used, but it will be soon: https://bugs.eclipse.org/bugs/show_bug.cgi?id=440748.

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 /link complex event pattern definitions or /link 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, IncQuery 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)).
until p1 U p2 Once the first pattern appears, no else pattern is allowed to appear until the second pattern appears. Rule: p1 U p2 === p1 -> p1 -> ... p2, unlimited times.
multiplicity p{n} The pattern has to appear n times. Rule: p{n} === p1 -> p1 -> ... p1, n 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(){
     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.

  1. 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.)

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

IncQuery event patterns

IQPatternEvent name (parameters) {
     iqPatternRef: name of the referred IncQuery pattern
     iqChangeType: NEW_MATCH_FOUND or EXISTING_MATCH_LOST
}

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

Rules

Rule name {
     events: complex pattern definition
     action{
          executable code block using XBase syntax
     }
}
Rule name {
     events: complex pattern definition
     actionHandler: reference to an action handler, i.e. a class implementing the IActionHandler interface
}

Packages and Usages

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.

uses package name with wildcard or a specific class in a package
uses-patterns IncQuery pattern package

The uses keyword imports other VEPL packages or source code packages; the uses-patterns keyword imports IncQuery patterns to be used in IncQuery event patterns.

Setting up the environment

  1. Download the latest Eclipse Luna Modeling (currently SR1) package.
  2. Install the following plugins or import their source plug-ins into a running Eclipse instance:
    EMF-IncQuery 0.9.0 
    CI update site
    VIATRA 0.7.0 (required components are VIATRA2-EMF and VIATRA-CEP) 
    CI update site

Examples

You can find demonstrative examples here.

Important links

Back to the top