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.
The default workflow
Based on the case studies we met, the usual workflow with VIATRA-CEP is the following.
First, you define your event model featuring
- atomic event patterns,
- complex event patterns, and
- rules, which define executable actions and associate them with the occurrence of previously defined atomic or complex event patterns.
During modeling event patterns and rules, high-quality Java code is generated. Only one of the generated packages is relevant for the user to implement his application, which is the base package. Its name is the same as the one defined in the event model. The base package contains a factory (CepFactory.java) providing factory methods for every event and rule class the user might want to reuse (instantiate) in the application.
After setting up the application, an instance of the VIATRA-CEP engine is acquired and subsequently an event stream is acquired as well from the engine's stream manager to publish the events of the application upon.
When the application starts, we enter the actual event processing phase. During this phase:
- events from the application are pushed to the event stream, whilst
- the engine continuously processes the events and
- executes actions upon the recognized event patterns
The special case of model events
As mentioned earlier, a unique feature of the VIATRA-CEP stack is the tight integration with an incremental graph query engine (EMF-IncQuery). This enables observing events arising from an underlying EMF model, and that in a fully automated way.
The workflow in this case is similar to the default one above. There are two important differences though.
First, before defining the event model, one also has to define graph pattern queries for the underlying model.
The second important difference does not actually affect the user, since it is a change in the runtime execution.
In order to observe events of the underlying model, these events are required to be forwarded to the CEP engine. Although, this is fully automated and therefore, completely invisible to the user. In the background, the an bridge component (IncQuery2ViatraCep.java) is generated which
- produces events on both newly found and disappearing graph pattern matches, and
- forwards them to the CEP engine on a dedicated event stream.