Removed ProtocolData model and added NetworkDeployment model (see below)
Rewrote NetworkProtocol handler API (see below)
Rewrote LoraServer NetworkProtocol handler to match new API.
Change networkSettings type from string to object in the REST API.
Add networkSettings to the network model. This enables users to configure necessary IDs, such as organizationID.
The key for encrypting network authentication credentials used to be randomly generated and stored in the DB, one key per network. I changed it to be one secret for all networks, passed in as an environment variable.
Add error tracing code to the model library, so that if a model method throws, the error is automatically extended with the model+method and arguments. Can be disabled within the method.
Add JSON Schemas and validation for the networkSettings object of ApplicationNetworkTypeLink, DeviceNetworkTypeLink, and DeviceProfile.
Previously, Applications could be enabled and ApplicationNetworkTypeLink could not. To disable an ApplicationNetworkTypeLink, you would delete it. I changed it so that Applications cannot be enabled/disabled, but ApplicationNetworkTypeLinks can be, and don't need to be deleted.
Added upsert method to models whose records can be created by pulling a network. This decreases the amount of pull-network business logic.
Added meta object to the network model. There was meta around authentication being stored in the securityData object. I wanted to separate that out to avoid passing around securityData unnecessarily, and also making it easier to update meta, without having to encrypt it.
Updated tests so that all tests are passing.
Changed flow of data for HTTP uplinks (#347)
Network Deployments
I removed ProtocolData, which was essentially a key/value store for remote network IDs, and I added a NetworkDeployment model, which tracks the meta and sync state for records deployed to networks. One NetworkDeployment record can be used for any type of record that is deployed. The NetworkDeployment currently tracks the remoteID, sync status, sync errors, and whether or not the the network is the origin of the record. Along with the updates, LPWAN Server will no longer delete records on the network from which they originated. All the hooks are in place to create/update/delete NetworkDeployments as needed when other records change. This is a first pass of NetworkDeployments, so while the model would support a scheduler that would attempt to re-deploy failed deployments, it doesn't work that way yet. An operation such as updating an Application will succeed even if the deployment fails. One of the goals of implementing NetworkDeployments was to make LPWAN Server operations less dependent on deployments. The error is available in the NetworkDeployment record. The front-end should be enhanced to display NetworkDeployment info and notify the user on failures.
NetworkProtocol Handler API
I moved a lot of business logic common to all NetworkProtocol handlers into the NetworkProtcol model. I reduced the amount of methods in a handler and made the methods smaller in scope (#347 ). Handler methods no longer have access to the models. They receive all the data that they might need, and return all results to the NetworkProtocol model, which then calls other model methods. This makes for a grossly simpler NetworkProtocol handler, and will make it easier to add NetworkProtocols in the future. The methods are generally CRUD methods for Applications, DeviceProfiles, and Devices.
NetworkProtocol handlers now extend the EventEmitter class, so a handler is now also an event bus between the handler and the NetworkProtocol model. This enables the handler to use any strategy for receiving uplinks, and then notify the app. This was previously supported by the handler having access to the models, and calling model methods. So that all uplink flows are the same, I updated the HTTP handler for uplinks to pass the uplink directly to the NetworkProtocol handler.
Do you have any concerns with this PR?
This PR gives the v2 release a good foundation. There's still a lot of work to be done, but NetworkDeployments are in place, and all tests are passing. The front-end will need a lot of updates.
How can the reviewer verify this PR?
Read. Run tests.
Any background context you want to provide?
Screenshots or logs (if appropriate)
Questions:
Have you connected this PR to the issue it resolves? #322
Does the documentation need an update? Yes, but will do as a whole prior to v2 release
Does this add new dependencies? No
Have you added unit or functional tests for this PR? Updated
What does this PR do?
networkSettingstype from string to object in the REST API.networkSettingsto the network model. This enables users to configure necessary IDs, such as organizationID.networkSettingsobject of ApplicationNetworkTypeLink, DeviceNetworkTypeLink, and DeviceProfile.upsertmethod to models whose records can be created by pulling a network. This decreases the amount of pull-network business logic.metaobject to the network model. There was meta around authentication being stored in thesecurityDataobject. I wanted to separate that out to avoid passing aroundsecurityDataunnecessarily, and also making it easier to update meta, without having to encrypt it.Network Deployments
I removed ProtocolData, which was essentially a key/value store for remote network IDs, and I added a NetworkDeployment model, which tracks the meta and sync state for records deployed to networks. One NetworkDeployment record can be used for any type of record that is deployed. The NetworkDeployment currently tracks the remoteID, sync status, sync errors, and whether or not the the network is the origin of the record. Along with the updates, LPWAN Server will no longer delete records on the network from which they originated. All the hooks are in place to create/update/delete NetworkDeployments as needed when other records change. This is a first pass of NetworkDeployments, so while the model would support a scheduler that would attempt to re-deploy failed deployments, it doesn't work that way yet. An operation such as updating an Application will succeed even if the deployment fails. One of the goals of implementing NetworkDeployments was to make LPWAN Server operations less dependent on deployments. The error is available in the NetworkDeployment record. The front-end should be enhanced to display NetworkDeployment info and notify the user on failures.
NetworkProtocol Handler API
I moved a lot of business logic common to all NetworkProtocol handlers into the NetworkProtcol model. I reduced the amount of methods in a handler and made the methods smaller in scope (#347 ). Handler methods no longer have access to the models. They receive all the data that they might need, and return all results to the NetworkProtocol model, which then calls other model methods. This makes for a grossly simpler NetworkProtocol handler, and will make it easier to add NetworkProtocols in the future. The methods are generally CRUD methods for Applications, DeviceProfiles, and Devices.
NetworkProtocol handlers now extend the EventEmitter class, so a handler is now also an event bus between the handler and the NetworkProtocol model. This enables the handler to use any strategy for receiving uplinks, and then notify the app. This was previously supported by the handler having access to the models, and calling model methods. So that all uplink flows are the same, I updated the HTTP handler for uplinks to pass the uplink directly to the NetworkProtocol handler.
Do you have any concerns with this PR?
This PR gives the v2 release a good foundation. There's still a lot of work to be done, but NetworkDeployments are in place, and all tests are passing. The front-end will need a lot of updates.
How can the reviewer verify this PR?
Read. Run tests.
Any background context you want to provide?
Screenshots or logs (if appropriate)
Questions: