Configuration parameters allow projects to be dynamic, flexible, and environment-specific. They enable managing variables and values that change across deployment environments (e.g., Development, QA, Production), without requiring hardcoded updates. This feature is particularly valuable for managing sensitive information, environment-specific settings, and configurations for integrations.
Configuration Parameters are defined per project version or library version, ensuring consistency across builds while allowing for environment-specific overrides. These parameters can be used across various components, such as business rules, UI elements, integration designer, and gateways.
Libraries can define configuration parameters to facilitate testing of processes or workflows that depend on them. However, unlike project-level configuration parameters, libraries do not support direct overrides.
null
or undefined, in which case the configuration parameter is used.To avoid conflicts, use distinct names for process variables and generic parameters whenever possible.
Exception in Business Rules:
In business rules, values are taken directly from the map of configuration parameters without applying the above fallback logic.
For details on configuring runtime overrides, see:
Configuration parameters are defined as key-value pairs and support the following types:
A static value directly used by the project. Suitable for settings that do not change across environments.
Use Cases:
Example:
officeEmail
value
officeEmail@office.com
References an external variable set by the DevOps team. These variables are defined per environment and referenced using a name convention.
Use Cases:
Example:
baseUrl
environment variable
BASE_URL
(name convention pointing to an externally defined value)Configuration details:
Key | Type | Value | Description |
---|---|---|---|
baseUrl | environment variable | BASE_URL | A reference to the base URL configured externally by DevOps. |
Example values for different environments
Environment | External Variable Name | Actual Value |
---|---|---|
Development | BASE_URL | https://dev.example.com/api |
QA | BASE_URL | https://qa.example.com/api |
Production | BASE_URL | https://api.example.com |
Used for sensitive data like passwords, API keys, or credentials. These values are securely managed by DevOps and referenced using a name convention.
Use Cases:
Example:
dbPassword
secret environment variable
DB_PASSWORD
Configuration parameters simplify the management of environment-specific or dynamic settings across multiple project components:
To add a new configuration parameter:
value
, environment variable
, or secret environment variable
.value
: Enter the static value.environment variable
or secret environment variable
: Enter the agreed name convention.ENV
/ENV_SECRET
) are managed by DevOps.processInstanceId
). Avoid using reserved keys for custom configurations.null
or undefined
process variables will default to the corresponding configuration parameter’s value during runtime.When designing processes, ensure that variables in subprocesses and parent processes do not conflict with configuration parameters names. Test these interactions in scenarios where variables are dynamically assigned or left undefined.