Direkt zum Hauptinhalt

Architektur-Überblick

Diese Übersicht beschreibt den Stand der D-DOK-Komponenten (Release 0.0.7, in Entwicklung 0.0.8). Quelle: git.agrarforschung.at/ddok/ddok.

Architektur-Diagramm

flowchart LR
  subgraph Client["Browser-Client"]
    NG["Angular 21 SPA
(client/)"]
  end

  subgraph Server["D-DOK Server (Node.js)"]
    API["Express + Inversify
(server/)"]
    PDF["PDF-Parse Worker
(modules/pdfparse)"]
  end

  subgraph DBs["Datenbanken (lokal)"]
    MY[("MySQL
Projekte / Publikationen
Metadaten")]
    MO[("MongoDB 7.0
PDF-Dateien + Volltext")]
  end

  subgraph DESS["D-ESS"]
    DESSDB[("MySQL
Kostentraeger / Benutzer:innen")]
  end

  subgraph Auth["Authentifizierung"]
    AD["Active Directory
(LDAPS)"]
    KC["Keycloak OIDC
sso.agrarforschung.at"]
  end

  subgraph Web["BAB Website (0.0.8)"]
    WEBMY[("MySQL
WEB_DATABASE")]
    WEBMO[("MongoDB
WEB_MONGO")]
    SITE["bab.gv.at Public-Frontend"]
  end

  NG -- HTTPS --> API
  API --> MY
  API --> MO
  API -- Lookup --> DESSDB
  API -. optional .-> AD
  API -. optional .-> KC
  API -- "Sync (0.0.8)" --> WEBMY
  API -- "Sync (0.0.8)" --> WEBMO
  WEBMY --> SITE
  WEBMO --> SITE
  PDF --> MO

  classDef new fill:#e8f5e9,stroke:#388e3c
  class WEBMY,WEBMO,SITE,Web new

Komponenten im Überblick

KomponenteStackQuelle
Frontend (SPA)Angular 21 (seit 0.0.8, vorher Angular 17) · Wijmo · Quill-Editorclient/
Backend-APINode.js · Express · Inversify (DI) · TypeScriptserver/
PDF-ParserWorker für Volltext-Extraktion aus PDF-Dateienmodules/pdfparse/
Relationale DBMySQL 3306 — Projekte, Publikationen, StammdatenD-DOK eigene DB
Dokumenten-DBMongoDB 7.0 (Port 27017) — PDF-Binaries + Volltext-IndexD-DOK eigene DB
D-ESS-AnbindungRead-only Zugriff auf D-ESS-Datenbank für Kostentraeger/KS/KT und Benutzer:innen-StammdatenDESS_LINK_ENABLED=true
AuthentifizierungLokal · Active Directory (LDAPS) · Keycloak OIDC (Realm ddok auf sso.agrarforschung.at)Konfiguration in server/config/config.js
Website-Sync (NEU 0.0.8)Zusaetzliche MySQL- und MongoDB-Verbindung zur oeffentlichen BAB-Website — Export ausgewählter PublikationenWEB_DATABASE_* + WEB_MONGO_DATABASE_*

Deployment

    D-DOK

    läuft in Produktion Server:nicht als Container. Das im Repository vorhandene Dockerfile ist ausschließlich eine reproduzierbare Build-Umgebung Dedizierterfür Anwendungsserverdie (Debian)CI – die Laufzeit ist ein klassischer Plesk-/Passenger-Node.js-Prozess.
    AspektDetails Laufzeit-HostPlesk-Server mit Node.js,Phusion lokalerPassenger MySQL-(LXC-Container). Geteilt mit D-ESS, Datenpool und MongoDB-Instanz.Adressdatenbank SSO-Integration:(Co-Tenancy). Node 22 via nodenv. App-PfadeLive: /var/www/vhosts/agrarforschung.at/ddok.agrarforschung.at
    Staging: /var/www/vhosts/agrarforschung.at/staging-ddok.agrarforschung.at SSOKeycloak-Realm ddok (vgl. Eintrag in der SSO-Anwendungsliste auf sso.agrarforschung.at

    Build – npm run build

    Führt drei Workspace-Builds nacheinander aus (package.json):

      build:pdfparse – baut das PDF-Volltext-Modul (modules/pdfparse/). build:client – Angular-Produktions-Build (client/). build:server – bündelt den TypeScript-Server via esbuild (node esbuild.mjs) und erzeugt das Laufzeit-Lockfile (npm --prefix ./dist install --package-lock-only).

      Resultat ist der Ordner dist/ – das eigentliche Deployment-Artefakt.

      Rolle des Dockerfile

      Multi-Stage-Build: Die builder-Stage führt npm ci + npm run build — baut Client, Server (via esbuild)aus und PDF-Parser-Modul;erzeugt Docker-dist/; die finale Stage übernimmt nur dist/, exponiert Port 3000 und definiert CMD ["npm","run","start"]. In der CI wird dieses Image viajedoch nicht als Runtime ausgerollt, sondern dient als hermetische Build-Box: Nach dem Build wird ein Wegwerf-Container erzeugt und dessen Dockerfile/usr/src/app im(= Repo-Root.

      dist/) per docker cp als CI-Artefakt herauskopiert.

      CI/CD:

      CD – .gitlab-ci.yml im

      Drei D-DOK-Repository.Stages, ausschließlich auf Branch master:

        build – Docker-Image bauen (Docker-in-Docker, BuildKit-Registry-Cache), nach Harbor pushen und dist/ als Artefakt extrahieren. deploy:staging (automatisch) – bestehendes Verzeichnis nach backup/ sichern (außer backup/log/config/config.js), dist/* per scp auf den Staging-Host kopieren, .npmrc schreiben, npm ci (nodenv Node 22), touch tmp/restart.txt → Passenger-Reload. deploy:live (manueller Trigger) – identischer Ablauf auf den Live-Host.

        Das Deployment ist somit ein scp-basiertes Datei-Rollout des dist/-Ordners mit anschließendem Passenger-Restart – kein docker run und kein Image-Pull auf dem Zielhost.

        Datenfluesse

        1. Projekt-/Publikationsanlage: Benutzer:innen erstellen Projekte und Publikationen im Angular-Frontend; Daten werden in der MySQL-DB persistiert.
        2. PDF-Upload: Hochgeladene Dateien werden in MongoDB gespeichert; ein PDF-Parser-Worker extrahiert den Volltext für die Suche.
        3. D-ESS-Lookup: Kostenstellen, Kostentraeger und Benutzer:innen-Stammdaten werden zur Laufzeit aus der D-ESS-Datenbank gelesen.
        4. Website-Export (0.0.8): Freigegebene Publikationen werden in die separate Website-Datenbank synchronisiert und auf der oeffentlichen BAB-Website angezeigt.

        Letzte Aktualisierung: 2026-05-2306-10 · Pflege: Roland Neissl · Quelle: git.agrarforschung.at/ddok/ddok

        nach oben