View source for 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 <tt>'''('''name:String, id:'''int)'''</tt>. Parameters are evaluated at runtime. To see the main motivation behind this, see the [[#Complex_event_patterns|Complex event patterns]].
*Multiple [[#Traits|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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=440748 Bugzilla entry].) Parameters of [[#Traits|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_patterns|Complex event pattern]] definitions or [[#Rules|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|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|Complex event patterns]], just like simple [[#Atomic_event_patterns|Atomic event patterns]].
The default query engine supporting this feature is [http://www.eclipse.org/incquery/ EMF-IncQuery].

=Complex event patterns=
 '''complexEvent''' ''name'' '''('''''parameters''''')''' '''{'''
      '''as''' ''complex pattern definition''
      '''context''' ''chronicle | immediate | strict''  //optional
 '''}'''
The <tt>definition</tt> block holds the actual pattern. It is built up using [[#Atomic_event_patterns|Atomic event patterns]], [[#Query_result_change_event_patterns|Query result change event patterns]] and other [[#Complex_event_patterns|Complex event patterns]], which are chained together by [[#Complex_event_operators|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|Complex event patterns]] and reusing these patterns in the original definition.

==Complex event operators==
{| border="1" cellpadding="5" cellspacing="0" align="center"
|-
! Operator name 
! Denotation
! Meaning
|-
|followed by
|p<sub>1</sub> <tt>'''->'''</tt> p<sub>2</sub>
|Both patterns have to appear in the specified order.
|-
|or
|p<sub>1</sub> <tt>'''OR'''</tt> p<sub>2</sub>
|One of the patterns has to appear.
|-
|and
|p<sub>1</sub> <tt>'''AND'''</tt> p<sub>2</sub>
|Both of the patterns has to appear, but the order does not matter. Rule: p<sub>1</sub> <tt>'''AND'''</tt> p<sub>2</sub> === ((p<sub>1</sub> <tt>'''->'''</tt> p<sub>2</sub>) OR (p<sub>2</sub> <tt>'''->'''</tt> p<sub>1</sub>)).
|-
|negation
|<tt>'''NOT'''</tt> p
|On atomic pattern: event instance with the given type must not occur. On complex pattern: the pattern must not match.
|-
|multiplicity
|p<tt>'''{'''''n'''''}'''</tt>
|The pattern has to appear ''n'' times, where n is a positive integer. Rule: p<tt>'''{'''''n'''''}'''</tt> === p<sub>1</sub> <tt>'''->'''</tt> p<sub>1</sub> <tt>'''->'''</tt> ... p<sub>1</sub>, ''n'' times.
|-
|"at least once" multiplicity
| p<tt>'''{+}'''</tt>
|The pattern has to appear at least once.
|-
|"infinite" multiplicity
| p<tt>'''{*}'''</tt>
|The pattern can appear 0 to infinite times.
|-
|within timewindow
|p<tt>'''['''''t''''']'''</tt>
|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.
|-
|}

<br/>
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|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 [https://wiki.eclipse.org/Xbase Xbase] syntax''
 '''}'''

Rules connect defined event patterns with executable actions. If any of the event patterns in the <tt>events</tt> block is observed, the related action is executed. Actions can be defined using [https://wiki.eclipse.org/Xbase 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: <tt>com.company.cepproject</tt>.
 '''import''' ''package name with wildcard or a specific class in a package''
 '''import-queries''' ''model query pattern package''
The <tt>import</tt> keyword imports other VEPL packages or source code packages; the <tt>import-queries</tt> keyword imports model queries to be used in [[#Query_result_change_event_patterns|Query result change event patterns]].

=Contexts=
As from version 0.9, contexts can be specified in the event model, per [[#Complex_event_patterns|complex event pattern]]. The default context can be set via the '''context''' keyword, after the import section.