Multitenancy is a core requirement for SaaS applications running on SAP BTP. The SAP Cloud Application Programming Model (CAP) provides built-in features to develop scalable, tenant-aware systems with isolated data and centralized application logic.
This guide explains how multitenancy works in CAP, how tenants are provisioned, and how data containers are created dynamically.
What Is Multitenancy in CAP?
Multitenancy allows a single CAP application to serve multiple customers (tenants) while isolating:
- Data
- Configurations
- Authorization policies
- Service bindings
With CAP, the application code is shared, but each tenant gets its own:
- HDI schema
- Database container
- Service instance bindings
This makes CAP ideal for enterprise SaaS offerings on BTP.
How CAP Enables Multitenancy
CAP relies on SAP BTP services to implement multitenancy:
- SaaS Provisioning Service (for onboarding/offboarding tenants)
- XSUAA (for authentication & tenant isolation)
- HDI containers (for tenant-specific schemas)
- Service Manager (automated resource provisioning)
The CAP runtime automatically:
- Detects tenant context
- Routes requests
- Applies tenant-specific database bindings
- Ensures isolated persistence
Enabling Multitenancy in CAP
Step 1: Enable Multitenancy in package.json
{
"cds": {
"requires": {
"multitenancy": true
}
}
}
Step 2: Use SaaS Provisioning Service in package.json
"cds": {
"requires": {
"saas-registry": {
"kind": "saas-registry"
}
}
}
This activates SaaS onboarding/offboarding APIs.
Step 3: Bootstrap CAP with Multitenancy
const cds = require('@sap/cds');
cds.on('bootstrap', app => {
// custom logic (optional)
});
module.exports = cds.server;
CAP automatically registers provisioning handlers.
Tenant Provisioning Workflow
Once multitenancy is enabled, SAP BTP handles:
- Tenant subscribes to SaaS app
- CAP receives the
onboardevent - New HDI container is created
- Database artifacts deployed to tenant-specific schema
- Connections and credentials stored in Service Manager
- Tenant is activated
Example Provisioning Handler
module.exports = cds.service.impl(function () {
this.on('tenantProvision', async req => {
console.log('Provisioning tenant:', req.tenant);
});
});
But in most cases, CAP handles provisioning automatically with no custom code required.
Tenant Isolation Using HDI Containers
Each tenant gets a dedicated HDI container:
- Separate tables
- Independent schemas
- Cleaner upgrades
- Full isolation
Example HDI configuration:
"cds": {
"requires": {
"db": {
"kind": "hana",
"multiTenant": true
}
}
}
CAP automatically switches database connections per tenant.
Routing Tenant Requests
CAP distinguishes tenants using:
- JWT tokens
- Subdomain in the URL
- XSUAA issuer claim
Examples:
tenant1.myapp.cfapps.eu10.hana.ondemand.com
tenant2.myapp.cfapps.eu10.hana.ondemand.com
CAP maps the incoming domain → tenant → schema.
Testing Multitenancy Locally
CAP provides a local multitenancy simulator.
Enable it:
cds watch --multi-tenant
Simulate tenants:
cds deploy --to sqlite:tenant1.db
cds deploy --to sqlite:tenant2.db
Switch tenants:
cds serve --tenant tenant1
cds serve --tenant tenant2
Useful for validating routing & service logic.
Deployment on SAP BTP
For deployment, ensure the mta.yaml includes:
- XSUAA
- SaaS Registry
- HDI containers
- Service Manager
Example section:
- name: myapp-saas-registry
type: org.cloudfoundry.managed-service
parameters:
service: saas-registry
service-plan: application
Once deployed:
- Tenants subscribe via BTP cockpit
- CAP provisions resources
- App is ready for use
Custom Logic During Provisioning
You can extend provisioning using CAP events:
subscribeunsubscribeupgrade
Example:
cds.on('subscribe', async req => {
console.log(`Tenant ${req.tenant} subscribed.`);
});
Useful for:
- Creating default master data
- Sending onboarding emails
- Logging events
Handling Tenant-Specific Configurations
You can store tenant-level configuration:
- In the HDI tenant DB
- In a central admin DB
- Via feature toggles
- Remote configuration services
Example query:
const settings = await SELECT.one.from('Config').where({ tenant: req.tenant });
Best Practices
- Keep business logic tenant-agnostic
- Use feature flags to enable tenant-specific functionality
- Avoid hardcoding tenant IDs
- Minimize dependencies between tenants
- Log tenant actions for audit purposes
- Automate DB migrations during upgrades
- Monitor provisioning errors
Conclusion
SAP CAP makes multitenancy development clean, scalable, and enterprise-ready. With built-in provisioning, tenant routing, and automated schema management via HDI containers, you can focus on building robust SaaS applications instead of complex infrastructure.
Whether you’re onboarding hundreds of tenants or customizing tenant-specific features, CAP provides everything needed to run a secure, isolated, multitenant SaaS solution on SAP BTP.
you may be interested in this blog here:-
Don’t Fear the Update: Navigating the Challenges of how to implement sap note
Five Top Technology Investment Drivers for 2024
How many dollars worth of RSU does Salesforce typically offer an MTS (experienced hire) on joining?
Integration cloud system to HANA Cloud Platform using Cloud Connector
WhatsApp us