Workflow Center is the Process Center in a container - the repository model is identical: process apps and toolkits, tracks, snapshots, dependencies, tags, online and offline servers, installation packages. What differs is the registration and the UI entry point:
- Online Workflow Servers in the same CR are registered automatically by the operator (on 21.0.3+ the operator wires Workflow Servers of the same CR to the Workflow Center); servers in other clusters are registered through the Workflow Center console (Servers tab) with the server's route and a technical user / API key, or run as offline servers.
- Offline servers: create the server definition in Workflow Center, export the installation package (.zip) for it, install with the Operations REST (POST /ops/std/bpm/containers/install) or the Workflow Server's Process Admin - the same as before.
- Console: the Workflow Center console (repository, servers, snapshots, tracks, archive) is reachable at its route (.../baw-center/ProcessCenter style path); Studio's Business automations page is the day-to-day list for authors.
- Naming and governance unchanged: snapshot acronyms, tags, "default snapshot" per server, instance migration policies.
# list servers known to Workflow Center and install a snapshot on one
GET https://<center>/ops/std/bpm/servers/workflow
POST https://<center>/ops/std/bpm/servers/workflow/{serverName}/install?container=CLM&version=2.3
# offline package for a disconnected production server
POST https://<center>/ops/std/bpm/containers/CLM/versions/2.3/offline_package?server=prod-offline -> zipOne organisational change: with namespaces being cheap, many teams run one Workflow Center per landscape (dev cluster) and register test / production Workflow Servers across clusters online, replacing the old offline-package chain - keep offline packages for air-gapped production only.
References