KDR

The KDR UDRs collected by the KPI Management agent hold the source data for KPI calculations. In your APL configuration, you can map the fields of this UDR type to the fields in your service model, e g metric or dimension objects.

The timestamp of the KDR UDRs are used to trigger closing and opening of periods.

Relation between KDR timestamps, Window Size, and periods

The smallest timestamp among the first KDRs that are routed to KPI Management agent determines the start of the initial period for each respective KPI. The start time is calculated as:

timestamp - (timestamp mod windowSize)

The end of the periods are determined by period start and window size. When a KDR contains a timestamp that exceeds the end of the period and if the delay property is set to 0 (zero) the output is sent to the Workflow. The period is then closed. KDRs that are collected later and that belongs to the closed period will be skipped.

In the figure above, the delay property is set to 1 (one) second. If the delay is configured to be greater than 0 then the trigger for output will be delayed until the KPI Management agent receives a timestamp that exceeds the end of the period with the added delay. This property is used to prevent that periods are closed too early due to late arriving data. The default value of this property is 0 (zero). For further information about how to set the delay property, see KPI Agent.

Processed KPIs will be flushed automatically when you close a workflow.

The following fields are included in the KDR UDRs:

Field	Type	Description
`key`	`bytearray`	This field is reserved for future use.
`timestamp`	`long`	This field must contain a timestamp (e g in Unix time) time for sorting the `KDR` data into a time periods. The meaning of this value can be arbitrary but the contained values should be chronologically consistent. For example the timestamp may indicate either the start or end of a session but not both.
`type`	`string`	This field must contain a string that identifies the `KDR` type. The type is used in the definitions of `metric`- and `dimension` objects in the service model.
`values`	`map<string,any>`	This field must contain a map of key-value pairs where the key is an arbitrary string, and the value contains the input data. The values are used in the definitions of `metric`- and `dimension` objects in the service model.

Example - Mapping input to KDR UDR in APL

kpimanagement.KDR kdr = udrCreate(kpimanagement.KDR);
kdr.type = input.type; 
kdr.timestamp = input.start_time;
kdr.values = mapCreate(string, any);
mapSet(kdr.values, "dimension_1", input.end_time);
mapSet(kdr.values, "dimension_2", input.end_time); 
mapSet(kdr.values, "call_length", input.call_length); 
 mapSet(kdr.values, "connect_latency", input.connect_latency);