Device Configuration Service – Basics¶
The Device Configuration Service uses the Deployment Workflow Service to instantiate the configuration update workflow. This sets up a state machine to track the configuration progress and requires the device to send status messages while executing the configuration job. The history of the job status is recorded by the Device Configuration Service.
Required Device Messages¶
For proper progress tracking, it is necessary, that the device sends status messages to the backend. It should send messages in the following cases:
- It has started the configuration job. This triggers the state machine to transition to
CONFIGURING. It may send status updates about the progress of the job.
- It has finished the configuration job. This triggers the state machine to transition to
- The configuration job has failed. This triggers the state machine to transition to
- The configuration job has been canceled, e.g. due to a timeout. This triggers the state machine to transition to
CANCELED. Do not trigger this transition, if an error occurred, as the backend might unnecessarily retry the operation in this case.
Configuration File Management¶
The Device Configuration Service distinguishes configuration files based on their path, which is defined by a unique string. The
/ character can be used to generate paths that imply structural information for human users. However, the Device Configuration Service treats it as a standard character. Thus, it handles the following paths individually:
The Device Configuration Services creates a hash for each revision of a configuration file. The hash is generated using the file's content and can be used for file access. Whenever a configuration file is modified, the Device Configuration Service creates a new hash. Note that it creates the same hash for any two revisions of a configuration file with the same content.
Except where otherwise noted, content on this site is licensed under the Development License Agreement.