Analytics Builder 10.9.0 | Using Analytics Builder for Cumulocity IoT | Wires and Blocks | Input blocks and event timing
 
Input blocks and event timing
Input blocks make data from external sources (such as Cumulocity IoT measurements) available to the model. Many data sources have timestamps on each piece of data, which reports the time that a measurement or event actually occurred. There may be delays in transmitting the data to the Apama system for processing, leading to events being received by Apama out of order.
Data sources with timestamps, such as measurements, can be reordered. Operations, for example, do not have timestamps and are therefore processed as they are received, without reordering.
Analytics Builder delivers several input block types which consume data sources with timestamps. These block types provide an Ignore Timestamp parameter which allows you to disable data reordering and thus to process the inputs as they are received. See also Common block inputs and parameters.
The following table lists the available input block types and indicates whether they are able to reorder the input:
Input block type
Reordering is possible
Measurement Input
Yes
Event Input
Yes
Alarm Input
Yes
Operation Input
No
Managed Object Input
No
Position Input
Yes
Note:
The Position Input block is a specialized Event Input block. You can also use the Cron Timer block to activate a model periodically. Unlike the above blocks, the Cron Timer block is not associated with a device and can be found in the Utility category of the palette.
For data sources that have timestamps associated with a piece of data, the input block can handle events received out of order. In order to do this, the input blocks hold all received events in a reorder buffer and delay processing them until a predefined delay time after their source timestamp. By delaying the processing of the event relative to the source timestamp, the input block allows events to be reordered. The key parameter to this process is the amount of time by which the events are delayed. To configure the time in seconds by which the input blocks delay inputs, send a POST request to Cumulocity IoT that changes the value for the timedelay_secs key. See Configuration for detailed information.
The input blocks assume that while events may be delivered out of order, they are received by Apama within the defined time delay value. If an event is received after a delay of more than the defined number of seconds (that is, the difference between the timestamp in the event and the time on the system running Apama), then it is dropped if an event for the same timestamp or a more recent timestamp has already been processed by the model. Thus, it is possible that an old event might be processed by one model but dropped by another model.
If the time delay value is set too low, then a small delay may result in Apama dropping an event, which can lead to erroneous results. The higher the time delay value is, the larger is the delay before an event is processed. Thus, it is important to pick a suitable value for the time delay to match the environment for events being delivered into Apama.
Note:
An event delayed beyond the defined number of seconds is always dropped if any custom input or output blocks written using the version 1 API of the Analytics Builder Block SDK are added as extensions. See the documentation at https://github.com/SoftwareAG/apama-analytics-builder-block-sdk for information on how to migrate such blocks to the version 2 API.
The correlator logs the number of dropped events periodically to the correlator log file. See Configuration for configuring logging throttling and Accessing the correlator log.