An external implementation is a BPD activity whose work is done by an external application instead of a human service or a system service. BPM creates the task, marks it as "external" and waits; the external application discovers the task through the REST API, does the work in its own UI / logic and completes it with the output data. It is the mechanism behind custom portals and "headless" task UIs (Angular / React apps, mobile apps, SharePoint).
- In Process Designer, add an External Activity artifact (library > User Interface > External Activity) with input / output variables and the location of the external UI (a URL, informational).
- Set the BPD activity's implementation to External Implementation and select that artifact; map the variables.
- The external application polls or is notified (task assignment e-mail, Process Portal, or a UCA-driven push), reads the task and completes it:
# task details incl. the external activity data
GET /rest/bpm/wle/v1/task/{taskId}?parts=data,externalActivity
# ... the external app renders its own form with data.data.variables ...
# complete the task with output values
PUT /rest/bpm/wle/v1/task/{taskId}?action=finish¶ms={"decision":"APPROVED","comment":"ok"}
# or claim first: PUT /rest/bpm/wle/v1/task/{taskId}?action=assign&toMe=trueWhen to use it: your organisation already has a task UI framework, tasks must be completed by another system (a CRM screen), or you want the BPD to stay clean of UI technology. When not: normal user tasks - a client-side human service is far less work and gets the portal features (claim, due dates, comments, collaboration) for free.
Related: external services (REST / SOAP / Java integrations) are the opposite direction - BPM calls out; an external implementation is BPM waiting for someone else to call in.
References