You can, with a caveat about where values are set. Environment variables and EPVs defined in a toolkit are inherited by every process app that depends on it, and their values per environment are set on each installed app in Process Admin (or through the Operations REST), not on the toolkit - the toolkit only carries the definition and the defaults.
- Good use: the names and defaults of company-wide settings (smtpFrom, crmBaseUrl, retryCount, feature flags), plus the helper services that read them (a "Get configuration" service that merges env vars, EPVs and a database table). Every app gets consistent names without redefining them.
- Caveat: because values are per installed app, promoting an app to production still needs the values to be set (or copied from the previous snapshot with the sync operations); the toolkit does not push them. Document the required values in the toolkit and automate the copy in the pipeline.
- EPVs are better than environment variables for values business users change at run time (limits, thresholds) - they are versioned with effective dates and editable in Process Admin without a redeploy; environment variables suit technical settings that differ per environment (hosts, folders).
- Servers (REST / web service / ECM definitions) can also live in the toolkit and are overridden per environment in the same way.
// helper in the global toolkit: configuration with precedence database > EPV > env var > default
function getConfig(name, defaultValue) {
var v = null;
try { v = tw.epv.GlobalSettings[name]; } catch (e) {}
if (v == null || v == "") v = tw.env[name];
if (v == null || v == "" || v == "undefined") v = defaultValue;
return v;
}
tw.local.retryCount = parseInt(getConfig("retryCount", "3"), 10);References