Ein neuer Mandant, Ende zu Ende

Worum es geht

Ein neuer Kunde bedeutet für die Plattform vier Dinge, die an vier verschiedenen Orten entstehen:

Eine gemeinsame Transaktion über alle vier gibt es nicht. Deshalb hält CIAS jeden Schritt einzeln fest, damit ein halb fertiger Kunde erkennbar ist und repariert werden kann.

Der ganze Weg in einem Bild

Der Normalfall: ein Plattform-Administrator legt den Mandanten an, CDMS und CIAS laufen im selben Prozess, die Datenhaltung ist auf MULTI eingestellt.

sequenceDiagram
    autonumber
    participant A as Admin
    participant C as CIAS
    participant CDB as CIAS-Datenbank
    participant P as CDMS-Persistenz
    participant TDB as Mandanten-DB
    participant K as Keycloak
    participant U as Client von nordbau

    A->>C: POST /cias/admin/tenants {key: nordbau, type: STATIC}
    C->>C: Rolle des Aufrufers prüfen
    C->>CDB: Transaktion 1 – Schlüssel frei? speichern als PENDING / IN_PROGRESS
    CDB-->>C: gespeichert
    C->>P: richte nordbau ein
    P->>TDB: CREATE DATABASE nordbau
    P->>TDB: Schema auf den Stand der Modelle bringen
    TDB-->>P: fertig
    P-->>C: eingerichtet
    C->>CDB: Transaktion 2 – PROVISIONED, dann ACTIVE
    C-->>A: 200 mit dem Mandanten

    Note over A,K: Jetzt bekommen die Menschen Zugang
    A->>C: Person anlegen oder einladen, Rollen vergeben
    C->>K: Konto, Mitgliedschaft, Rollen
    C->>CDB: Benutzerdatensatz

    Note over U,TDB: Die erste Anfrage
    U->>C: POST /api/rest/crm/customer/query + Token
    C->>C: Token prüfen, Mandant auflösen
    C->>C: Wird nordbau bedient?
    C->>U: Antwort aus der Mandanten-DB

Drei Dinge an dieser Form sind Absicht:

1. Absicht zuerst speichern. Stürzt der Prozess danach ab, ist wenigstens etwas da, das man wiedererkennt: ein Mandant in IN_PROGRESS mit Startzeit.
2. Einrichten ohne offene Transaktion. Eine Datenbank anzulegen und zu migrieren kann dauern. Liefe das in einer Transaktion, hielte CIAS so lange eine Verbindung und ihre Sperren fest.
3. Ergebnis danach speichern, Erfolg wie Misserfolg, jeweils in einer eigenen kurzen Transaktion.

Die Stationen bis zur ersten Anfrage

Die letzten drei Stationen laufen bei jeder Anfrage, nicht nur bei der ersten. Einzelheiten unter Die Mandantenprüfung in beiden Betriebsarten.

Die Varianten

Wo die Datenbank entsteht

Welche Datenbank ein Zugriff trifft und wann sie angelegt wird, steht unter Datenbanken, Pools, Migration und Datenbanken und Schemata.

Die Zustände unterwegs

Gelingt alles, ist der Mandant sofort aktiv; PENDING sieht man nur, solange die Einrichtung läuft oder gescheitert ist. Der ganze Lebenslauf steht unter Der Lebenslauf eines Mandanten, das Anlegen im Einzelnen unter Einen Mandanten anlegen und bereitstellen.

Stirbt der Prozess zwischen den beiden Transaktionen, bleibt der Mandant in IN_PROGRESS stehen, und der Neuversuch nimmt nur FAILED an. Dafür gibt es einen Zeitgeber, der liegengebliebene Einrichtungen nach einer Frist auf FAILED setzt. Er kommt mit dem Starter und ist dort standardmäßig aus; der eigenständige CIAS-Dienst schaltet ihn ein.

Vom Mandanten zur ersten Anfrage

Ein angelegter Mandant reicht nicht. Die Anfrage einer Person muss diesen Mandanten nennen, und woher sie das tut, hängt an der Art des Mandanten:

Danach ist der Weg für beide gleich: Die Filterkette löst den Mandanten auf, das Mandanten-Tor fragt CIAS, ob er bedient wird, und merkt sich die Antwort kurz. Erst dann erreicht die Anfrage CDMS. Der ganze Weg steht unter Vom Login bis zu den Daten.

Fallen

Weiter

• Einen Mandanten anlegen und bereitstellen und Der Lebenslauf eines Mandanten
• Mandant, Organisation, Gruppe und Statische und dynamische Mandanten
• Selbstregistrierung und Was beim Abschluss passiert
• Datenbanken und Schemata und Kaltstart einer Installation
• Die Mandantenprüfung in beiden Betriebsarten