General changes from 0.x to 1.0¶

This section describes the general changes in the Cybus Connectware version 1.0.0 compared to the previous 0.x versions.

Services and resources¶

The most important change is that everything is done in a service and described as resources.

The previous distinction between service commissioning file and device commissioning file has been removed. Both files are replaced by one single commissioning file for services, similar to AWS cloud formation files, still in the well-known yaml file format. This enables “infrastructure as code” on a whole new level.
The new service commissioning file describes the complete system context as a set of resources. Resources can be devices, Docker containers (both customized by the customer or standard containers by Cybus), connections, data transformations, and more.
Describing connections to devices in device commissioning files has been replaced by describing connection resources inside the service commissioning files.

This change enables the following new features:

Service life cycle can be managed and observed explicitly: A service changes states from disabled to enabling to enabled and vice versa.
If not all resources inside a service are available or working properly, a deviation for this service between expected state and actual state is shown and the service is marked as deviated, leading the user directly to the cause of the problem in order to fix it quickly
Resources can reference each other not only within one commissioning file and within one service, but also across different services using the service id. The complete system context can hence be described by one or multiple commissioning files, whatever fits best for the application.
When defining a container resource for the service, parameters such as port mappings can be specified with defaults from the commissioning files, but can also manually be entered when the commissioning file is installed into the Connectware
When writing commissioning files with multiple entries, several helper functions exist to avoid code duplications in the resources’ properties: ref uses the value from somewhere else by reference; sub will substitute values from somewhere else as a string replacement; merge will merge a set of common parameter values with additional given specific values such as concrete addresses.

Each service is displayed in the admin user interface (web interface) with an overview and detail view. In the detail view, the resources that are used within this service are all shown. Every of those resources can be clicked on to jump to the details view of those resources (such as connections, containers, endpoints). Alternatively, for every resource kind there exists an overview list from which one can go to the detail view of that resource, too.
The admin user interface includes an Explorer page which enables browsing through all MQTT topics by topic structure, showing the data as received from the machine endpoints or as prepared by the service mappings to semantic structures, both according to the configuration from the service commissioning file.

Setup of distributed agents is much easier: Distributed systems can be set up very easily every time new machines and data sources should be connected

Upgrading from a previous 0.x version to 1.0.0 is described here: Upgrading from 0.x to 1.0