Page tree

Versions Compared


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

Table of Contents


Note that in multi-Master Controller environments, the configuration needs only to be updated in the primary Master Controller. The secondary and other Master Controllers will normally receive the configuration by means of synchronisation.

New features in Delft-FEWS Configuration Manager 2017.02

The following changes are new compared to 2017.01( and earlier)

  • Connection to the database via Direct Database Access (DDA) only, also no more SA
  • Import directly into central database, but with temporary “uncommitted” version number and synch level 9
  • No more DefaultConfig database tables required
  • Config indicated with synchLevel 11 will be the default
  • On startup all “uncommitted” config is removed
  • When session from other user is still active a warning is given
  • Removed buttons: "Log in", "Log out", "Download" and "Upload" (these actions are now automated or not required anymore because of DDA)


  • Different ordering of the buttons, more suitable to the order and frequency of use
  • New Button: "Save All" => Give all uncommitted configuration files a new version (instead of uncomitted) and set as default. When this button is pressed, an audit log message is provided as the following: 
    CM.SaveAll: User <user> created a new revision with id <id> with comment <comment>.

Importing new files from root

Select root and click the <Import> button


The import window appears showing all new and changed files


After clicking <OK> all files are imported into the database with a temporary version called "uncommited" and synch level 9 which means they will not be synchronised.


All newly imported files are already marked as default during this session with a yellow highlight, but all changes are temporary and only exist in memory during the config manager session until <Save all> button is pressed.


When clicking <Save all> the user can choose to add a comment to the new revision (or not) and when clicking <yes> a new revision is created and all config changes from that session are made final.

For new files this means they will get a new version and synchLevel 11 and they will be officially part of the active config revision.

Import changed files from root

When there already is an active config revision and an import from root is done, the import dialog will show in the first tab all new and changed files


The missing configurations tab will show the files that where present in the current config revision but not in the new import from root. When selecting "Deactivate missing configuration files" those files will be removed from the current active revision


A changed config file will have a new file listed in the table with version "uncommitted" and synch level 9 which means it is temporary, but it is highlighted in yellow to show that it will be part of the active config revision (currently only in memory).


A deactivated config will not have a higlighted version in the table anymore.

Only until clicking <Save all> a new revision is created and all config changes in memory from the session are made final.


All changes made with the <set active>, <set inactive> and <delete> buttons during the session are also kept in memory and only finalized after pressing <Save all>.

When the user tries to close the config manager and there are changes in memory that are not processed by <Save all> the user gets a message and a question whether het is sure he wants to exit.

Single file changes

Besides changing the config revision by import there are also options to activate, deactivate or delete config file versions. These changes will also be kept in memory and only made final after <Save all> is pressed and a new revision is created.

Set active

When an inactive config file version is selected it can be made active by clicking the <Set Active> button


Afterwards, the activated version will be highlighted in yellow to show it belongs to the new config revision the user is working on. The change however will only be made final after <Save all> is clicked and a new revision is created.

Set Inactive

When an active config file version is selected it can be made inactive by clicking the <Set Inactive> button


Afterwards, the deactivated version will not be highlighted in yellow anymore because it will not belong to the new config revision the user is working on. The change however will only be made final after <Save all> is clicked and a new revision is created.


When an inactive config file version is selected it can be deleted by clicking the <Delete> button


After this the deleted version will not be visible in the table anymore. The change however will only be made final after <Save all> is clicked and a new revision is created.


Deleting older versions needs to be done with care if it will be desired to restore older config revisions later on.

Exiting without "Save all"

When the user made config changes and tries to exit Delft-FEWS without having pressed <Save all> a popup will show with a warning.

Restoring old revision

In the Version Management tab a table with all revisions stored in the database is shown.

When selecting one, the list with all changes between the revision from the dropdown list are shown.

When pressing the restore button all config files belonging to that revision will be considered as active in the session. The user has to click "Save all" and create a new revision to make the changes final.

When the user already made config changes without pressing "Save All" and then clicks the restore button a warning will popup because it causes all current changes to be reverted.

When the user tries to restore a revision which contains a file that has been deleted a warning will popup

If the user clicks yes, the deleted file will be removed from the revision. So after "Save All" has been pressed the old revision is restored but the deleted file is removed from it.


Group By

The Group By button will group module config files by their module when selected.

Below it is seen when the button is not activated, it will use the same directory structure as the files are located on disk

When activated the module config files will be grouped by module (like generalAdapterRun, timeseriesImportRun or transformationModule):


New features in Delft-FEWS Configuration Manager 2018.02

Since 2018.02, the Admin Interface is used to upload the patch.jar used by the Config Manager. Also the user management in the Admin Interface controls which users are allowed to view or edit configuration in the ConfigManager.

Validation button removed since 2020.01

Since the CM already validates the xml with schema on import and the validate button itself has only a very limited outdated of extra checks it is decided that from 2020.01 the validate button will be removed to prevent a false sense of security. A warning is added that the config should be tested in stand alone and after a creating a new config revision users should check the AI to see if the system is still running fine.

Using the ConfigManager for a Master Controller synchronization pool

The ConfigManager will always operate on a single Master Controller database, also in a multi Master Controller environment. When multiple Master Controllers are always kept in synch, in theory it should not matter which Master Controller database the ConfigManager operates on. In practice however, it is best practice to upload new configuration to one and the same Master Controller of the synchronization pool. Most commonly the database where the upload takes place is referred to as the primary Master Controller. Changes uploaded are then automatically shared among the synchronizing Master Controllers that synchronize the uploaded configuration from that central database.


Always upload new configuration to one and the same Master Controller of the synchronization pool. If by mistake the Config Manager was used to upload a single patch.jar to the secondary Master Controller, this can lead to the secondary MC not seeing al the configuration. In such a case it is advised to use the ConfigManager to upload a minor change (e.g. comment) in the primary MC to make all config files visible again to the secondary Master Controller. This will work if only a single patch.jar has been oploaded to the secondary MC and no other config files or actions like "delete inactive config" have been done.

Using the ConfigManager in a non-standard Master Controller synchronization pool

A non-standard Master Controller synchronisation pool  is for instance when there is an external synchronizing Master Controller (for instance in another geography / organization) that is also allowed to synchronize from the primary Master Controller database, but is not synchronizing back. In this case it strongly forbidden to upload configuration in the external Master Controller database. Any subsequent upload into the primary Master Controller could conflict with the externally uploaded configuration.


Never use the ConfigManager to upload configuration to a non-primary Master Controller that is not allowed to synchronize back to its own synchronization pool.

If there has been created such a conflict between configurations, it is normally recommended to remove the conflicting configuration from the external Master Controller using the McRecoveryTool. If for some reason, the external Master Controller is for a short period the primary Master Controller, a temporay measure allowing synchronization back to the central system would indeed prevent the configuration conflicts described above.

F12 config zip upload (since 2020.02)

Since 2020.02 it is possible to upload a new config revision at once from a zip file, this will skip the import review dialog, clicking the save all and adding a revision comment.

Within the zip a directory called "config" should be present.

It will replace the whole config revision without extra GUI steps in between.

It will check whether the file is a zip and whether it contains at least some System, Root and Region config files.

Should not be used while Configuration Manager is open, this will cause conflicts.

Not possible to connect with CM to newer Master Controller's (since 2020.02)

Since the 2020.02 CM it is not possible anymore to connect to newer Master Controllers to prevent possible database corruptions in the future.

Warnings about other version differences remain.