CodamAIDocs
Themafertig

Der Weg einer Anfrage durch die Schichten

Filterkette, REST-Layer, System-Layer, Persistenz, Commit: was jede Station prüft, was sie entscheidet und mit welchem Fehler sie abbricht. Getrennt für Lese- und Schreibvorgänge.

Ausprägungen
LesevorgangAnlegenÄndern und Löschen (mit Sichtbarkeitsprüfung)SuchenErfolg: Commit vor der AntwortFehler: RollbackAbbruch an jeder Station

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

Eine Anfrage von außen nach innen
  1. CIAS
    Filterkette
    Token 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)
  2. CDMS
    REST-Layer
    Ist der Request lesbar? Welche Felder verlangt response? Dateien aus Multipart oder Base64 übernehmen.
    ↳ nein 400 (Request fehlerhaft, response fehlt)
  3. CDMS
    System-Layer
    Hat 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)
  4. CDMS
    Persistenz
    Welche 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)
  5. CDMS
    Commit
    Alles geklappt? Dann Transaktion festschreiben, bevor die Antwort geschrieben wird.
    ↳ nein Rollback, 409 bei einem Konflikt, 503 wenn die Datenbank nicht erreichbar ist, sonst 500
  6. Antwort mit data und meta, die Änderung ist dauerhaft gespeichert

Wer was weiß

Jede Schicht kennt nur ihren Teil. Das macht sie austauschbar und testbar.

StationModulkenntkennt nicht
Filterkettecias-authenticationToken, Person, Mandant, RollenModelle, Daten
REST-Layercdms-rest-apiPfade, Payloads, FeldauswahlDatenbank
System-Layercdms-system-layer, cdms-authorizationFachregeln, Rechte, Beziehungen, HooksSQL, Datenbankwahl
Persistenzcdms-persistence-databaseDatenbanken, Tabellen, SQLHTTP, Payloads
Dateien (optional)cdms-localfs-storageAblagepfade, Bytesalles 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

Vier Arten von Anfragen

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

  1. 1
    Client→CDMS
    schickt die Änderung mit der id des Objekts
  2. 2
    CDMS
    prüft zuerst, ob die Zeile für diese Person sichtbar ist, mit denselben Filtern wie beim Lesen
    Nicht sichtbar → 404. So reicht es nicht, eine fremde id zu kennen, um fremde Daten zu ändern.
  3. 3
    CDMS→Database
    lädt das vollständige Objekt
  4. 4
    CDMS
    prüft die Rolle, überträgt die Änderung, führt Hooks aus, validiert
  5. 5
    CDMS→Database
    speichert, liest zurück (bei DELETE entfällt das Zurücklesen)
  6. 6
    CDMS→Client
    committet und antwortet

Ergebnis: Man kann nur ändern oder löschen, was man auch lesen kann.

Wann: POST /query

  1. 1
    Client→CDMS
    schickt response und parameter (Filter, Sortierung, Seite)
  2. 2
    CDMS
    löst die Feldauswahl auf, prüft die Leserolle
  3. 3
    CDMS
    legt den Filter des Clients zusammen mit den Sicherheitsfiltern in eine gemeinsame UND-Klammer
    So kann kein Filter des Clients die Sicherheitsfilter aushebeln, auch kein OR.
  4. 4
    CDMS→Database
    zählt die Treffer (für totalCount) und liest die angeforderte Seite
  5. 5
    Hook
    After-Hook (READ) für jedes geladene Objekt, bevor es in die Liste kommt
  6. 6
    CDMS→Client
    antwortet mit data (Liste) und meta (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.

Ende einer Anfrage
Alle Stationen erfolgreich?Commit erfolgreich?Ergebnis
jajaAntwort 2xx, die Änderung ist dauerhaft. Eine direkt folgende Anfrage sieht sie schon.
janeinRollback. 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

FrageStation
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

Fallen

Quellen im Code und in der Wissensdatenbank
  • CIAS/cias-authentication – JwtSessionFilter
  • CDMS/cdms-rest-api – AbstractRestApi, Expander, CdmsExceptionMapper, RequestTransactionCommitter
  • CDMS/cdms-system-layer – AbstractSystemLayer (createObject, readObject, updateObject, patchObject), AbstractLayer (recursivePrepare, assertVisibleForWrite)
  • CDMS/cdms-authorization – AbstractAuthorizationLayer
  • commons-persistence – DatabaseRequestContext
  • documentation/10-cdms-grundlagen/01-schichten-und-request-flow.md, 30-daten-und-persistenz/02-transaktionen.md
Suchen