Data Export

Hyper Alarm logger logs alarm messages in the proprietary data format stored in SQLite database tables. However, in some cases, it can be useful to have alarm data accessible in different data formats (textual files, databases). The initial version of Data Exporter supports two target storages. Additional storages will be implemented in the future releases:

General concept

Data exporter starts data exports based on global trigger events. Then exporter reads the stored alarm messages from the logger’s internal storage, using time range where start time is an end time from the previous synchronization batch. The first synchronization batch uses “Starting At” settings in the exporter task configuration. The end time is determined as “time now” subtracted by synchronization offset. The last data synchronization time is persistently stored on the alarm logger’s host machine. Thus, even after alarm logger restarts, the data export continues synchronization after the last synchronized interval.

 

The data read from the logger’s storage can be optionally filtered based on the available input alarm fields. The output dataset can reorganize input fields, optionally create new ones, based on expression evaluation.

 

Failures to target storage access are handled by the retry mechanism. The retry storage configuration (# of retries and retry delay) can be found in the storage configuration form.

 

Besides automatic data exports, manual data resynchronization is supported. User can specify a time domain and simple data export task filters to resynchronize exported data. Resynchronization task can either run immediately or can be scheduled for later processing. Resynchronization tasks can be created in Workbench configuration tool or entered manually into input task folder. 

 

In redundant scenario, only active server synchronizes export data, including situations when resynchronization tasks are entered for processing on an inactive server.

Configuration

Hyper Alarm Logger configuration tree

 

Three areas must be configured to export data: where to store exported data, what should be stored and when data exports should run. All three parts of the data exporter configuration are located under the main data exporter folder:

Storages

Storages represent export targets. The initial version supports two storage types: SQL/Azure SQL server and CSV files created on a local disk or NAS. Cloud-based storages are planned for future releases.

 

New Storage

 

Storage Connection

This section configures general connection parameters – connection type and storage connection properties. Connection string edit box is context specific – for SQL server type, it contains database connection string, but for CSV exports, this connection string represents the target file directory.

 

Textual aliases can be used as a part of a connection string. Aliases are delimited by << and >> delimiters.  These aliases are resolved separately for each exporter task.

Advanced

Local CSV Files Storage

This storage type creates one or multiple CSV files directly in the root directory specified.

 

The CSV format uses standard reserved characters, which means a comma for separating cells, a system defined new-line delimiter (CR+LF on Window), and double quotes to escape any reserved characters inside cell values. Double quotes in cell values are doubled.

Creating and appending files

When creating a new file, the first line will be a header line containing all the column names. This header line is never modified, and new data is only ever appended to the end of the file.

 

It means that if the Dataset configuration changes and columns are added, removed, modified or reordered, the existing header in the CSV file may no longer match the data that is appended after the configuration change. It is necessary to manually reexport the data to fix it. See elsewhere in this documentation.

Non-array data types

As the CSV file is a purely textual file, all data types supported by the Hyper Alarm Logger are the first converted to the text before exporting. In most cases, the conversion is straightforward, the following table only lists cases that require some explanation. The exported format is the same whether the ‘Target Data Type’ on the Dataset Column definition is set to ‘Native’, ‘String’, or the actual data type of the exported value.

 

Type

Notes

Boolean

Exported as true/false

Float32, Float64

Always using the dot (.) as the floating-point character, regardless of culture settings.

Date Time

Using the ISO 8601 extended format (.NET formatting string is yyyy-MM-ddTHH:mm:ss.FFFFFFF)

Date Time Offset

Using the ISO 8601 extended format with offset (.NET formatting string is yyyy-MM-ddTHH:mm:ss.FFFFFFFzzz)

Duration

Formatted as [-][d.]hh:mm:ss[.fffffff]. Elements in the square brackets are optional, fractional positions are used only as required.

Guid

Formatted as xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

Status Code

The numerical value of the status code is exported.

Array data types

Hyper Alarm Logger can export one dimensional arrays of any of the supported data types by formatting the value as JSON. The individual elements of the JSON array will be formatted the same way as single (non-array) values are.

The only exception is the array of UInt8, which will get converted to Base64.

Limiting cell size

For CSV, the ‘Data Type Length’ setting on the Dataset’s column definitions limits the number of text characters that is exported per cell value. If the textual representation of the value is longer, it gets truncated. Leaving the ‘Data Type Length’ at zero disables the length limit.

SQL / Azure SQL

This storage type creates one or multiple database tables in the database specified by the connection string.

Creating and appending tables

New tables are created from the current Dataset configuration. If the Dataset configuration changes later, the missing columns are added to the database table, but the existing columns are never removed. The settings (data type) of existing columns are never changed.

 

That means that if the Dataset configuration changes and columns are modified, it may no longer be possible to export data to the existing database table because of type mismatches. These errors will show in traces and in the event viewer.

 

It is necessary to manually delete the existing database tables and reexport the data to fix it. The Hyper Alarm Logger is not programmed with the capability of deleting the database tables.

Non-array data types

The following table lists all the simple (non-array) column data types supported by Hyper Alarm Logger and describes how they map to SQL data types. Column data types are specified on the Dataset configuration.

 

Type

SQL Type

Notes

Native

sql_variant

Please see a next section how data is exported into the sql variant type.

Boolean

bit

 

String

nvarchar

This data type accepts the ‘Data Type Length’ setting from the Dataset Column. A value of 0 on this setting or anything bigger than 4000 will create a SQL column with a maximum length, nvarchar(max). Any value longer than the column allows will be truncated.

Float32

real

 

Float64

float

 

Int8

smallint

 

Int16

smallint

 

Int32

int

 

Int64

bigint

 

UInt8

tinyint

 

UInt16

int

 

UInt32

bigint

 

UInt64

numeric(20)

 

Date Time

datetime2(7)

 

Date Time Offset

datetimeoffset(7)

 

Duration

numeric(19,7)

Duration in seconds. The precision of the Hyper Alarm Logger on Date Time and Duration types is 7 decimal places.

Decimal

varchar(31)

The Decimal is a 128bit floating point value with some floating limitations (please consult the .NET manual if details are required). Unfortunately, this data type is not natively supported by SQL, and is hence stored as a text value.

Guid

uniqueidentifier

 

Character

nchar(1)

 

Status Code

bigint

The numerical value of the status code is exported.

 

Array data types

Hyper Alarm Logger can export one dimensional arrays of any of the supported data types. It will do so by creating a nvarchar(n) column and then exporting the value formatted as JSON. The only exception is the array of UInt8, which will get exported straight into a varbinary(n) column.

 

In both cases, the “Data Type Length’ setting from the Dataset Column is accepted when creating the SQL column. A value 0 on this setting or anything bigger than 4000 for nvarchar, or 8000 for varbinary will create a SQL column with a maximum length.

 

The individual elements of the JSON array will be formatted the same way as single (non-array) values of the CSV file are. Please consult the CSV section for formatting details.

Native data type (sql_variant)

When a Dataset Column’s type is set to ‘Native’, the exporter will create a sql_variant column in the target table. The ‘Is Array’ check box is ignored for the ‘Native’ data type.

 

Hype Alarm Logger will export data into the sql_variant column in the same format as it would into the strongly typed column. That means that arrays of values will be exported as JSON text for example.

 

Be aware though that the maximum length of the text stored in the sql_variant column is 4000 character (using the nvarchar type) and any longer text is truncated. The maximum length for varbinary byte arrays is 8000 bytes. The ‘Data Type Length’ setting does not apply to the sql_variant type.

Datasets

Dataset configuration defines output columns for export dataset. Dataset can be created as a combination of data coming from different logger collections. It combines columns from all collections into single dataset, rows can be optionally filtered by expression-based condition.

 

To start with a new dataset definition, fill-in dataset name.

General Page

General Page in Datasets

 

Collections Page

Collections Page in Datasets

 

Columns Page

“Columns” page is the most complex configuration form in the dataset’s configuration. Columns can be manipulated in a similar fashion as data collection association. The “Add” and “Remove” buttons are used to add or remove columns. Each column is defined as an expression; thus, the column value is not necessarily mapped to a single collection column. Instead, it can be created from multiple dataset columns and optionally formatted using expression functions. Each column can be formatted into “Target Data Type”, or it may keep data type returned from an expression evaluation.

 

Columns Page in Datasets

 

Tasks

Tasks represent the topmost entities which link “Storages”, “Datasets” and define when an export should run by utilizing a global triggering system.

 

Tasks

 

General Settings

Storage Trigger Event

Triggers in Data Browser

 

Data Storage Schedule

This section specifies when to create a new storage entity (that is a database table or export file). It allows to use either one storage entity to export all of the data, or to split data into multiple entities based on their time stamp, for example to split data into daily or monthly files/tables.

 

Whether exporting into CSV or into a database table, the name of the entity follows the same pattern. When exporting all data into a single entity, the name of the entity will be simply the name of the Task, with a file extension applied in case of the CSV file. That means that the file will be named for example NewTask.csv, and the table will be named NewTask.

 

When splitting data into multiple entities, the name of the entity will be <TaskName>_<StartTime>--<EndTime>[.extension]. The StartTime and EndTime are in the ISO 8601 extended format and are separated by two hyphens (also according to ISO 8601).

 

Advanced

First_alias_name=first_alias_value;Second_alias_name=second_alias_value; …

 

A browse alias dialog can be used to setup aliases – click on the icon next to “Aliases” edit box.

 

Aliases Browser

 

Data Export - System Settings

General data exporter settings can be found under the “Product Configuration” folder in the “System Settings” configuration form. The last section in this form is dedicated to “Data Exporter”.

 

"System Settings" configuration form - Data Export

 

Data Export Concurrency Level

The maximum concurrently running exporter tasks should prevent the system overload when too many exports are triggered at the same time. The exporter infrastructure begins the data export for specified maximum exporter tasks and waits until some of them completes. After that, pending exporter task can begin the data export.  

Export State Directory

The Export state file persistently stores information about last exported times for each configured exporter task. This setting specifies a folder on the local disk where state storage file should be created. When this setting is empty,  it uses the “ProgramData\ICONICS\HyperAlarmLogger\DataExport” folder. When default location is modified, make sure that logger service has the "read/write/create access" permissions to the newly configured folder.

Export State Flush Time

This is a period in which the logger stores the modified data export state. If it is “too fast”,  it may consume unnecessary host system resources. If it is “too slow”, the system is in risk of loosing synchronization end times in case of system failure.

Synchronization Tasks Directory

Synchronization tasks are used to re-synchronize the exported data. The data exporter uses textual files to describe data resynchronization parameters. Running data exporter accepts such files from the file directory configured in this setting. When empty, the logger uses the “ProgramData\ICONICS\HyperAlarmLogger\DataExportTasks” folder.

 

Data Exporter Tasks

Sometimes is necessary to re-synchronize exported data. This functionality is available using data exporter tasks. These tasks are represented by textual files, where task values are encoded as set of key-value pairs structures. Task files can be created either using workbench configuration form or created manually and placed into specific file directory, configured in system settings. See Synchronization Tasks Directory).  

Data Exporter Task Management

Task management GUI can be found under “Hyper Alarm Logger” - the “Product Configuration” folder in the Workbench’s project explorer tree.

 

Data Exporter Tasks Management

 

To create new a new synchronization task, click on the “+” button. This shows the following configuration dialog:

 

A new Synchronization task

 

Times are in Local Time – when checked, all times shown in this dialog are in the host system time zone. However, the created task file has all times always in UTC.

 

Execution time specifies when new synchronization should be started, either now, or at some specific time (e.g., at midnight). This time is used to specify the synchronization task file name.

 

Calculation interval defines the synchronization time domain. The end time is always limited to the max. latest synchronized time. The start time is either a configured start time or a specified time.

 

Delete Old Values – if checked, the old values in re-synchronization interval are deleted, but this setting may also change the re-synchronization interval for the scheduled entities in the target storage. If the old values must be deleted in a file-based storage, the export files are overwritten completely from their starting time. If the old values must be deleted from a database storage, the rows in the time range specified are simply deleted from the database tables.

 

Task Filter – an optional filter to specify tasks which should be re-synchronized.

 

Storage Filter – an option filter to specify storages which should be re-synchronized. Both filters must be true for tasks re-synchronization.

 

Once user clicks on the “Ok” button, a new task appears in the list in the "Main task management" form. However, a new task is not created until the “Apply” button in the "Main configuration" form is activated. The same concept is used for editing or deleting of the existing re-synchronization tasks. First, delete or modify task, then click on the “Apply” button.

Synchronization Task File Format

As was mentioned in the previous sections, a text file is used to describe a re-synchronization task. This allows users to create such file using the 3rd party tools and just place it to the correct folder to activate it. The format of this file is relatively simple – a set of key-value pairs where the key-value is delimited by the equals sign and value pairs are delimited by a semicolon.

 

Begin=20220403T22-00-00;End=20220404T22-00-00;DeleteOldValues=False;DataStorageNameFilter="";TaskNameFilter="";

 

Once a file is created, it can be stored in the Synchronization tasks directory. The name of a file must follow the following format which codes the task execution time:

 

"yyyy''MM''dd'T'HH'-'mm'-'ss".txt

 

An example of a created task file name:

 

20220406T13-04-53.txt