Environment variables live on the server; a coach view runs in the browser, so the value has to be handed over. Three ways, from cleanest to quickest:
- Configuration option: the CSHS reads tw.env.myVar in a server-side step (a service flow called at the start of the CSHS, since client-side scripts have no tw.env) into tw.local.config, and the coach view gets it through a configuration option bound to that variable - the view reads this.context.options.baseUrl.get("value"). Reusable and testable.
- Coach-level variable: same, but the coach view reads page data through a hidden control or its binding (this.context.binding.get("value") when bound to tw.local.config).
- Ajax service from the view: a service flow with no input that returns the environment variables the UI may see (never secrets), called by a Service Call or the view's Service option at load; cached in a global for other views.
// service flow "Get UI config" (server side): whitelist what the browser may know
tw.local.config = new tw.object.UiConfig();
tw.local.config.reportUrl = tw.env.reportUrl;
tw.local.config.maxUploadMb = parseInt(tw.env.maxUploadMb, 10);
// CSHS: first step calls it; coach view "Uploader" has an option maxUploadMb bound to tw.local.config.maxUploadMb
// coach view load handler:
var max = this.context.options.maxUploadMb.get("value") || 10;Do not try tw.env in client-side scripts or coach view code - it is undefined there (the classic symptom is "tw.env is not defined" in the browser console). Keep secrets (passwords, API keys) on the server: pass only what the UI needs. On CP4BA the mechanism is identical; only the values are set per Workflow Server in Process Admin.
References