IoT Backend Architecture #

The IoT Backend is an application providing the functionality needed for an IoT platform.

It is composed of several modules interacting together.

Device Manager #

The Device Manager is the main module of the IoT Backend. He is responsible for managing digital twins (assets and devices) as well as receiving measurements.

It exposes a set of API controllers used in the IoT management of the platform:

• device-manager/assets: allows you to manipulate assets
• device-manager/devices: used to manipulate devices
• device-manager/models: allows you to manipulate asset and device models
• device-manager/payloads: allows to receive raw data.

It also exposes events internal to the framework in order to modify the operation of the data ingestion pipeline for enrichment or post-processing purposes:

• device-manager:measures:process:before: used to enrich the data before propagation
• device-manager:measures:process:after: used to trigger processing (e.g. alerts, replication, etc)

The Device Manager is accessible through the application instance:

// Everywhere with `app` access
const deviceManager = app.plugin.get<DeviceManagerPlugin>('device-manager');

// In modules
this.deviceManager;

Multi Tenant #

Apart from the Multi-Tenancy module, the modules are not aware of the existence of a multi-tenant operation.

However, they are able to operate in multi-tenant mode with data isolation by index. This isolation of data by data index is also the basis of the Multi-Tenancy module.

The Multi-Tenancy module manages the creation of tenants and their users, when creating a new tenant, it will propagate the request to the other modules so that they initialize the necessary resources (often collections) for their operation on a new data index.

It exposes several controllers in order to manage tenants and users:

• multi-tenancy/tenant: allows to create and modify tenants
• multi-tenancy/users: allows to manipulate tenant users (creation, modification, deletion, profiles, etc)

The Multi-Tenancy module is accessible through the application instance:

// Everywhere with `app` access
const multiTenancy = app.plugin.get<MultiTenancyPlugin>('multi-tenancy');

// In modules
this.multiTenancy;

The tenants operate according to a group system, each tenant belongs to a defined group which will have the resources in line with its use case.

The different groups of tenants must be registered with the Multi-Tenancy module during the development phases.

Soft tenant #

Soft tenant is currently an opt-in extension of multi-tenancy plugin. It does activated by this in kuzzlerc:

{
  "plugins": {
    "multi-tenancy": {
      "softTenant": true
    }
  }
}

It exposes specific controller (multi-tenancy/soft-tenant) to manage the soft-tenant (creation, modification, deletion, ...).

Also this add actions addSoftTenant and removeSoftTenant to the controller multi-tenancy/users to add or remove access to a soft tenant to an user.

Rules Engine #

The Rules Engine allows you to create business rules that run when a framework event is triggered or when a real-time notification is received.

These business rules are defined in the form of a document governing the scheduling of the different steps of the rule. Steps can declare options that can be changed by users at runtime.

In general, a business rule has an action defined on the framework by means of a Task class.

The Rules Engine module is accessible through the application instance:

// Everywhere with `app` access
const workflows = app.plugin.get<WorkflowsPlugin>('workflows');

// In modules
this.workflows;

Dashboard Builder #

The Dashboard Builder allows you to create dashboards that can be used to display data from the IoT platform.

These dashboards are defined in the form of a document that can be modified by users at runtime.

Each dashboard is composed of differents widgets like a graph, a table, a map, etc.

Scheduler #

The Scheduler is to be integrated into the Rules Engine

The Scheduler allows you to define scheduled tasks that will be executed at regular intervals.

These scheduled tasks are defined in the form of a configuration document, they can trigger API actions at regular intervals.

The Scheduler module is accessible through the application instance:

const scheduler = app.plugin.get<SchedulerPlugin>('scheduler');