Wie es funktioniert

Mon, 01 Jan 0001 00:00:00 +0000

Das Grundprinzip

Die dsyr.DataBridge arbeitet wie ein kontinuierlicher Datenstrom zwischen zwei Systemen. Sie fragt regelmäßig: „Was hat sich seit dem letzten Mal geändert?" — und überträgt genau diese Änderungen ins Zielsystem. Nichts mehr, nichts weniger.

Kein manueller Export. Kein Doppelpflegen. Keine Vollsynchronisation, die alles neu schreibt. Nur die Differenz, automatisch, im Minutentakt.

Der Datenfluss in fünf Schritten

flowchart LR
 A([Quelldaten\nändern sich]) -->|"alle 2 Minuten\nprüfen"| B[DataBridge\nerkennt Änderung]
 B -->|"Datensätze\npuffern"| C[(Service Bus\nQueue)]
 C -->|"Nachricht\nverarbeiten"| D[Felder\nmappen & wandeln]
 D -->|"schreiben"| E([Zielsystem\naktualisiert])
 E -->|"Stand merken"| F[(Watermark\ngespeichert)]
 F -.->|"nächster Lauf\nstartet hier"| B

 style A fill:#e8f5f1,stroke:#18b28d
 style E fill:#e8f5f1,stroke:#18b28d
 style C fill:#fff3e0,stroke:#f57c00
 style F fill:#e3f2fd,stroke:#1565c0

Schritt 1 — Änderungen erkennen

Alle zwei Minuten (konfigurierbar) startet ein Timer. Die DataBridge fragt das Quellsystem: „Gib mir alle Datensätze, die seit meinem letzten Stand geändert wurden."

Technische Architektur

Mon, 01 Jan 0001 00:00:00 +0000

Zielgruppe

Diese Seite richtet sich an Administratoren und technische Nutzer, die den internen Aufbau der DataBridge verstehen oder Probleme diagnostizieren möchten. Für einen konzeptuellen Einstieg siehe Wie es funktioniert.

Azure-Komponenten

Die DataBridge besteht aus mehreren Azure-Diensten, die in einer gemeinsamen Ressourcengruppe betrieben werden:

Komponente	Dienst	Rolle
Function App	Azure Functions (Isolated Worker, .NET 10)	Ausführungsumgebung für alle Funktionen
App Service Plan	`Microsoft.Web/serverfarms`	Compute-Plan: Y1 (Consumption, Standard) oder EP1–EP3 (Premium)
Service Bus	Azure Service Bus Namespace	Puffer zwischen Erkennung und Verarbeitung
Table Storage	Azure Storage Account	Laufzeit-Konfiguration (Connections, Jobs, Mappings, Watermark)
Application Insights	Azure Monitor	Logging, Telemetrie, Alerting; Traces und ausgehende Aufrufe werden gesampelt
Grafana-Dashboard	`Microsoft.Dashboard/dashboards`	Vorkonfiguriertes Betriebsdashboard im Application-Insights-Blade (seit v2.1, wird immer mitdeployt)
Metric Alerts + Action Group	Azure Monitor	Dead-Letter- und Queue-Längen-Alerts, optional über `enableAlerts`

Eigene Infrastruktur

Alle Komponenten laufen im **eigenen Azure-Abonnement** des Kunden. Die DataBridge nutzt keinen geteilten Dienst im Datenpfad — Datenverkehr und Konfiguration verlassen das Kunden-Abonnement nicht. Beim containerisierten Betrieb wird lediglich das Container-Image aus der WYSA-Registry bezogen.

Architektur nach dem C4-Modell

Die folgenden drei Diagramme folgen dem C4-Modell (Context → Container → Component) — von außen nach innen, jede Ebene zoomt weiter in die DataBridge hinein.