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.
Showing artifacts, examples and content with confirmed Node.js applicability. View All CAP
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.
A Node.js coverage assessment has not been written. View all flavors
Answers the dead-letter side: the dead-message queues named in its configuration are consumed and acknowledged, and their messages can be requeued one at a time or a whole queue at once.
A Node.js coverage assessment has not been written. View all flavors
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