A new tenant, end to end

What this is about

A new customer means four things to the platform, and they come into being in four different places:

There is no shared transaction across all four. So CIAS records every step on its own, which is what makes a half-finished customer recognizable and repairable.

The whole path in one picture

The normal case: a platform administrator creates the tenant, CDMS and CIAS run in the same process, and the data layer is set to MULTI.

sequenceDiagram
    autonumber
    participant A as Admin
    participant C as CIAS
    participant CDB as CIAS database
    participant P as CDMS persistence
    participant TDB as Tenant DB
    participant K as Keycloak
    participant U as Client of nordbau

    A->>C: POST /cias/admin/tenants {key: nordbau, type: STATIC}
    C->>C: check the caller's role
    C->>CDB: transaction 1 – key free? store as PENDING / IN_PROGRESS
    CDB-->>C: stored
    C->>P: provision nordbau
    P->>TDB: CREATE DATABASE nordbau
    P->>TDB: bring the schema up to the models
    TDB-->>P: done
    P-->>C: provisioned
    C->>CDB: transaction 2 – PROVISIONED, then ACTIVE
    C-->>A: 200 with the tenant

    Note over A,K: now the people get access
    A->>C: create or invite a person, grant roles
    C->>K: account, membership, roles
    C->>CDB: user record

    Note over U,TDB: the first request
    U->>C: POST /api/rest/crm/customer/query + token
    C->>C: check the token, resolve the tenant
    C->>C: is nordbau served?
    C->>U: answer from the tenant DB

Three things about this shape are deliberate:

1. Store the intention first. If the process dies afterwards, at least something recognizable is there: a tenant in IN_PROGRESS with a start time.
2. Provision without an open transaction. Creating and migrating a database can take a while. Inside a transaction, CIAS would hold a connection and its locks for that long.
3. Store the outcome afterwards, success as well as failure, each in its own short transaction.

The stations up to the first request

The last three stations run on every request, not only the first. Details under The tenant check in both operating modes.

The variants

Where the database comes from

Which database an access hits and when it is created is under Databases, pools, migration and Databases and schemas.

The states along the way

If everything succeeds, the tenant is immediately active; you only see PENDING while provisioning runs or after it failed. The full lifecycle is under The lifecycle of a tenant, the creation itself under Create and provision a tenant.

If the process dies between the two transactions, the tenant stays in IN_PROGRESS, and the retry accepts only FAILED. There is a timer for that, which marks abandoned provisionings FAILED after a deadline. It comes with the starter and is off there by default; the standalone CIAS service switches it on.

From the tenant to the first request

A created tenant is not enough. A person’s request has to name this tenant, and where it does that from depends on the tenant’s type:

After that the path is the same for both: the filter chain resolves the tenant, the tenant gate asks CIAS whether it is served and remembers the answer briefly. Only then does the request reach CDMS. The whole path is under From login to the data.

Watch out

Next

• Create and provision a tenant and The lifecycle of a tenant
• Tenant, organization, group and Static and dynamic tenants
• Self-registration and What happens on completion
• Databases and schemas and Cold start of an installation
• The tenant check in both operating modes