Wie es funktioniert

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<br/>ändern sich]) -->|"alle 15 Sekunden<br/>prüfen"| B[DataBridge<br/>erkennt Änderung]
    B -->|"Datensätze<br/>puffern"| C[(Service Bus<br/>Queue)]
    C -->|"Nachricht<br/>verarbeiten"| D[Felder<br/>mappen & wandeln]
    D -->|"schreiben"| E([Zielsystem<br/>aktualisiert])
    E -->|"Stand merken"| F[(Watermark<br/>gespeichert)]
    F -.->|"nächster Lauf<br/>startet hier"| B

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

Schritt 1 — Änderungen erkennen

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

Dafür nutzt sie den gespeicherten Watermark — einen Zeitstempel oder einen Änderungstoken, der beim letzten erfolgreichen Lauf hinterlegt wurde.

Schritt 2 — Änderungen puffern

Gefundene Datensätze landen nicht sofort im Zielsystem, sondern zunächst in einer Azure Service Bus Queue. Das entkoppelt Erkennung und Verarbeitung: Selbst wenn das Zielsystem kurz nicht erreichbar ist, gehen keine Daten verloren. Die Queue speichert die Nachrichten bis zur erfolgreichen Verarbeitung.

Schritt 3 — Felder mappen und wandeln

Jede Nachricht aus der Queue wird einzeln verarbeitet. Die DataBridge liest die konfigurierten Mappings und weiß: Quellfeld A geht in Zielfeld B, Wert X wird zu Wert Y übersetzt, ein fehlendes Feld bekommt einen Standardwert.

Dieser Schritt ist vollständig konfigurierbar — ohne Programmierung.

Schritt 4 — Ins Zielsystem schreiben

Der gemappte Datensatz wird ins Zielsystem geschrieben. Die DataBridge prüft dabei anhand eines konfigurierten Schlüssels, ob der Datensatz dort bereits existiert:

• Existiert: Update des vorhandenen Datensatzes
• Existiert nicht: Neuanlage

Schritt 5 — Watermark aktualisieren

Nach erfolgreichem Durchlauf speichert die DataBridge den neuen Stand als Watermark. Beim nächsten Timer-Aufruf dient dieser Wert als Startpunkt — so werden Datensätze weder doppelt übertragen noch übersprungen.

Bidirektionale Synchronisation

Die fünf Schritte gelten für eine Richtung der Synchronisation. Wenn Daten in beide Richtungen fließen sollen (z. B. BC → Dataverse und Dataverse → BC), werden zwei unabhängige Jobs konfiguriert — jeder mit eigenem Quell- und Zielsystem, eigenem Mapping und eigenem Watermark.

Prioritäten und Parallelverarbeitung

Nicht alle Datensätze sind gleich wichtig. Die DataBridge kennt drei Prioritätsstufen:

Nachrichten mit hoher Priorität werden bevorzugt verarbeitet, ohne dass niedrigere Prioritäten blockiert werden.

Was passiert bei Fehlern?

Schlägt die Verarbeitung einer Nachricht fehl, gibt es mehrere Sicherheitsnetze:

1. Automatischer Wiederholungsversuch — die Nachricht wird nach kurzer Wartezeit erneut verarbeitet (bis zu einer konfigurierten Maximalanzahl).
2. Transitive Queue — meldet das Zielsystem einen Konflikt (z. B. ein Duplikat), wird die Nachricht in eine separate Queue abgelegt, damit sie den Hauptpfad nicht blockiert. Dort wird sie nicht automatisch erneut verarbeitet, sondern bei Bedarf manuell zurückgestellt.
3. Dead-Letter Queue — dauerhaft nicht verarbeitbare Nachrichten werden dort gesammelt und können analysiert oder manuell re-queued werden.

In keinem dieser Fälle gehen Daten still verloren. Das Monitoring und die konfigurierbaren Alerts informieren aktiv, wenn die Dead-Letter Queue Einträge enthält.