General changes from 0.x to 1.0

Last updated 5 months ago

Was this helpful?

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

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

The previous distinction between service commissioning file and device commissioning file has been removed. Both files are replaced by one single 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 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 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 and .
If not all resources inside a service are available or working properly, a 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 . 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 into the Connectware
When writing commissioning files with multiple entries, several helper functions exist to avoid code duplications in the resources’ : 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 , 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 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

Last updated 5 months ago

Was this helpful?

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

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

The previous distinction between service commissioning file and device commissioning file has been removed. Both files are replaced by one single 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 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 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 and .
If not all resources inside a service are available or working properly, a 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 . 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 into the Connectware
When writing commissioning files with multiple entries, several helper functions exist to avoid code duplications in the resources’ : 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 , 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 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: