🧩 Clean Core SaaS Architecture

SAP BTP CAP MTX Multitenant Extensibility & Schema Guide

Complete architectural guide to building multi-tenant SaaS extensions with CAP MTXS: subscriber-specific CDS extensions, automated HDI migrations, and Clean Core namespace governance.

1. The Architecture of CAP MTXS

In modern SAP BTP SaaS applications, enterprise customers demand the ability to customize data models (add custom fields, validation rules, and satellite entities) without compromising the provider's ability to ship continuous updates. The @sap/cds-mtxs framework provides this separation by dynamically compiling subscriber extensions on top of provider base models at runtime.

Architecture Layer Provider Base Application Subscriber Extension Project
Repository & Codebase Main SaaS vendor git repository Isolated subscriber extension package
Database Isolation Standard base tables in template HDI container Dedicated HDI Container provisioned via Service Manager
Field Naming Standard Standard business properties (e.g. amount) Mandatory prefix (e.g. Z_CustomScore, ZZ_TaxCode)
Upgrade Impact Provider pushes new base releases freely MTXS recompiles extension automatically against new base

2. Enforcing Clean Core Namespace Governance

To prevent subscriber extensions from colliding with future product updates, configure strict prefix validation in the MTXS sidecar's package.json:

"cds.xt.ExtensibilityService": {
  "element-prefix": ["Z_", "ZZ_"],
  "extension-allow-list": [
    { "for": "sap.procure.PurchaseOrders" }
  ]
}

3. The Dynamic Schema Migration Lifecycle

When the SaaS provider releases version 2.0 of a data model, hundreds or thousands of customer database containers must be migrated without service interruption:

  1. Build Base Artifacts: Run cds build --production to generate updated CSN schemas.
  2. Concurrency Gating: Run cds-mtx upgrade --concurrency 10. MTXS queries the SAP Service Manager for all active tenant bindings and executes schema DDL in parallel batches of 10 containers.
  3. Extension Recompilation: For tenants with custom extensions, MTXS merges the tenant's ext.cds with the new base model. If a conflict occurs, that specific tenant is flagged for remediation while others proceed normally.
💡 Sidecar Isolation Pattern Always deploy CAP MTXS as a standalone sidecar microservice (app-mtx) rather than embedding it inside the main user-facing server. This ensures that heavy schema compilation jobs never starve CPU resources from active customer HTTP transactions.

4. Interactive Tool Companion

Use our free web utility to generate CAP MTXS package configurations, subscriber extension templates, and automated tenant upgrade scripts:

→ Open SAP CAP MTX Extensibility Project Builder (Tool #78)

Scale Your Enterprise Multi-Tenant SaaS Solutions

Discover complete production blueprints, automated subscriber migration harnesses, and multi-tenant security frameworks in our flagship books.