Multitenancy
Serving many tenants from one deployment — onboarding, tenant-isolated data, per-tenant schema deployment and the operational tooling around it. It is decided once, before anything is built, and narrows the artifacts in almost every capability downstream: most sharply in cachingCachingHolding the result of an expensive read so the next one is cheap. This spans four different things people call caching — HTTP response caching, query result caching, remote service response caching, and application-level memoisation. They are not interchangeable, and picking the wrong one is the usual cause of stale-data bugs in multitenant apps.SAP and community, unassessed and anything else holding state in process.
Showing artifacts, examples and content with confirmed Java applicability. View All CAP
Overview
Exposes SUBSCRIBE, UNSUBSCRIBE and DEPENDENCIES tenant lifecycle events and by default creates or deletes a tenant-specific database container through the Service Manager; CDS model data for tenant extensions is fetched from the Node.js MTX sidecar rather than handled here.
Carries the tenant in the Request Context across every service call and thread, and opens tenant-specific database connections from it. Provisioning and subscription are cds-feature-mt.
A Java coverage assessment has not been written. View all flavors
No community artifact is confirmed here for Java.
A Java coverage assessment has not been written. View all flavors
Artifacts
Details
Coverage
For your agent
- Ref
capability:multitenancy- JSON
- /capabilities/multitenancy.json
- MCP
- Connecting an agent