Implement Asset Types for configuration

[pankalog]

To allow different parameter ID lists for different device models, we require to create a new Asset Type that can contain the configuration data for each device type. That would include a list of TeltonikaParameters, maybe some other metadata, etc. We also need to insert a default configuration on handler creation if it does not exist.

We would also need a general configuration asset type, for setting default model number, and any other parameter data we would require.

[pankalog]

To differentiate between data types, I thought of having device-specific configuration assets as children of the main configuration asset. To read the correct asset type when a message comes in, request all of the parents of the configuration asset, and then use the required ModelNumber attribute for finding the correct device configuration.

This would also be the correct place to implement a device whitelist, which will be used to kick subscribing clients with IMEIs that are not in the whitelist.

[pankalog]

Update, current situation

Okay so, since writing this issue:

TeltonikaMasterConfigurationAsset and TeltonikaModelConfigurationAsset have been created, implementing the functionality above.

The way the assets were first used was that, on handler startup, check if assets exist and create TeltonikaConfiguration object, if not, create the assets and then try again.

When the configuration was needed, I had a function called getConfig() that just re-fetches the assets on every single call.

I happened to run the profiler on my local instance with a device connected to it and the calls to fetch those assets were just ripping through the performance of this, with 10+ calls for each payload that arrives.

No more

I created a gigantic update for the asset configuration.

Specifically, I managed to cram 3.5 design patterns on it; Singleton, Builder, Factory, and a semi-okay observer.

To reduce the amount of calls to the backend without reducing the amount of times we access the configuration, I created a singleton pattern. If I need the instance, there is only one of it.

To then make sure that I stay up to date with the actual configuration, I update the configuration every minute (an adjustable value in code, to be converted to environment variables).

If the user edits any configuration, I refresh the instance manually.

Results

I re-ran the profiler and did some tests. I timed the period from the moment I receive the payload in onPublish to the point where I've already merged/sent off the AttributeEvents.

LUDICROUSLY fast.

The worst measurement I've seen is 14ms.