–
Architekturebenen
–
Aktive Adapter
–
DOMUS Live-Verbindung
Vier-Ebenen-Architektur
Anfrage-Pfad: Portal → DataHub → Quellsysteme
Adapter & Quellen
Aktive Datenbankverbindungen
Datenschutz
Betrieb mit Live-Daten (Festlegung 2026-06-22). Reale Persistenz im Fakten-Puffer nur per
Jede Schreiboperation erfordert
persist_real (Schutz vor versehentlichen Real-Writes).Jede Schreiboperation erfordert
grund_code (Begründungspflicht) + Audit. Mandanten-Trennung per RLS.
Service-Endpunkte
| Pfad | Methode | Beschreibung | Schreibend |
|---|---|---|---|
/hub/audit | GET | Änderungsprotokoll | – |
/hub/verzeichnis | GET | Art.-30-Verzeichnis (DSGVO) | – |
/hub/reason-codes | GET | Zulässige Änderungsgründe | – |
/hub/status | GET | Hub-Gesundheitszustand | – |
Datenfelder für bereits über Sync bekannte Begriffe lesen und nach
fach.* schreiben (identifiziere → lese_bulk → cache.fakt →
reconcile_bulk). Setzt voraus, dass die hub_refs schon in
hub.id_mapping stehen — dafür ist der Sync-Tab da.
Performance
Batchgröße für
execute_values() beim Schreiben nach
cache.fakt/fach.*. Zu klein (Default 100)
erzeugt bei großen Begriffen viele einzelne DB-Roundtrips (Beispiel:
146000 Zeilen bei page_size=100 → ~45s, bei 5000 → ~8s). Größer
spart weitere Roundtrips, riskiert bei sehr hohen Werten aber
einzelne SQL-Statements mit sehr vielen Werten je Roundtrip.
Datenbefüllung
Identify → Lesen → cache.fakt → fach.*
Pipeline-Status
Noch keine Läufe in dieser Sitzung.
Art. 30 DSGVO — Verarbeitungsverzeichnis
Automatisch generiert aus hub.verarbeitung
Audit Log
Letzte 20 Schreiboperationen mit Begründung
Kandidaten-Review
Offene Merge-Kandidaten aus hub.id_mapping_kandidat — menschliche Entscheidung (Auto-Merge nur bei striktem Anker). Nutzt ausschließlich
/hub/mapping/* + /hub/reason-codes — keine internen Aufrufe.
Abgleich (on demand):
Filter:
Feld:
Sortierung:
Aktuelle Verbindung
Gespeichert in /config/adapters.json (nicht in Git)
DOMUS MS-SQL — Verbindungsdaten
Port 1433 — der DOMUS-Server muss vom Hetzner-Server aus erreichbar sein
Wie es funktioniert
Nach dem Speichern fragen die Fach-Lesezugriffe direkt den DOMUS MS-SQL-Server ab
(
Ist MS-SQL nicht erreichbar, liefern die Lesemethoden leer (kein Fallback mehr).
Der DOMUS-Server muss Port 1433 vom Hetzner-Server aus erreichbar sein.
dbo.TA0160_Adresse) — read-only, ohne lokalen Spiegel.Ist MS-SQL nicht erreichbar, liefern die Lesemethoden leer (kein Fallback mehr).
Der DOMUS-Server muss Port 1433 vom Hetzner-Server aus erreichbar sein.
DocuWare — Verbindungsdaten
Eigenständiges Quellsystem (DocuWare-Backend, MS-SQL) — nur lesend, gespeichert in /config/adapters.json
Wie es funktioniert
Nach dem Speichern liefert
Der Verbindungstest prüft Erreichbarkeit und zählt sichtbare Tabellen — es werden keine Daten kopiert (nur lesend).
Das Quellsystem muss vom Hetzner-Server aus erreichbar sein (ggf. über VPN/Route).
/fach/docuware/tabellen eine Schema-Übersicht des DocuWare-Backends. Konkrete Dokument-Lesepfade (Cabinets/Index) folgen, sobald das Schema feststeht.Der Verbindungstest prüft Erreichbarkeit und zählt sichtbare Tabellen — es werden keine Daten kopiert (nur lesend).
Das Quellsystem muss vom Hetzner-Server aus erreichbar sein (ggf. über VPN/Route).
DocuWare-Platform — REST-API (Identity-Logon)
Für künftige Dokument-Aktionen (z. B. Download) zusätzlich zur DocuWare-Datenbank oben — gespeichert in /config/adapters.json
Wie es funktioniert
Separater Zugang zur DocuWare-Platform-REST-API (nicht die MS-SQL-Datenbank oben) — nötig für Dokument-Aktionen wie Download/Viewer. Der Logon-Test prüft nur die Anmeldung, es werden keine Dokumente geladen.
Aktuell nutzt kein produktiver Endpunkt diese Zugangsdaten (siehe
Aktuell nutzt kein produktiver Endpunkt diese Zugangsdaten (siehe
engine/DIREKT_ENDPUNKTE.spec.md §3) — die Konfiguration steht bereit, falls ein Download-/Viewer-Feature darauf aufsetzt.
Intranet — Verbindungsdaten
Eigenständiges Quellsystem (EGH-Backend, MS-SQL) — nur lesend, gespeichert in /config/adapters.json
Wie es funktioniert
Nach dem Speichern liefert
Der Verbindungstest prüft Erreichbarkeit und zählt sichtbare Tabellen — es werden keine Daten kopiert (nur lesend).
Das Quellsystem muss vom Hetzner-Server aus erreichbar sein (ggf. über VPN/Route).
/fach/intranet/tabellen eine Schema-Übersicht des EGH-Backends. Konkrete fachliche Lesepfade folgen, sobald die relevanten Tabellen feststehen.Der Verbindungstest prüft Erreichbarkeit und zählt sichtbare Tabellen — es werden keine Daten kopiert (nur lesend).
Das Quellsystem muss vom Hetzner-Server aus erreichbar sein (ggf. über VPN/Route).
Token erzeugen
Benannte Zugriffstokens (z. B. externer LLM via Ollama). Nur mit Admin-Key. Klartext wird nur einmal angezeigt; gespeichert wird nur ein sha256-Hash.
Vorhandene Tokens
Workflow: 1. Widerruf (deaktiviert) → 2. Löschen (aus DB). Beides geloggt.
Token-Status & Verwaltung
Audit, Cleanup (abgelaufen/ungenutzt), Audit-Log.
Ermittelt neue/entfernte Quell-Datensätze und pflegt
hub.id_mapping
(Quell-ID ↔ hub_ref). Läuft vor der Pipeline, die aus diesen hub_refs die
eigentlichen Datenfelder liest und nach fach.* schreibt.
Sync-fähige Begriffe
Zeitplan
Je fälligem Lauf wird pro Begriff erst der Sync, dann die Pipeline ausgeführt (voller Auffrisch-Zyklus →
fach.* bleibt aktuell).Log (letzte 15)
Spiegelt den kompletten Inhalt von
hub.id_mapping_kandidat
(alle Zuordnungen + Vorschläge, alle Status) als vollen Mirror in die
Intranet-Tabelle eghbackend.dbo.datahub_id_mapping_kandidat
— Gegenrichtung zum Sync. Jeder Lauf ersetzt den Zielinhalt
vollständig (DELETE + INSERT in einer Transaktion).
Kandidaten-Export
Zeitplan
Log (letzte Läufe)
Editiert die Steuerungsdateien direkt auf dem Server (persistent, überlebt
Deploys). Jede Speicherung validiert den gesamten Steuerungs-Stand
(Querverweise zwischen den Dateien) und lädt die Engine bei Erfolg neu —
bei Fehlern wird nichts übernommen.
Dateien
Datei auswählen
Versionen
Datei auswählen…
Prüft und pflegt die DataHub-DB (
fach.*/hub.*) gegen die
aktive Steuerung — getrennt von der Datei-Bearbeitung unter „Konfiguration".
Prüft, ob die DataHub-DB (fach.*/hub.*) zur aktiven Steuerung passt. E3-Fehler löst man per Migration.
DB-Optimierung — Ref-Indizes (Meilenstein B)
Indizes auf den Relations-/Ref-Spalten (Join-Keys) — deklariert in begriffssystem
(
index: true). Fehlende können live per CREATE INDEX CONCURRENTLY
angelegt werden (nicht-blockierend, auditiert).
„Prüfen" klicken…
Wege-DB-Funktionen (PFADE.spec)
fach.weg_...-Funktionen für Reporting/SQL-Zugriff — vollständig deklarativ aus
relationen: abgeleitet (kein manueller Pfad-Katalog). Dieselben Wege stehen
auch über GET /fach/finde zur Verfügung (PFADE.spec.md).
„Prüfen" klicken…
DB-Schema-Reparatur (ADMIN_MIGRATIONS.spec)
Je E3-Befund ein generiertes SQL-Skript. Additive Fixes (Tabelle/Spalte/Constraint/Grant
fehlt) können live angelegt werden; alle anderen (Typ-Mismatch, überzählige Spalte,
fälschliches UNIQUE) sind nur zum Kopieren — dafür braucht es eine reguläre Migration.
„Prüfen" klicken…
Geführter LLM-Dialog zum Ergänzen von
begriffssystem.yaml/
mapping.yaml/abfragen.yaml. Das LLM liefert nur
Bausteine (neue Einträge / Erweiterungen bestehender Einträge) — der
DataHub merged sie deterministisch, validiert sie wie im Editor oben und
legt sie bei Erfolg als Entwurf ab. Aktiviert wird ausschließlich
über die Versionen-Ansicht unter „Konfiguration".
LLM-Konfiguration
Dialog
Beschreibe frei, welchen Begriff/welche Domäne du aufnehmen möchtest…