Worum es geht
Jede Anfrage an CDMS durchläuft dieselben Stationen, immer in derselben Reihenfolge. Jede Station hat genau eine Aufgabe und darf die Anfrage abbrechen. Wer die Stationen kennt, weiß bei jedem Fehler sofort, wo er entstanden ist.
Die Stationen
-
CIASFilterketteToken gültig? Welche Person, welcher Mandant? Wird der Mandant bedient? Ist ein Kontextwechsel erlaubt?↳ nein 401 (kein gültiges Token auf geschütztem Pfad) · 403 (Mandant nicht bedient oder nicht bestimmbar)
-
CDMSREST-LayerIst der Request lesbar? Welche Felder verlangt
response? Dateien aus Multipart oder Base64 übernehmen.↳ nein 400 (Request fehlerhaft,responsefehlt) -
CDMSSystem-LayerHat die Person die Rolle? Ist die Zeile für sie sichtbar? Sind alle Felder gültig? Hooks ausführen, Beziehungen mitschreiben.↳ nein 403 (Rolle fehlt) · 404 (nicht sichtbar) · 422 (ungültig)
-
CDMSPersistenzWelche Datenbank? Nur die sichtbaren Zeilen, nur die angeforderten Spalten. Beim Lesen läuft danach der READ-Hook.↳ nein 400 / 403 (Mandant fehlt oder unzulässig) · 409 (Wert schon vergeben, Objekt noch verwiesen) · 400 (Wert passt nicht in die Spalte) · 503 (Datenbank nicht erreichbar)
-
CDMSCommitAlles geklappt? Dann Transaktion festschreiben, bevor die Antwort geschrieben wird.↳ nein Rollback, 409 bei einem Konflikt, 503 wenn die Datenbank nicht erreichbar ist, sonst 500
- Antwort mit
dataundmeta, die Änderung ist dauerhaft gespeichert
Wer was weiß
Jede Schicht kennt nur ihren Teil. Das macht sie austauschbar und testbar.
| Station | Modul | kennt | kennt nicht |
|---|---|---|---|
| Filterkette | cias-authentication | Token, Person, Mandant, Rollen | Modelle, Daten |
| REST-Layer | cdms-rest-api | Pfade, Payloads, Feldauswahl | Datenbank |
| System-Layer | cdms-system-layer, cdms-authorization | Fachregeln, Rechte, Beziehungen, Hooks | SQL, Datenbankwahl |
| Persistenz | cdms-persistence-database | Datenbanken, Tabellen, SQL | HTTP, Payloads |
| Dateien (optional) | cdms-localfs-storage | Ablagepfade, Bytes | alles andere |
Das Ergebnis der Filterkette ist der RequestContext: ein Objekt für die Dauer genau dieser Anfrage mit Person, Mandant, erlaubten Mandanten, Rollen und Attributen. Alle späteren Stationen lesen daraus, keine liest selbst das Token.
Die Wege im Einzelnen
Wann: POST /read/{id} oder GET /read/{id}
sequenceDiagram
participant C as Client
participant F as Filterkette (CIAS)
participant R as REST-Layer
participant S as System-Layer
participant P as Persistenz
participant DB as Datenbank
participant H as Hooks
C->>F: POST /read/{id} + Token
F->>F: Token prüfen, RequestContext füllen
F->>R: weiterreichen
R->>R: response auflösen (Felder, Referenzen)
R->>S: readObject(id, Feldauswahl)
S->>S: Leserolle prüfen
S->>S: Sicherheitsfilter anhängen (Besitzer, Attribute)
S->>P: Abfrage
P->>DB: SELECT nur der angeforderten Spalten
DB-->>P: Zeile
P-->>S: Entity
S->>H: After-Hook (READ), z. B. ein Feld entschlüsseln
S->>S: Entity in DTO umwandeln
S->>S: Referenzen einzeln nachladen, je mit eigener Rechteprüfung und eigenem READ-Hook
S-->>R: DTO
R-->>C: data + meta
Ergebnis: Kein Treffer, oder Treffer nicht sichtbar: 404. Der READ-Hook sieht jedes geladene Objekt, bevor es zur Antwort wird.
Wann: POST /create
sequenceDiagram
participant C as Client
participant F as Filterkette (CIAS)
participant R as REST-Layer
participant S as System-Layer
participant H as Hooks
participant P as Persistenz
C->>F: POST /create + Token
F->>R: RequestContext gefüllt
R->>R: Dateien übernehmen, response auflösen
R->>S: createObject(DTO)
S->>S: Rolle prüfen, Felder übertragen,<br/>Defaults setzen, Verstöße sammeln,<br/>Kinder rekursiv anlegen
S->>H: Before-Hooks
S->>S: alle Verstöße auf einmal melden (422)
S->>P: speichern
S->>H: After-Hooks
S->>P: flush, dann zurücklesen (mit READ-Hook)
S-->>R: DTO
R-->>C: data + meta
Ergebnis: Die Hooks laufen vor der Validierung. Ein Hook darf also ein Pflichtfeld füllen, das der Client gar nicht kennt.
Wann: PUT, PATCH, DELETE, Rollback
-
1Client→CDMSschickt die Änderung mit der
iddes Objekts -
2CDMSprüft zuerst, ob die Zeile für diese Person sichtbar ist, mit denselben Filtern wie beim LesenNicht sichtbar → 404. So reicht es nicht, eine fremde
idzu kennen, um fremde Daten zu ändern. -
3CDMS→Databaselädt das vollständige Objekt
-
4CDMSprüft die Rolle, überträgt die Änderung, führt Hooks aus, validiert
-
5CDMS→Databasespeichert, liest zurück (bei
DELETEentfällt das Zurücklesen) -
6CDMS→Clientcommittet und antwortet
Ergebnis: Man kann nur ändern oder löschen, was man auch lesen kann.
Wann: POST /query
-
1Client→CDMSschickt
responseundparameter(Filter, Sortierung, Seite) -
2CDMSlöst die Feldauswahl auf, prüft die Leserolle
-
3CDMSlegt den Filter des Clients zusammen mit den Sicherheitsfiltern in eine gemeinsame UND-KlammerSo kann kein Filter des Clients die Sicherheitsfilter aushebeln, auch kein
OR. -
4CDMS→Databasezählt die Treffer (für
totalCount) und liest die angeforderte Seite -
5HookAfter-Hook (READ) für jedes geladene Objekt, bevor es in die Liste kommt
-
6CDMS→Clientantwortet mit
data(Liste) undmeta(Zahlen)
Ergebnis: Keine Treffer sind kein Fehler: 200 mit leerer Liste.
Wann ist eine Änderung gespeichert?
Die Transaktion umfasst die ganze Anfrage, nicht einzelne Methoden. CDMS schreibt sie an einem festen Punkt fest: direkt bevor die Antwort geschrieben wird.
| Alle Stationen erfolgreich? | Commit erfolgreich? | Ergebnis |
|---|---|---|
| ja | ja | Antwort 2xx, die Änderung ist dauerhaft. Eine direkt folgende Anfrage sieht sie schon. |
| ja | nein | Rollback. 409, wenn eine gleichzeitige Änderung oder die gespeicherten Daten den Commit verhindert haben, 503, wenn die Datenbank nicht erreichbar war, sonst 500 |
| nein | – | Rollback aller Datenbanken, die die Anfrage berührt hat. Die Fehlerantwort beschreibt, woran es lag |
Mehr dazu unter Ein Request, eine Transaktion.
Wo welche Entscheidung fällt
| Frage | Station |
|---|---|
| Wer fragt, für welchen Mandanten? | Filterkette (CIAS) |
| Darf der Mandant überhaupt bedient werden? | Filterkette (CIAS) |
| Welche Felder kommen zurück? | REST-Layer (Auflösung) und Persistenz (Spaltenauswahl) |
| Darf die Person diese Operation auf diesem Modell? | System-Layer, über die Modellrollen |
| Darf die Person diese Zeile sehen oder ändern? | System-Layer, über Owner-Filter und Attributfilter |
| Ist der Inhalt gültig? | System-Layer, über die Validierung |
| In welche Datenbank? | Persistenz, über die Modell-Ebene |
| Wann ist es gespeichert? | Commit am Ende der Anfrage |