BTP & Integrationadvanced

BTP CAP Part 4: Multitenancy, Extensibility and Production Deployment

Key takeaway

Build SaaS with CAP: multitenancy with the MTX services (@sap/cds-mtxs), tenant subscription via SaaS registry, tenant-specific HDI containers, tenant-aware caching, extensibility for customers, and production deployment practices (MTA, profiles, CI/CD).

Explanation

📌 KEY POINTS
✅ cds add multitenancy adds MTX services that handle tenant subscription, upgrade and database containers.
✅ Each subscriber tenant gets its own HDI container; requests run in the tenant's context.
✅ The SaaS provisioning service (SaaS registry) triggers subscribe/unsubscribe callbacks.
✅ Extensibility lets customers add fields/entities per tenant (when enabled).
⚠️ Global in-memory caches shared across tenants can leak data between customers — cache per tenant.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 3 secured services. Now SaaS and production.

━━━━━━━━━━━━━━━━━━━━
▶ 1. MULTITENANCY

MTX sidecar, tenant containers.

━━━━━━━━━━━━━━━━━━━━
▶ 2. SUBSCRIPTION

SaaS registry; approuter per tenant URL.

━━━━━━━━━━━━━━━━━━━━
▶ 3. TENANT ISOLATION

Data, caching, logging with tenant IDs.

━━━━━━━━━━━━━━━━━━━━
▶ 4. EXTENSIBILITY

Tenant-specific extensions, feature toggles.

━━━━━━━━━━━━━━━━━━━━
▶ 5. PRODUCTION

MTA, profiles, CI/CD, upgrades of all tenants.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

cds add multitenancy.
Deploy and subscribe from a consumer subaccount.
Verify separate tenant containers.

✅ CHECKPOINT: two tenants never see each other's data.

Code example

ABAP Code

===== ENABLE =====cds add multitenancy     # adds @sap/cds-mtxs, sidecar, SaaS registry resources in mta.yamlmbt build && cf deploy mta_archives/*.mtarConsumer subaccount → Subscribe to app → callback → tenant HDI container created ===== TENANT-AWARE CACHE (Node.js) =====const key = `${cds.context.tenant}:${code}`   // never a global key===== UPGRADE =====Deploy new version → MTX upgrades tenant containers (e.g. upgrade job / API)

Real project scenario

A SaaS app cached reference data globally; one customer's custom values appeared for another. Switching to tenant-scoped cache keys and adding tests with two tenants fixed the leak.

Common mistakes

Global caches.
Skipping tenant upgrades.
No tenant in logs.
Testing with one tenant.
Extensions without governance.

Best practices

Tenant-scoped caches.
Automated tenant upgrades.
Tenant IDs in logs.
Multi-tenant tests.
Govern extensions.

Interview angle

Questions: "How does CAP multitenancy work?", "How is tenant data isolated?", "How do you upgrade tenants?"
Strong answer: MTX, subscription, isolation, extensibility, production practices.

Practice this lesson

Quick check

1. Where does each subscriber tenant's data live in a multitenant CAP app on HANA Cloud?

2. Which CAP feature/package provides multitenancy and SaaS extensibility capabilities such as tenant-specific model extensions and subscription handling?

3. A multitenant CAP app cached reference data globally and one customer saw another's values. What fixes it?

Interview questions

1. When designing a new multitenant SaaS application using the SAP Cloud Application Programming Model (CAP), what are the key architectural and operational considerations beyond just the technical implementation of multitenancy to ensure the application is secure, scalable, and maintainable?

Answer it in your own words first, then compare.

2. You are turning a CAP app into a multitenant SaaS offering. What do you design?