Constants
A section with constants can be defined in each configuration. A section such as this is primarily used to maintain the configuration values, which are adapted on a project-specific basis, in a central location in standardized configuration templates.
Each constant definition consists of a name/value pair. The name serves as a placeholder in the syntax %ConstantName% (i.e., it is embedded in percent signs). This placeholder can be used elsewhere in the configuration data to insert the value of the constant at this point. When it comes to merely replacing text, the constant is used. Text replacement takes place at program start before the content of the configuration data is interpreted. A constant can therefore be used for the complete value of a property or for a partial value, as long as the value as a whole corresponds to the syntactic specifications after the constant has been replaced.
Constants can be defined in global configurations as well as in scenario configurations. For a block of constants, you can specify whether these constants are only valid for a specific tenant. Thus, constants with the same name can be defined for different tenants with specific values. At runtime, the tenant-specific values of these constants are used depending on the execution context (i.e., depending on the tenant for which a processing scenario is executed).
Special Considerations regarding JSON Format
The value of a constant is always specified as the type "String." In JSON format, string values must always be distinguished with quotation marks, yielding different results in JSON format configuration, depending on the target value.
Target value | Example |
|---|---|
String value | The notation of a constant for the database server would be When using the constant, make sure that the placeholder is embedded in quotes again. An example of correct embedding would be |
Boolean value | If the target value is of the data type "Boolean," the quotes around the placeholder could theoretically be omitted. For example, when enabling logging to the Windows Event Viewer, the configuration key would be notated In practice, however, for the configuration data to be read in at all, it must already be in valid JSON syntax before the constants are substituted. For syntax to qualify as valid, the placeholder of the constant must be specified as a string (i.e., Once the constants have been substituted, the Boolean value is also embedded in quotes. Since the program knows the target data type, it can interpret the string value correctly and implicitly convert it to a Boolean value. |
List of multiple values | In some cases, it will be necessary to list multiple values within a constant (e.g., to define the authorization of users for a web-service call). For example, a configuration key may be Note that the outer quotation marks before |
Dependencies
The following dependencies apply to constants defined in a global configuration:
Without tenant reference: the constants can be used in the global configurations and in all scenario configurations.
With tenant reference: the constants can be used in all scenario configurations that are executed in the context of that tenant.
The following dependencies apply to constants defined in a scenario configuration:
Without reference to tenant: the constants can only be used in just this scenario configuration, but independent of the tenant for which the scenario is executed.
With reference to tenant: the constants can only be used in just this scenario configuration and only if the scenario is executed in the context of this tenant.
Notice
In the case of same-name constants that are defined multiple times, the more specific constants have priority. Constants that are defined in a scenario configuration thus have priority over globally defined constants.
Tenant-specific constants always have priority over tenant-independent constants, regardless of whether they are defined in a global or a scenario configuration.