It still exists, unchanged in principle: process-app-level configuration stays in the workflow tools; the CR only configures the platform.
- Environment variables: defaults live in the process app (Studio); per Workflow Server they are overridden in Process Admin (.../baw/<instance>/ProcessAdmin > Installed Apps > app > snapshot > Environment variables) exactly as before. Scripted: the Operations REST PUT /ops/std/bpm/containers/{acronym}/versions/{snapshot}/env_vars.
- EPVs: Process Admin > Manage EPVs, or PUT /ops/std/bpm/containers/{acronym}/versions/{snapshot}/epvs.
- Servers (REST, web service, ECM, database) of a process app: defined in Studio per app with a value per environment type (Development / Test / Staging / Production) and overridden per Workflow Server in Process Admin > Installed Apps > app > Servers; passwords are stored encrypted in the BAW database, not in Kubernetes secrets.
- Team bindings: Process Admin > Installed Apps > app > Teams, or the Operations REST team binding resources.
# CI/CD: set environment variables of a snapshot on the target server after install
curl -sk -X PUT "https://cpd.../baw/bawins1/ops/std/bpm/containers/CLM/versions/2.3/env_vars" \
-H "Authorization: ZenApiKey $KEY" -H "BPMCSRFToken: $TOKEN" -H "Content-Type: application/json" \
-d '{"env_vars": [{"name": "crmBaseUrl", "value": "https://crm.example.com/api"}, {"name": "batchSize", "value": "200"}]}'
# copy env vars / EPVs / teams from the previous snapshot to the new one in one call
POST .../ops/std/bpm/containers/CLM/versions/2.3/env_vars/sync?source_version=2.2What does move to the platform: database connections of the engine (CR), LDAP (CR), TLS trust (CR trusted_certificate_list), and Liberty resources such as JMS connection factories or mail sessions that scripts look up by JNDI (custom Liberty config secret). Keep app configuration in the app; keep platform configuration in the CR - mixing them makes promotion between environments painful.
References