You may want to perform some processing on available context information. As an example, you may want to automatically detect patterns that require triggering some action or raising some alarm. You can use the FIWARE Complex Event Processing (CEP) as part of the architecture of your applications for this purpose. The Complex Event Processing GE allows you to detect patterns above contexts. This way, instead of reacting to a single context information you can identify and react to patterns over the contexts of several entities or over a context that was changed over time. The Complex Event Processing receives contexts information as input events and generates observations that sometimes called situations, as output events. The CEP GE analyses input event data in real-time, generates immediate insight and enables instant response to changing conditions. The technology and implementations of the CEP provide means to expressively and flexibly define and maintain the event processing logic of the application.
Applications connected to the CEP GE (external applications or some other GEs like the Context Broker GE) can play two different roles: the role of Event Producer or the role of Event Consumer. Note that nothing precludes that a given application plays both roles. Event Producers are the source of events for event processing. Following are some examples of event producers:
- External applications reporting events on user activities such as "user placed a new order", and on operation activities such as "delivery has been shipped".
- Sensors reporting on a new measurement. Events generated by such sensors can be consumed directly by the CEP GE. Another alternative is that the sensor events are gathered and processed through the IoT GEs, which publish context events to the Context Broker GE, having the CEP acting as a context consumer of the Context Broker GE.
Event Producers can provide events in two modes:
- "Push" mode: the Event Producers push events into the CEP by means of invoking a REST API.
- ”Pull” mode: the Event Producer exports a REST API that the CEP can invoke to retrieve events.
Event Consumers are the destination point of events. Following are some examples of event consumers:
- Dashboard: a type of event consumer that displays alarms defined when certain conditions hold on events related to some entities user community or produced by a number of devices.
- Handling process: a type of event consumer that consumes meaningful events (such as opportunities or threats) and performs a concrete action.
- The Context Broker GE which can connect as an event consumer to the CEP and forward the events it consumes to all interested applications based on a subscription model.
The CEP sends output events to the event consumers in a “push” mode by activating their REST API.
The CEP allows you to define patterns over selected events occurring in event processing contexts (such as a time window or segmentation) with optional additional conditions. Those patterns are defined using a Web based authoring tool without the need to write any code. This makes it easier to write the event processing logic and to maintain and change it over time. Examples for supported patterns are:
- Sequence, meaning events need to occur in a specified order for the pattern to be detected. E.g., follow a sensor context, and detect if the sensor status was “fixed” and later was “failed” within a time window.
- Aggregate, compute some aggregation functions on a set of incoming events. E.g., compute the percentage of the sensors events that arrived with a fail status out of all the sensors events arrived in the time window. Alert if the percentage of the failed sensors is higher than 10 percent.
- Absent, meaning no event holding some condition arrived within the time window for the pattern to match. E.g., alert if within the time window no sensor events arriving from specific source have arrived. This may indicate that the source is down.
- All, meaning that all the events specified should arrive for the pattern to match. E.g., wait to get status events from all the 4 locations, where each status event arrives with the quantity of reservations. Alert if the total reservations are higher than some threshold.
Every pattern is associated with an Event processing context. Event processing context groups event instances so that they can be processed in a related way. It assigns each event instance to one or more processing context partitions. Event processing context can be a temporal processing context, a segmentation processing context, or a composite context that is to say one made up of other processing context specifications.
- Temporal processing context defines a time window. If a pattern is associated with a temporal processing context, it will process only the events arriving within this time window. E.g., “within 5 seconds after sensor events with high value”, “A time window bounded by Order-Placed and Order-Delivered events”
- Segmentation processing context defined a matching criteria based on the attribute values of the events. E.g., “Sensor’s ID”, “Shipment’s ID”, “Building’s ID”. Events that belong to the same matching criteria (e.g., have the same sensor ID) will be processed together within the same processing context partition.
If you are interested in more details check out:
If you want to start experimenting and doing hands-on work, have a look at: