diff --git a/guides/multitenancy/index.md b/guides/multitenancy/index.md index 1e23ec6f7..d386e72e5 100644 --- a/guides/multitenancy/index.md +++ b/guides/multitenancy/index.md @@ -316,7 +316,7 @@ In a first terminal, start the MTX sidecar process: [cds] - serving cds.xt.JobsService { path: '/-/cds/jobs' } ``` - In addition, we can see a `t0` tenant being deployed, which is used by the MTX services for book-keeping tasks. + In addition, we can see a [`t0` tenant]./mtxs#about-technical-tenant-t0) being deployed, which is used by the MTX services for book-keeping tasks. ```log [cds] - loaded model from 1 file(s): @@ -894,7 +894,7 @@ To help ensure that the generated SAP HANA tenant UUID is unique within a region like `prefix-${org}-${space}` in Cloud Foundry. :::warning Prefix is mandatory -The cds/requires/cds.xt.DeploymentService/hdi/create/hana_tenant_prefix configuration is mandatory to ensure that the internal tenant `t0` is created with its own SAP HANA tenant. +The cds/requires/cds.xt.DeploymentService/hdi/create/hana_tenant_prefix configuration is mandatory to ensure that the internal tenant [`t0`](./mtxs#about-technical-tenant-t0) is created with its own SAP HANA tenant. ::: :::warning Length restriction @@ -952,8 +952,8 @@ To group the tenant containers of many applications or microservices in a common } } ``` - The `hana_tenant_id` must be a valid UUID and must be unique per subscriber tenant. Specifying `hana_tenant_id` overrides the prefix settings mentioned earlier, - except for the internal tenant `t0`. Also ensure that the ID is unique within a region. + The `hana_tenant_id` must be a valid UUID and must be unique per subscriber tenant. Specifying `hana_tenant_id` overrides the prefix settings mentioned earlier, + except for [the internal tenant t0](./mtxs#about-technical-tenant-t0). Also ensure that the ID is unique within a region. : **... in CAP Java** diff --git a/guides/multitenancy/mtxs.md b/guides/multitenancy/mtxs.md index f7c9ce043..61dff7e99 100644 --- a/guides/multitenancy/mtxs.md +++ b/guides/multitenancy/mtxs.md @@ -1597,6 +1597,53 @@ The job and task status can take on the values `QUEUED`, `RUNNING`, `FINISHED` a +## About technical Tenant `t0` + +`t0` is a technical tenant used by `@sap/cds-mtxs`. It is a dedicated database container that stores operational metadata. The application's domain model is **not** deployed to `t0`. + +#### What `t0` stores + +| Entity | Purpose | +|--------|---------| +| `cds.xt.Tenants` | Registry of all subscribed tenants with their metadata, schema info, and version | +| `cds.xt.Jobs` | Async job state for operations like `subscribe`, `upgrade`, `extend` | +| `cds.xt.Tasks` | Individual tasks within a job (one per tenant per operation) | + + +#### Lifecycle of `t0` + +The `t0` tenant is automatically created or updated at startup of the MTX sidecar. + +##### Schema evolution + +Each startup checks if `t0` needs redeployment. If the schema is up-to-date, no action is taken. + +##### Special constraints for `t0` + +- Never uses `hana_tenant_id` from subscription parameters for [SAP HANA TMS v2](./index#sap-hana-tms-v2) +- Never applies `dataEncryption` +- Never applies the application's `cdsc` compiler options + + +#### Configuring a different Tenant Name for `t0` + +The default tenant name is `'t0'`. It can be customized via configuration cds/requires/multitenancy/t0 or environment variable `CDS_REQUIRES_MULTITENANCY_T0=my-custom-t0`. + +This is useful for scenarios where the `'t0'` name must vary per deployment (e.g., when multiple apps share the same Service Manager instance and need distinct `t0` containers). + +#### Default `database_id` and `lazyT0` + +By default, `t0` is created on server startup without an explicit `database_id`. This means it uses the Service Manager's default (primary) HANA database associated with the service instance or the database that is configured for the cds/requires/cds.xt.DeploymentService/hdi/create/database_id + +[Learn more about DeploymentService configuration.](./mtxs.md#deployment-config){.learn-more} + +##### `lazyT0` configuration + +The creation of the `t0` tenant can be deferred using configuration cds/requires/cds.xt.DeploymentService/lazyT0. + +With that, the `t0` tenant is only created together with the first subscription. Before the first tenant is subscribed, `t0` is created with the same onboarding parameters (including `database_id`) as the subscribing tenant. This can be useful if the `database_id` is not known when deploying the MTX sidecar. + + ## [Old MTX Reference](old-mtx-apis) {.toc-redirect} [See Reference docs for former 'old' MTX Services.](old-mtx-apis){.learn-more}