10 · Qualitätsanforderungen¶
Die in Kapitel 1 genannten Qualitätsziele werden hier konkretisiert: zunächst als Qualitätsbaum, der zeigt, wie die Architektur jedes Ziel unterstützt, dann als messbare Szenarien.
Nicht-funktionale Anforderungen aus dem Datennutzungsgesetz – insbesondere Verfügbarkeit, Maschinenlesbarkeit und Barrierefreiheit des Portals – listet die Seite Nicht-funktionale Anforderungen (DNG).
Qualitätsbaum¶
| Qualitätsmerkmal | Teilmerkmal | Bedeutung für die ODI | Wie die Architektur es unterstützt |
|---|---|---|---|
| Datenqualität | Korrektheit | Datensätze im Katalog entsprechen ihrem deklarierten Schema | Frictionless-Validierung vor jeder Veröffentlichung; kein Datensatz ohne gültige Prüfung |
| Datenqualität | Vollständigkeit | Pflichtmetadaten sind vorhanden | Metadaten-Validierung beim Upload; DCAT-AP-Pflichtfelder werden geprüft |
| Interoperabilität | Standardkonformität | Drittportale können Datensätze direkt einbinden | DCAT-AP-Metadaten, OGC WFS/WMS, SensorThings API, SPARQL 1.1 |
| Interoperabilität | Formatvielfalt | Daten sind in mehreren maschinenlesbaren Formaten verfügbar | Automatische Erzeugung von CSV, TDR, Parquet, JSON, RDF je Datensatz |
| Nachvollziehbarkeit | Revisionssicherheit | Veröffentlichungen sind nachweisbar | Unveränderliche datasetId; Keycloak-JWT mit Berechtigungs-Claims; Loki-Logging |
| Betreibbarkeit | Deploybarkeit | Neue Versionen kommen automatisch in den Cluster | GitOps (FluxCD), Image-Automation; Stage-Umgebung als Preproduktionstest |
| Betreibbarkeit | Beobachtbarkeit | Fehler und Engpässe sind schnell erkennbar | Grafana-Dashboards, Loki-Logging, VictoriaMetrics-Metriken |
| Erweiterbarkeit | Austauschbarkeit | Katalog-Technologie oder neue Ausgabeformate können ergänzt werden | CKAN-Service als Fassade; capability-basierte Microservices |
| Sicherheit | Authentifizierung | Nur berechtigte Stellen können Daten veröffentlichen | Keycloak mit OIDC/JWT; Client-Credentials-Flow für Fachverfahren |
| Sicherheit | Autorisierung | Berechtigungen sind feingranular und nachvollziehbar | Permissions-Claims im JWT statt grober Rollen |
Qualitätsszenarien¶
Szenario 1 – Gültiger CSV-Upload¶
Auslöser: Ein Fachverfahren sendet POST /upload/csv mit einem JWT und einer CSV-Datei, deren Inhalt dem angegebenen Frictionless-Schema entspricht.
Erwartetes Systemverhalten: Das Staging-Backend prüft das JWT (< 1 s), lädt das Schema aus dem Schema-Repository (< 2 s) und übergibt die Datei an das Frictionless-Backend zur Validierung. Nach erfolgreicher Validierung wird der Datensatz angelegt, alle Repräsentationen (CSV, TDR, Parquet, JSON) erzeugt und veröffentlicht. Der Aufrufer erhält 201 Created mit datasetId und datasetUrl. Der Gesamtablauf dauert für einen mittleren Datensatz (einige tausend Zeilen) typischerweise weniger als 30 Sekunden.
Szenario 2 – Validierungsfehler schützt den Katalog¶
Auslöser: Eine CSV-Datei enthält in einer Spalte, die laut Schema den Typ number haben soll, Textwerte.
Erwartetes Systemverhalten: Das Frictionless-Backend meldet den Typfehler mit Zeilen- und Spaltenangabe. Das Staging-Backend gibt 422 Unprocessable Entity mit einer strukturierten Fehlerliste zurück. Im Datenkatalog wird kein Datensatz angelegt; der Systemzustand bleibt unverändert.
Szenario 3 – Neues Service-Image wird automatisch deployed¶
Auslöser: Ein Entwickler pusht einen Bugfix auf main im Repository odi-staging-backend.
Erwartetes Systemverhalten: GitLab CI baut das neue Docker-Image mit Kaniko und pusht es in die Stage-Registry. Flux erkennt das neue Image beim nächsten Scan (maximal 5 Minuten), schreibt den Tag ins Manifest und startet ein Rolling-Update im Cluster. Nach spätestens 15 Minuten laufen die Pods mit dem neuen Image – ohne manuellen Eingriff.
Szenario 4 – Katalog-Technologie wird ausgetauscht¶
Auslöser: Die Entscheidung fällt, vom aktuellen CKAN auf Piveau als Datenkatalog zu wechseln.
Erwartetes Systemverhalten: Nur der odi-ckan-service (Adapter/Fassade) muss durch einen äquivalenten odi-piveau-service ersetzt werden. Das Staging-Backend, das Frictionless-Backend und alle anderen Dienste erfordern keine Code-Änderungen. Der Wechsel ist auf einen Dienst begrenzt.
Szenario 5 – Keycloak temporär nicht erreichbar¶
Auslöser: Der Keycloak-Pod im keycloak-Namespace ist für 2 Minuten nicht erreichbar (z. B. Rolling-Update).
Erwartetes Systemverhalten: Lesende Endpunkte (Datensatz-Download, Katalog-Abfrage, SPARQL, WFS/WMS) bleiben vollständig verfügbar – sie prüfen keine JWTs. Schreibende Endpunkte (Upload, Schema-Anlage) geben 503 Service Unavailable zurück, bis Keycloak wieder antwortet. Nach Wiederherstellung von Keycloak funktionieren alle Endpunkte ohne Neustart der anderen Dienste.