Die Beteiligten einer Anfrage

Worum es geht

Wenn du in einer CodamAI-Anwendung auf „Kunden anzeigen“ klickst, sind viele Programme beteiligt. Jedes hat genau eine Aufgabe. Diese Seite zeigt sie alle auf einem Bild und sagt, wer mit wem spricht.

Die Beteiligten und ihre Farben

Jeder Beteiligte hat auf allen Seiten dieselbe Farbe. Das ist die Legende für die Bilder unten:

1

Benutzer
der Mensch vor dem Bildschirm
2

Browser
zeigt die Seiten und hält das verschlüsselte Sitzungs-Cookie. Ruft CDMS und CIAS nie selbst auf
3

Frontend
die Web-Anwendung (Nuxt), z. B. die Hub-Oberfläche, das CDMS-Portal oder das CIAS-Portal
4

BFF
der Server-Teil des Frontends. Er hält die Tokens und ruft CDMS und CIAS auf
5

Keycloak
der Identity Provider. Zeigt die Login-Seite, prüft das Passwort, stellt Tokens aus
6

CIAS
Identität und Zugang. Seine Filterkette prüft jede Anfrage, seine Module verwalten Benutzer, Mandanten, Rollen
7

CDMS
die Anwendung mit den Daten, z. B. das Hub-Backend oder deine eigene CDMS-Anwendung
8

Datenbank
System-Datenbank, Mandanten-Datenbanken, im getrennten Betrieb auch die Datenbank von CIAS
9

Dateispeicher
Verzeichnis oder Volume für Dateiinhalte, nur bei Anwendungen mit Datei-Modellen
10

E-Mail
Mails, die CIAS verschickt, etwa zur Bestätigung einer Registrierung

Ein paar Wörter dazu:

BFF heißt Backend for Frontend. Jedes Frontend hat einen eigenen kleinen Server. Nur er kennt die Tokens, der Browser hat bloß ein verschlüsseltes Cookie. Details unter Sitzung im BFF und Cookies.
Ein Token ist ein signierter Ausweis, den Keycloak nach der Anmeldung ausstellt. Der BFF schickt es bei jedem Aufruf im Header Authorization: Bearer … mit.
Die Filterkette ist Code von CIAS, der vor jedem Endpunkt läuft. Sie prüft das Token und legt fest, in welchem Mandanten die Anfrage läuft. Details unter Was bei jeder Anfrage mit dem Token passiert.
Ein Mandant ist ein Kunde, dessen Daten von allen anderen getrennt sind. Jeder Mandant kann eine eigene Datenbank haben, siehe Welche Datenbank? Das Persistenzziel.

Das Architekturbild

CDMS und CIAS laufen entweder eingebettet in einem Programm oder getrennt als zwei Dienste. Die Beteiligten sind dieselben, nur die Pfeile zwischen CDMS und CIAS ändern sich. Beide Bilder nebeneinander:

Wer spricht mit wem?

EingebettetGetrennt

Wann: CDMS und CIAS laufen im selben Prozess, so wie im Hub-Backend.

flowchart LR
    U(["Benutzer"]) --> B["Browser"]
    B -- "Seiten, Sitzungs-Cookie" --> F["Frontend mit BFF"]
    B -. "Login-Seite" .-> K["Keycloak"]
    F -- "Tokens holen, erneuern" --> K
    subgraph P["Backend: ein Prozess"]
        FK["Filterkette (CIAS)"]
        C["CDMS"]
        CI["CIAS-Module"]
        FK --> C
        FK --> CI
        C <-->|Methodenaufruf| CI
    end
    F -- "Bearer-Token<br/>/api/rest/… und /cias/…" --> FK
    FK -- "Schlüssel, Token-Tausch" --> K
    CI -- "Konten, Rollen, Gruppen<br/>(Adapter)" --> K
    C --> SDB[("System-DB<br/>mit CIAS-Tabellen")]
    CI --> SDB
    C --> TDB[("Mandanten-DBs")]
    C --> FS[("Dateispeicher")]
    CI -.-> M["E-Mail"]
    classDef user fill:#0f766e,stroke:#0f766e,color:#fff
    classDef client fill:#475569,stroke:#475569,color:#fff
    classDef cdms fill:#1976d2,stroke:#1976d2,color:#fff
    classDef cias fill:#8e24aa,stroke:#8e24aa,color:#fff
    classDef idp fill:#c2410c,stroke:#c2410c,color:#fff
    classDef db fill:#4d7c0f,stroke:#4d7c0f,color:#fff
    classDef mail fill:#be185d,stroke:#be185d,color:#fff
    class U,B user
    class F client
    class C cdms
    class FK,CI cias
    class K idp
    class SDB,TDB,FS db
    class M mail

Ergebnis: Ein Backend-Prozess. CDMS und CIAS reden per Methodenaufruf, die CIAS-Tabellen liegen in der System-Datenbank.

Wann: CIAS läuft als eigener Dienst (cias-runtime).

flowchart LR
    U(["Benutzer"]) --> B["Browser"]
    B -- "Seiten, Sitzungs-Cookie" --> F["Frontend mit BFF"]
    B -. "Login-Seite" .-> K["Keycloak"]
    F -- "Tokens holen, erneuern" --> K
    subgraph D1["Dienst 1"]
        FK["Filterkette (CIAS)"]
        C["CDMS"]
        FK --> C
    end
    subgraph D2["Dienst 2: cias-runtime"]
        CI["CIAS-Module"]
    end
    F -- "Bearer-Token<br/>/api/rest/…" --> FK
    F -- "Bearer-Token<br/>/cias/…" --> CI
    FK -- "Mandant bedient? Attribute?<br/>(Dienstkonto, HTTP)" --> CI
    CI -- "GET /cias/fetch<br/>(Rollen, Attribute)" --> C
    FK -- "Schlüssel, Token-Tausch" --> K
    CI -- "Konten, Rollen, Gruppen<br/>(Adapter)" --> K
    C --> SDB[("System-DB")]
    C --> TDB[("Mandanten-DBs")]
    C --> FS[("Dateispeicher")]
    CI --> CDB[("CIAS-DB")]
    CI -.-> M["E-Mail"]
    classDef user fill:#0f766e,stroke:#0f766e,color:#fff
    classDef client fill:#475569,stroke:#475569,color:#fff
    classDef cdms fill:#1976d2,stroke:#1976d2,color:#fff
    classDef cias fill:#8e24aa,stroke:#8e24aa,color:#fff
    classDef idp fill:#c2410c,stroke:#c2410c,color:#fff
    classDef db fill:#4d7c0f,stroke:#4d7c0f,color:#fff
    classDef mail fill:#be185d,stroke:#be185d,color:#fff
    class U,B user
    class F client
    class C cdms
    class FK,CI cias
    class K idp
    class SDB,TDB,FS,CDB db
    class M mail

Ergebnis: Zwei Dienste. CDMS fragt CIAS per HTTP, CIAS hat eine eigene Datenbank. Die Filterkette läuft trotzdem im CDMS-Dienst.

Der Unterschied liegt nur zwischen CDMS und CIAS. Browser, BFF, Keycloak und die Datenbanken von CDMS sehen in beiden Bildern gleich aus. Alle Unterschiede im Detail stehen unter Eingebettet und getrennt im Vergleich.

Wer spricht mit wem?

Von	An	Wie	Wofür
Browser	Frontend	HTTP mit Sitzungs-Cookie	Seiten laden, Aktionen auslösen
Browser	Keycloak	Weiterleitung	Login-Seite anzeigen, Passwort eingeben, abmelden
BFF	Keycloak	HTTP	Tokens nach dem Login abholen, Access-Token erneuern
BFF	CDMS	HTTP, `Authorization: Bearer …`	Daten lesen und schreiben unter `/api/rest/…`
BFF	CIAS	HTTP, `Authorization: Bearer …`	Verwaltung unter `/cias/…`: Benutzer, Mandanten, Rollen, Registrierung
Filterkette	Keycloak	HTTP	Schlüssel zum Prüfen der Signatur, Token-Tausch
CIAS	Keycloak	HTTP, über den Adapter	Konten anlegen, Rollen und Gruppen schreiben
CDMS	CIAS	eingebettet: Methodenaufruf. Getrennt: HTTP mit eigenem Dienstkonto	Darf der Mandant bedient werden? Welche Attribute gelten?
CIAS	CDMS	eingebettet: im selben Prozess. Getrennt: HTTP `GET /cias/fetch`	Welche Rollen und Attribute meldet die Anwendung an?
CDMS	Datenbanken	JDBC	System-Datenbank und eine Datenbank je Mandant
CDMS	Dateispeicher	Dateisystem	Inhalte von Datei-Modellen
CIAS	Datenbank	JDBC	eingebettet: Tabellen in der System-Datenbank. Getrennt: eigene CIAS-Datenbank
CIAS	E-Mail	Mailserver	Bestätigung, Einladung, Link zum Passwort-Setzen

Welche Frontends es gibt und zu welchem Modul sie gehören, zeigt Die CodamAI-Module. Für dieses Bild sind sie alle gleich gebaut: Nuxt mit eigenem BFF, Anmeldung über Keycloak.

Eine Anfrage in Schritten

So wandert „Liste der Kunden“ durch die Beteiligten. Der Benutzer ist schon angemeldet.

GET der Kundenliste, vom Klick bis zur Datenbank

1

Benutzer→Browser
klickt auf „Kunden“
2

Browser→BFF
ruft eine Route des eigenen Frontends auf, das Sitzungs-Cookie geht mit
3

BFF
entschlüsselt das Cookie und nimmt das Access-Token heraus. Ist es abgelaufen, holt er bei Keycloak ein neues
4

BFF→CDMS
schickt POST /api/rest/crm/customer/query mit Authorization: Bearer …
5

Filterkette
prüft das Token, bestimmt den Mandanten und fragt, ob er bedient werden darf
6

CDMS
prüft, ob eine Rolle im Token das Modell lesen darf
7

CDMS→Mandanten-DB
liest nur die Zeilen, die diese Person sehen darf
8

CDMS→BFF
antwortet mit data und meta
9

BFF→Browser
gibt die Daten an die Seite weiter

Ergebnis: Die Liste erscheint. Weder Browser noch Seite haben CDMS direkt aufgerufen

Was an jeder Station schiefgehen kann und welche Antwort dann kommt, steht unter Was bei jeder Anfrage mit dem Token passiert und Der Weg einer Anfrage durch die Schichten.

Fallen

Weiter

Die CodamAI-Module: welche Repositories hinter den Beteiligten stehen
Die wichtigsten Begriffe in Bildern
Wer entscheidet was?
Anmelden im Browser und Token-Tausch
Wird der Mandant bedient?