The delayed response pattern couples a BPD (BPMN, human-centric) with a BPEL process (BAW Advanced / WPS, system-centric) asynchronously: the BPD calls the BPEL process and continues (or waits at an event) instead of blocking a thread until the long-running BPEL work is done; the BPEL process later sends the result back as an event that the BPD receives.
- The BPD invokes an Advanced Integration Service (AIS) implemented by the BPEL process; the AIS is declared asynchronous (the call returns immediately with an acknowledgement / correlation id).
- The BPD reaches an intermediate message event (or a receive task) that waits for the reply, correlated by the instance id or a business key.
- When the BPEL process finishes, it sends the response: either the AIS response message routed by BPM's SCA binding back to the waiting event, or an explicit event message to a UCA (<eventmsg> XML on the event queue) that the intermediate message event consumes.
- The BPD continues with the result; timeouts are handled by a timer boundary on the waiting event (escalate if no reply in N hours).
BPD: [Submit order] -> (AIS "Fulfil order", async) -> ( wait: intermediate message event "Order fulfilled", correlation = tw.local.orderId )
\-> timer boundary 24h -> [Escalate]
BPEL: receive(order) -> invoke ERP -> invoke logistics -> reply / send "OrderFulfilled" event {orderId, status}Why: BPEL work may take hours (waiting for other systems), and a synchronous call would hold BPM threads and fail on timeouts; the delayed response keeps the human process responsive and restart-safe (both sides are persisted). Without BAW Advanced the same pattern is built with any long-running system: call REST / MQ, wait at a message event, receive a UCA-triggered event (questions 2741, 2573).
References