Doing work outside the request that triggered it, with a guarantee that it eventually happens — deferred jobs, retries, and periodic work. Distinct from messaging, which is about telling other systems.
@sap/cds Queues a service's calls, inbound messages and scheduled tasks in the cds.outbox.Messages table inside the business transaction, dispatches them after commit, retries with exponential backoff and keeps failures past maxAttempts as a dead letter queue; cds.queued() wraps a service, outboxed: true does it by configuration.
com.sap.cds:cds-services-bom Exposes CAP's transactional event queues as outbox services. The runtime ships two default outboxes, used internally for messaging and for the audit log, and custom outbox services can be registered for further isolation or scaling.
Not covered: At the table. A dead letter stays in cds.outbox.Messages for a person to revive or discard, through a query or a service the application defines; there is no console, no priority and no rate control, and Java has no callbacks yet. That is what the entries here add on top.
Messaging is not automatically mass extraction, but an external broker can cross the boundary named in section 1. The data flow, volume and interoperability purpose therefore need to be checked for the concrete design.
SAP Developer License Agreement 3.2 CAP →The queue's runners coordinate through application-level locking: a picked-up message is marked processing and the row lock is released after selection. @sap/cds 8 did not check the status column, @sap/cds 9 held a row-level lock for the whole processing.
A rolling upgrade straight from @sap/cds 8 to 10, which the guide says can double-process messages; drain the queue or upgrade through 9.
Before this, a tenant's outbox messages were only picked up by a background job that polled across all tenants on a fixed interval, bounding delivery latency by that poll cycle. The default processing strategy changed to trigger asynchronous, per-tenant processing as part of the request that submits the message, rather than a regular sweep over every tenant; the old polling strategy is still available by setting cds.outbox.persistent.scheduler.enabled: false.
Descriptions of outbox delivery as bound by a fixed cross-tenant poll interval — since this release the default path triggers processing from the submitting request instead.
Before this, cds.requires.outbox: true gave an in-memory outbox — events waited in process memory until commit, then sent, with nothing surviving a crash before dispatch. The default flipped to persistent-outbox: messaging services and the audit-logging service now write to a database table before dispatch, and the old in-memory behaviour survives only as an explicit opt-out.
Guidance that says enabling cds.requires.outbox gives an in-memory-only queue, or that database-backed delivery needs its own separate configuration. Since November 2023, outbox: true already means persistent-outbox.
capability:async-processing