Advanced system settings

Overview

Apart from customer-specific settings the users can configure/modify on UI within appropriate applications the system provides low-level configurations. By customer-specific settings we refer to the Settings menu item in the Applications, see also Global System Settings.

The low-level configurations are available via direct database modification in the following Data Definitions:

Backend Configurations (see PDRDwpConfigurationClass)
Frontend Configurations (see PDRDwpFrontendConfigurationClass)

The initial System and Frontend settings were designed to be a part of SPS.config and config.json accordingly. The new requirement to run the application on a cluster environment forces developers to move SPS.config and config.json to appropriate tables with preserving its original structures. Thus, eliminating the files and creating a single source of the settings guarantees consistency across the nodes while running the application in a cluster. Note, the fallback mechanism is available to ensure system stability: if the setting is missing in the database, the fallback value is getting fetched from the configuration file.

Backend Configurations

SPS.config settings are migrated to PDRDwpConfigurationClass having key-value schema to contain ‘{section}-{attribute}’ in a Key and appropriate value in a Value column. The number of settings and their values remains unchanged and should be treated in a similar way we had them in SPS.config. The application fetches the settings from the database and, if null or empty, tries to get it from SPS.config.

Both Matrix42.Setup.exe and cmdlets write the values to the PDRDwpConfigurationClass rather than config.json. Thus, config.json remains unchanged while installing or upgrading the product.

See a sample of migrated settings below:

MicrosoftTeams-image (6).png

Frontend Configurations

Config.json settings are migrated to PDRDwpFrontendConfigurationClass having key-value schema to contain ‘{json path}’ in a Key and appropriate value in a Value column (see brief explanation below).

Consider the following object (i.e. dataSource from config.json).

To generate the json path and keep it stored in a key-value table, it has been transformed and represented as shown below:

"dataSource": { 
    "pageSize": 50, 
    "pageSizes": [ 
      10, 
      20, 
      50, 
      100, 
      200 
    ], 
    "showHiddenValuesInSearch": true 
  }

Key	Value	Type
dataSource.pageSize	50	Number
dataSource.pageSizes	[10,20,50,100,200]	Array
dataSource.showHiddenValueInSearch	TRUE	Boolean

We must treat it as parent.child... until getting to the end of the object. Going through the entries from the PDRDwpFrontendConfigurationClass, the application generates the final json document and shares it via {domain}/m42Services/api/wmconfig anonymous API endpoint. The front-end overrides existing config.json with the JSON obtained from the provided API (if prod mode is configured in config.josn). To prioritize config.json, the dev mode must be set.

Both Matrix42.Setup.exe and cmdlets write the values to the PDRDwpFrontendConfigurationClass rather than config.json. Thus, config.json remains unchanged while installing or upgrading the product.

See a sample of migrated settings below:

MicrosoftTeams-image (7).png