Local storage process
On this page you will find information about the local storage process, a new feature available from the version 1.1.0 of the TelemetryMonitor.
Introduction
The telemetry events generated by each company application are sent periodically by a background process to the company server, in order to give information of the applications usage by the clients.
In some sceneries (no internet connection, telemetry API endpoint unavailability, premature closure of the application, and others) the telemetry events can't be uploaded to the server and all this data would get lost. So, this new process tries to avoid that data loss.
The new process
This new approach for the telemetry events update process consist in the addition of a local storage composed by a SQLite database where the telemetry events generated by the applications will be stored instead of the current queue managed on memory.
The SQLite database file will be created in the user AppData/Roaming/Mobilize.Net folder with the name of "telemetry.sqlite". No need to install third party software to manage this database file.
The following diagram represents the new process added to the telemetry events update process:
The process will be started automatically with the Controller class instantiation (available on Controller version 4.1.2 and above).
A background process will be started and will validate the telemetry events stored on the SQLite database, creating groups of events related by the corresponding session id, this groups will be sent through the telemetry API endpoint defined on the bundle that has instantiated the Controller. Each register on the SQLite database have a status property that allows it to know if the register has been sent or not, in order to execute the corresponding retries when it is needed or execute the maintenance process that will delete all the registers that has been sent or definitely have not been sent (maximum retries reached).
All the telemetry events will be stored in the SQLite database first, and later they will be sent to the telemetry API, in order to avoid the data loss.
Note: If by some reason the local storage process cannot be initialized, the previous telemetry events update process will be started instead. acting as a backup.
Last updated
