Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

To read more about the topic, visit the next page: Server and service configuration.

The server configurations are stored in two locations in the system: in a the central database that allows to manage and review them via the user interface; and in every server’s registry that allows the local services to read them. The current configuration values can be retrieved from both locations. A server configuration change in both approaches require the following steps:

...

Basically, the values stored in the central database

...

and the registry should not be different, but after a server installation or a manual registry change, there can be differences

...

. Before configuring the server, the differences must be eliminated by using the configurationDifferences endpoint. When the central database value is chosen as the proper value, then one or more configuration tasks will be generated that indicates the required changes in the registry.

A server configuration change requires the following steps:

Step 1: Change the configurations in the central database. The changes don’t have a direct effect on the behavior of services after this change. Such changes are not considered as a difference between the registry and the central database, but a configuration task is generated instead, and the changes can be pushed to the servers' registry by executing this task.

Step 2: When the configuration tasks have been created for every server, these tasks have to must be applied to each server. After applying the tasks, the new configuration values has been will be pushed to the local registry, and the services will reread the new values and started will start to work based on the new valuesconfiguration.

The configuration passwords are stored in an encrypted format in the central database and the registry too. Contrary to the other entities the passwords are handled in a different way in the server configuration-related endpoints. Numerous integrations require a connection string in a complex format instead of dedicated configuration values. These connection strings contain the passwords in an encrypted format with unencrypted configuration values separated with separator characters in one configuration value. Based on that at the backend side, automatic password encryption is not possible. Due to that, the passwords have to be encrypted by the client with the usage of the dedicated password encryption endpoint.

...