Complete guide to designing, deploying, and governing secure multi-tenant SaaS solutions with SAP BTP SaaS Registry, CAP MTXS, isolated HDI containers, and subscriber extensibility.
When software vendors (ISVs) or global enterprises deploy applications on SAP BTP to serve multiple independent customers or decentralized operating entities, multi-tenancy becomes the primary architectural foundation. Under the Clean Core paradigm, multi-tenancy ensures that base applications remain completely upgrade-stable while granting each subscriber isolated data storage and custom extensibility.
| Isolation Model | Data Separation Mechanism | Security & Regulatory Fit | Operational Complexity |
|---|---|---|---|
| Isolated HDI Container (Recommended) | Dedicated SAP HANA Database Container per subscriber via SAP Service Manager | Highest (Banking, Healthcare, GDPR, FIPS 140-3 compliant) | Automated via CAP MTXS lifecycle provisioning |
| Discriminator Column | Single shared database table with TENANT_ID filter injected in CDS layers |
Medium (Potential data-leak vulnerability if SQL bypasses CDS security) | Low database footprint; high manual audit requirement |
| ABAP Cloud Client | Client-dependent database tables (MANDT / @ClientHandling.type: #CLIENT_DEPENDENT) |
High (Standard SAP S/4HANA enterprise client architecture) | Managed natively by the SAP kernel & RAP framework |
A production SAP BTP SaaS application requires three coordinated cloud services:
saas-registry): Registers the multi-tenant application with the SAP BTP landscape, handles subscription events from customer subaccounts, and routes tenant launchpad URLs.service-manager:container): Dynamically provisions, updates, and deletes isolated SAP HANA HDI containers when new customers subscribe or terminate contracts.@sap/cds-mtxs): Provides asynchronous microservice endpoints for tenant onboarding, database migration, tenant model compilation, and customer extension packages.When a tenant administrator clicks Subscribe in their SAP BTP Subaccount, the following orchestration occurs:
PUT callback to the application's SaaS Registry endpoint: /mtx/v1/provisioning/tenants/{tenantId}.Callback scope defined in xs-security.json.https://subscriber-subdomain-app.cfapps.eu10.hana.ondemand.com) to the BTP Cockpit.The CAP MTXS framework allows subscribers to add custom fields and custom entities to the standard SaaS solution without touching provider code:
// subscriber-extension/db/ext.cds
using { sap.invoice as base } from '@sap/base-invoice-service';
// Extend base business entity with custom enterprise fields
extend entity base.Invoices with {
Z_CustomTaxComplianceCode : String(40);
Z_SustainabilityRating : Decimal(5, 2);
Z_AuditTrailTimestamp : Timestamp;
};package.json (e.g., "element-prefix": ["Z_", "ZZ_"]) to avoid namespace collisions between base SaaS product updates and subscriber extensions.
Use our free web utility to generate production mta.yaml manifests, SaaS subscription lifecycle callbacks, and CAP MTXS package configurations:
→ Open SAP BTP Multi-Tenant SaaS Extension Architect (Tool #69)
Explore end-to-end architectures, automated continuous tenant deployment pipelines, and cross-tenant security hardening in our comprehensive books.