Straight-through processing (STP) means a transaction runs from start to end without human intervention - every step is a system interaction (validate, enrich, call back ends, decide with rules, update, notify), and humans only see the exceptions that fall out. Payments, order confirmations, policy renewals and claims below a threshold are typical.
Why BPEL (BAW Advanced / WPS) fits STP better than a BPD:
- Transactions and compensation: BPEL scopes can be transactional (short-running microflows run in one unit of work) and support compensation handlers to undo completed steps when a later one fails - a BPD has no compensation.
- Throughput: microflows run in memory without persisting after each step; BPDs persist the execution context at every activity (designed for human waits), which costs a database write per step.
- Typed, WSDL-based interfaces: BPEL is built on SCA / WSDL / XSD, integrating naturally with adapters, JMS and web services; correlation sets, event handlers and fault handling are first-class.
- Parallelism and dynamic loops (flow, forEach) map to system work; timers and waits exist for the long-running variants.
Why not only BPEL: the moment a person is needed (exception handling, approvals), BPDs give you tasks, teams, portal, coaches and the business-readable model. The classic split is: BPD orchestrates the business case and handles the exception paths; BPEL / mediation modules do the STP core, invoked as Advanced Integration Services (synchronous for microflows, delayed response for long-running - question 1025). On CP4BA (no BPEL) the STP core moves to App Connect Enterprise flows or to service flows with idempotent REST steps, and the BPD stays the exception handler.
References