Hub-Status
Verbinde…
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 persist_real (Schutz vor versehentlichen Real-Writes).
Jede Schreiboperation erfordert grund_code (Begründungspflicht) + Audit. Mandanten-Trennung per RLS.
Service-Endpunkte
PfadMethodeBeschreibungSchreibend
/hub/auditGETÄnderungsprotokoll
/hub/verzeichnisGETArt.-30-Verzeichnis (DSGVO)
/hub/reason-codesGETZulässige Änderungsgründe
/hub/statusGETHub-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.
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: 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 (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 /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 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 /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
Widerruf ist sofort wirksam (keine Server-Neustart nötig).
Wählen Sie links ein Dokument zur Vorschau.
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
Log (letzte 15)
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.
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…
Dateien
Datei auswählen
Versionen
Datei auswählen…