# Wie es funktioniert

> Der Datenfluss der dsyr.DataBridge in fünf Schritten — verständlich erklärt ohne technischen Ballast.

---

Site [llms.txt](/llms.txt)

---

## 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

```mermaid
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:

| Priorität | Typischer Einsatz |
|---|---|
| **Hoch** | Zeitkritische Stammdaten (z. B. Preise, Kundendaten) |
| **Standard** | Normale Synchronisation (Bestellungen, Kontakte) |
| **Niedrig** | Historische Daten, große Datenmengen ohne Zeitdruck |

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.