When you run a batch or real-time data flow that contains an event strategy with Tumbling windows, you can control whether a Tumbling window emits remaining events after the data flow stops. By default, Tumbling windows emit remaining events after the data flow stops, which prevents data loss. If you disable this option, events that are not emitted from Tumbling windows before the data flow stop are deleted.

Emission of events from incomplete Tumbling windows

A Tumbling window that did not post the collected events is referred to as an incomplete Tumbling window. A Tumbling window that has buffered a specified number of events or its time has elapsed posts the collected events and moves to another chunk of data. Create a simple data flow with an event strategy, run and stop the data flow to learn how events are emitted from incomplete Tumbling windows.

Example

In the following example, the data flow processes a stream of data, for example customers' calls to IT support about technical issues. The calls are collected only when the data flow runs.

Simple data flow that processes a stream of data

The event strategy tracks when each customer makes a phone call to IT support. When there are three phone calls from one customer, they are gathered into an event that in the end is stored in the OutputDDS data set (the destination of the data flow). IT support can use this data to identify customers with the highest number of phone calls which might indicate serious hardware or software problems, and schedule remedial steps.

Simple event strategy with a Tumbling window

When you run a batch or real-time data flow, the Data Flow work item is configured by default to emit incomplete Tumbling windows when the data flow stops. If there are one or two phone calls from one customer after the data flow stops, they are also gathered into an event that in the end is stored in the OutputDDS data set (the destination of the data flow).

Emitting option for Tumbling windows in event strategies

In this example, a single customer made eight phone calls so the stream data set had sent eight events to the Tumbling window when the data flow stopped. Until that moment, the event strategy processed six events in the Tumbling window and emitted them as two events. The data flow stored these two events in the OutputDDS data set (the destination of the data flow). In other words, the data set contained two records with information that a particular customer made six phone calls.

Component statistics for the data flow before it stopped

When the data flow stopped, the Tumbling window was incomplete because there were only two events in the window. However, the Event emitting option was enabled, which forced the two events to be emitted and stored as the third input record in the OutputDDS data set.

Component statistics for the data flow after it stopped

Stopping the data flow caused the remaining events to be emitted. There are now a total of three destination input records with information about eight phone calls that a particular customer made. If the Event emitting option was not enabled, the OutputDDS data set would store information about six phone calls. The last two phone calls would not be stored as the third input record causing data loss.