WebSphere environment entries and JVM custom properties are readable from server-side JavaScript through Java, and WebSphere variables (${APP_INSTALL_ROOT} style) through the expansion API - useful for paths and per-node settings that must not live in the process app:
// JVM custom property (Servers > server > Java and Process Management > Process definition > JVM > Custom properties)
var region = String(java.lang.System.getProperty("company.region", "EU"));
// OS environment variable of the JVM process
var home = String(java.lang.System.getenv("BPM_DATA_HOME") || "/data");
// (WebSphere variables of the Environment page are not exposed to scripts - mirror the ones you need as JVM custom properties)// practical: JVM custom property or OS variable is enough for 95% of cases
var dataHome = String(java.lang.System.getProperty("bpm.data.home") || java.lang.System.getenv("BPM_DATA_HOME") || "/data");
tw.local.inboundFolder = dataHome + "/in";
// WebSphere variable expansion (traditional): the server name / node name
var installRoot = String(java.lang.System.getProperty("was.install.root") || "");Which to use for what: BPM environment variables (process app level, per snapshot / server, editable in Process Admin) for application configuration - the intended mechanism; JVM custom properties for per-JVM / per-node technical settings (paths, feature switches for a member) - set once per member, read with System.getProperty; OS variables only when the platform injects them (containers: Kubernetes env from ConfigMaps / Secrets - on CP4BA that is the natural way to pass secrets to Java integrations); WebSphere variables for WebSphere resources (data source paths, library references), rarely needed in process code. On CP4BA there is no WebSphere admin console: JVM properties go into jvm_customize_options of the CR and env vars into the pod spec through the operator's custom settings.
References