Process Federation Server (PFS) indexes tasks, instances and launchable items of several workflow systems (BPM / BAW Process Servers, BPEL on BAW Advanced, Case) into one Elasticsearch / OpenSearch index and exposes a federated REST API (/rest/bpm/federated/v1/tasks, /launchableEntities, /systems) plus the federated saved searches. The user sees one task list across systems (Process Portal in federated mode on traditional BAW; Workplace on CP4BA).
Traditional BAW, one Process Server cell: you do not need PFS - the Process Portal talks to its own server. You need it when: users work on tasks from two or more Process Servers (different cells, versions, or BAW + Case), you want one portal over BPEL and BPD tasks, or you want the faster indexed task search for very large task lists (PFS answers from the index, not from the BPMDB).
CP4BA: PFS is always part of the workflow deployment because Workplace only reads through the federated API; the operator deploys the PFS pods and OpenSearch (pfs_configuration, elasticsearch_configuration) and registers every Workflow Server automatically. Sizing the index (retention of completed items, replicas) is a CR setting.
# federated API as used by Workplace / federated portal
GET /rest/bpm/federated/v1/systems -> registered systems, index state
GET /rest/bpm/federated/v1/tasks?size=50&offset=0&sort=DUE:asc
GET /rest/bpm/federated/v1/launchableEntities
Operational notes: PFS indexes with a lag of seconds (a newly created task appears after the next index cycle); an index rebuild is needed after restoring a database; the Elasticsearch / OpenSearch cluster needs its own storage and monitoring; on traditional installs PFS is a separate Liberty server with its own config (server.xml with the federatedSystem elements per Process Server) - the PFS documentation chapter covers the install.
References