## 5 Proposed Implementation for Parametric Event Transformation
### Abstraction and Reusable Implementation: Splitting  
The motivation for creating the Splitting Composite Transformation is the selection of event types derived from the Ingestion Composite Transformation. That is, their separation from a single stream into distinct event streams, where each stream includes a specific type of measurement, i.e., physical quantity measurement. The specific Composite Transformation serves the requirement of creating homogenized event streams based on the physical quantity type. The user defines, as parameters, the physical quantities for which a discrete event stream must be created. The name of the topic (but also the topic itself), which includes the records of the event stream, is created dynamically. More specifically, the records of all event streams are self-contained and know certain information, such as the quantity type and others, as mentioned in previous sections. Therefore, they can feed processors with useful information to perform various processes. Each message gets the same key.  
An additional abstraction, possibly to extend the first abstraction without depending on it, concerns splitting the events from the single event stream created by the above process. For each discrete physical quantity found in the events, a corresponding event stream is created with the corresponding topic (if it does not already exist). The purpose is to create topics that each include records related to the measurement of the same quantity.  
This part of the abstraction is independent of the first part mentioned above. It is proposed for two main reasons: First, the creation of ready-to-use topics by consumers who want measurements of a specific quantity, and, second, the support of near real-time monitoring of one of the measurements of a specific quantity.  
This abstraction is parametric. The parameter is a list of the physical quantities to create distinct event streams for.  
In detail, the processing is depicted in Figure 4 and includes the following stages:  
**1. stream**: Consumption of data stream from the topic \"sensor_telemetry_measure nt_event\", i.e., processed IoT Events, from the Event Bus in order of the time sequence they were stored. In addition, this specific step includes deserializing the message payload from bytes in the format required by Event Engine, i.e., \"SensorTelemetryMeasurementEvent\", which can be physically represented as either POJO or JSON.  
**2. filter**: This stage filters the records based on the physical quantity in which the measurement they carry refers to. More specifically, the condition is true if the physical quantity is included in the list of physical quantities the user selects to create discrete flows. Conversely, it is discarded if the physical quantity is not in the user's list. It is clarified that if discarded, the event continues to exist in the original event stream.  
**3. to**: Each of the previously consumed events is checked to determine if the Event Engine supports the measurements, and if they are supported, the event is forwarded to the corresponding topic keeping its format, i.e., \"SensorTelemetryMeasurementEvent\". This stage supports the dynamic determination of the topic name. The format of the name is as follows: \"sensor_telemetry_[NAME]_measurement_event\" where \"[NAME]\" is the dynamic portion of the topic name replaced by the name of the physical quantity it represents.