Nutzer on dsyr.DataBridge

D365BC — Business Central

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

Der D365BC-Konnektor verbindet die DataBridge mit Microsoft Dynamics 365 Business Central über die OData-v4-REST-API (API-Version 2.0). Er unterstützt sowohl Cloud-Umgebungen (OAuth2) als auch OnPremise-Installationen (Basic Auth).

Eigenschaft	Wert
Lesen	✅ unterstützt
Schreiben	✅ unterstützt
Job-Filter	✅ wird als OData-`$filter` an BC übergeben
Status	Freigegeben
Getestete Mindestversion	Business Central v17.0 (Oktober 2020)

Die Mindestversion wird nicht geprüft

Die Angabe zur Mindestversion beschreibt den getesteten Stand. Die DataBridge fragt die Version von Business Central nicht ab und lehnt ältere Stände nicht ab. Ob eine ältere Installation funktioniert, hängt allein davon ab, ob sie die verwendete API-Version 2.0 und die im Mapping genannten Felder bereitstellt.

Funktionsweise

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

Endpunkt


Function	`Mcp` (`DataBridge/Functions/McpApi.cs`)
Route	`POST /api/mcp` (JSON-RPC-Austausch); `GET /api/mcp` liefert bewusst `405` — siehe Bekannte Einschränkung
Auth-Level	`Function` (Function Key als `?code=`-Query-Parameter)
Protokoll	MCP über Streamable HTTP, stateless — jede POST-Anfrage ist ein eigenständiger JSON-RPC-Austausch, es gibt keine langlebige Server-Session

Der Server ist damit direkt an einer laufenden Function App (lokal oder in Azure) ansprechbar, ohne eigenen Prozess oder zusätzliche Infrastruktur. Da die Authentifizierung über den normalen Azure-Functions-Mechanismus läuft (Function Key), lässt sich der Server ohne zusätzliche Identity-Provider-Konfiguration einrichten — der Key kann als Query-Parameter oder als Header übergeben werden, je nachdem, was der jeweilige Client unterstützt (siehe Nutzung).

Logging & Telemetrie

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

Die DataBridge steuert ihr Telemetrie-Volumen über zwei voneinander unabhängige Mechanismen:

Gepuffertes Logging — Log-Einträge werden pro Funktionsausführung gesammelt und erst am Ende des Laufs, abhängig vom Ergebnis, selektiv gesendet.
Sampling von Abhängigkeiten — ausgehende Aufrufe an Quell- und Zielsysteme werden nur anteilig gesendet, sofern sie erfolgreich und schnell waren.

Der zweite Mechanismus ist der eigentliche Kostenhebel: In einer Volumenanalyse über 90 Tage entfielen rund 78 % des gesamten Datenvolumens auf Abhängigkeiten und nur ein Bruchteil auf Log-Einträge.

Metriken

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

Neben Traces und Requests sendet die dsyr.DataBridge eigene Custom Metrics an Application Insights. Metriken sind numerische Zeitreihen mit Dimensionen — sie eignen sich für Dashboards, Trend-Analysen und Metric Alerts, ohne dass dafür Log-Einträge durchsucht werden müssen.

Die Metriken werden über TelemetryClient.GetMetric() vorab aggregiert: Das SDK sammelt die Werte lokal in 1-Minuten-Intervallen und sendet pro Intervall und Dimensionskombination einen aggregierten Datenpunkt (Summe, Anzahl, Min, Max).

Metriken unterliegen keinem Sampling

Weder das gepufferte Logging noch das Dependency-Sampling noch das Application-Insights-Sampling wirken auf Custom Metrics. Für belastbare Mengenangaben sind sie deshalb die einzige verlässliche Quelle.

Überblick

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

Dieses Kapitel erklärt die dsyr.DataBridge auf zwei Ebenen: konzeptuell für alle, die verstehen wollen wie die Synchronisation abläuft — und technisch für diejenigen, die den genauen Aufbau der Komponenten kennen möchten.

Seite	Zielgruppe	Inhalt
Wie es funktioniert	Alle Nutzer	Datenfluss in einfachen Schritten
Architektur	Techniker, Administratoren	Azure-Komponenten, Services, Queues

Release v2.3

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

Was ist neu

Neue Funktionen

Metadaten-Abfrage für die SQL-Connectoren: Die MCP-Tools list_connector_tables und get_connector_table_schema funktionieren jetzt auch für MSSQL, MySQL, Oracle und PostgreSQL. Bisher war das nur für BC, NAV, CE (Dataverse) und OpenAPI möglich, bei SQL-Verbindungen brach der Aufruf mit einer Fehlermeldung ab. Geliefert werden Spaltenname, Typ, Nullable, maximale Länge, bei Dezimalspalten Precision und Scale sowie der Primary Key — direkt aus dem Datenbank-Katalog (INFORMATION_SCHEMA, bei Oracle USER_*/ALL_*-Views).

Über apiPath wird das Schema gewählt (MySQL: die Datenbank, Oracle: der Owner). Ohne Angabe gilt das Standard-Schema der Verbindung, sodass gleichnamige Tabellen in verschiedenen Schemas (z. B. dbo.Customers / archive.Customers) nicht vermischt werden. Die Metadaten werden zwischengespeichert; Schemaänderungen an der Datenbank werden erst nach einem Neustart der Function App sichtbar. Details: MCP-Server → Operationen.
Genaue .NET-Datentypen je Datenbank: Die Spaltentypen werden je Datenbank passend abgebildet — z. B. date als DateOnly, time als TimeSpan, Spalten mit Zeitzone als DateTimeOffset, Binärspalten als Byte[], MySQL BOOLEAN (tinyint(1)) als Boolean und Oracle NUMBER(p,0) je nach Stellenzahl als Int16/Int32/Int64. Die vollständige Übersicht steht unter MCP-Server → Operationen.
Managed Identity für D365CE (Dataverse): Die Verbindung kann statt über einen Connection-String mit Secret direkt über die Managed Identity der Function App aufgebaut werden. Dazu url (und optional clientid für eine benutzer-zugewiesene Identity) in der Connection angeben. Ein vorhandener connectionstring hat weiterhin Vorrang. Siehe D365CE.
Managed Identity für D365BC (Cloud): Neue Authentifizierungsart ManagedIdentity für HTTP-Konnektoren. Ohne clientId wird die system-zugewiesene, mit clientId die benutzer-zugewiesene Identity genutzt. Der Token wird automatisch erneuert, bevor er abläuft, und mit dem scope der Connection angefordert. Siehe D365BC.
Neuer Verbindungsparameter authmethod: Erlaubt es, die Authentifizierungsmethode ausdrücklich festzulegen (BasicAuthentication, OAuth2, APIKey, ManagedIdentity). Ohne Angabe bleibt das bisherige Verhalten unverändert. ManagedIdentity wird nie automatisch aus fehlenden Zugangsdaten abgeleitet, damit eine unvollständige Connection weiterhin sofort mit einem klaren Fehler abbricht. Siehe Verbindungen.

Verbindungen (connections)

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

Die Tabelle connections ist die Grundlage jeder DataBridge-Konfiguration. Sie enthält die Zugangsdaten zu allen Systemen, mit denen die DataBridge kommuniziert — sowohl Quell- als auch Zielsysteme.

Tabellenstruktur

Spalte	Wert	Beschreibung
PartitionKey	`connection`	Muss immer `connection` lauten
RowKey	frei wählbar	Eindeutiger Name dieser Verbindung. Wird in der `jobs`-Tabelle als Referenz verwendet.
Timestamp	automatisch	Systemseitig gesetzt, nicht bearbeitbar
Type	Connector-Typ	Gibt an, um welches System es sich handelt (siehe Tabelle unten)
Json	JSON-Objekt	System-spezifische Verbindungsparameter (unterscheidet sich je nach `Type`)

PartitionKey ist nicht frei wählbar

Die DataBridge liest die Tabelle ausschließlich mit dem Filter PartitionKey eq 'connection'. Zeilen mit einem abweichenden PartitionKey werden ohne Fehlermeldung und ohne Warnung ignoriert — die Verbindung existiert dann für die DataBridge nicht, und jeder Job, der sie referenziert, wird als unvollständig verworfen.

Voraussetzungen

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

Bevor die DataBridge installiert werden kann, müssen die folgenden Voraussetzungen in Azure, Dataverse und Business Central erfüllt sein.

Azure-Abonnement

Ein aktives Azure-Abonnement ist Pflicht. Im Abonnement müssen die folgenden Resource Provider registriert sein:

Provider	Zweck	Pflicht
`Microsoft.Insights`	Application Insights	✅
`Microsoft.OperationalInsights`	Log Analytics	✅
`Microsoft.ServiceBus`	Service Bus Namespace	✅
`Microsoft.Storage`	Table Storage, Blob Storage	✅
`Microsoft.Web`	Azure Function App	✅
`Microsoft.Dashboard`	Grafana-Dashboard in Application Insights	✅
`Microsoft.KeyVault`	Sichere Speicherung von Connection Strings	optional
`Microsoft.Relay`	Hybrid Connections (OnPremise-Anbindung)	optional
`Microsoft.App`	Container Apps	veraltet / deprecated

Provider können im Azure Portal unter Abonnement → Ressourcenanbieter aktiviert werden.

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<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."

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. Sequenzdiagramme, Bicep-Module, DI-Verdrahtung und Nachrichten-Schemata stehen in der Entwickler-Dokumentation unter Architektur im Detail.

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.

D365CE — Dataverse / Customer Engagement

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

Der D365CE-Konnektor verbindet die DataBridge mit Microsoft Dataverse und Dynamics 365 Customer Engagement über das offizielle Dataverse SDK. Er nutzt die Change Tracking API für eine lückenlose Erkennung aller Änderungen.

Eigenschaft	Wert
Lesen	✅ unterstützt
Schreiben	✅ unterstützt
Job-Filter	✅ clientseitig nach dem Abruf
Status	Freigegeben
Getestete Mindestversion	Dataverse / D365CE v9.1

Die Mindestversion beschreibt den getesteten Stand; eine Versionsprüfung findet im Code nicht statt.

Voraussetzung: Change Tracking aktivieren

Für alle Dataverse-Tabellen, die als Quelle genutzt werden, muss Change Tracking aktiviert sein. Ohne Change Tracking kann der Konnektor keine Differenzabfragen durchführen.

Dokumentation

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

Willkommen in der dsyr.DataBridge-Dokumentation. Hier findest du alles, was du für Einrichtung, Konfiguration und Betrieb einer DataBridge-Instanz benötigst.

Überblick

Neu hier? Starte mit dem konzeptuellen Einstieg.

Wie es funktioniert

Der Datenfluss in fünf Schritten — verständlich ohne technischen Ballast.

→ Zum Artikel

Technische Architektur

Azure-Komponenten, Queue-Struktur, Service-Schicht und Connector-Hierarchie.

→ Zum Artikel

Einrichtung

Voraussetzungen

Benutzerkonten, Berechtigungen, Azure-Provider, Change Tracking.

→ Zum Artikel

Installation

Azure-Ressourcen per Bicep anlegen, Function App deployen.

→ Zum Artikel

Umgebungsvariablen

Alle App-Settings mit Standardwerten und Wirkung.

→ Zum Artikel

Einrichtung

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

Dieses Kapitel führt Schritt für Schritt durch die erstmalige Einrichtung einer dsyr.DataBridge-Instanz. Am Ende steht eine vollständig deployete und konfigurierte Azure Function App, die synchronisieren kann.

Empfohlene Reihenfolge:

Voraussetzungen — Benutzer, Berechtigungen, Azure-Provider
Installation — Azure-Ressourcen per Bicep anlegen, Function deployen
Umgebungsvariablen — Alle Einstellungen im Function-App-Kontext

Ergänzend, außerhalb des regulären Installationswegs:

Container-Betrieb — Betrieb als Container-Image. Beta, nicht für den Kundenbetrieb vorgesehen.

Installation

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

Für die Installation gibt es zwei Wege:

Weg	Wann geeignet
Azure Marketplace	Regelfall. Läuft vollständig im Azure Portal, keine lokale Software nötig.
Bicep / Azure CLI	Automatisierte oder wiederholbare Deployments, Integration in eine Pipeline.

Beide Wege legen dieselben Ressourcen an und sind gleichwertig im Ergebnis.

Weg 1 — Azure Marketplace (empfohlen)

1. Ressourcengruppe anlegen

Im Azure Portal eine neue Ressourcengruppe für die DataBridge-Instanz erstellen. Pro Umgebung (Test, Produktion) wird eine eigene Ressourcengruppe verwendet.

Jobs (jobs)

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

Ein Job beschreibt genau eine Synchronisationsrichtung zwischen zwei Systemen: er verbindet eine Quelltabelle mit einer Zieltabelle, legt den Zeitplan fest und verweist auf das zugehörige Mapping.

Tabellenstruktur

Spalte	Pflicht	Beschreibung
PartitionKey	✅	Muss immer `job` lauten.
RowKey	✅	Eindeutiger Jobname. Wird im Logging und als Referenz für ResponseJobs verwendet.
IsActive	✅	`true` = Job wird von `GetChanges` ausgeführt. `false` = Job wird nur indirekt (als ResponseJob) aufgerufen.
SourceConnection	✅	RowKey-Referenz auf einen Eintrag in der `connections`-Tabelle (Quelldaten).
TargetConnection	✅	RowKey-Referenz auf einen Eintrag in der `connections`-Tabelle (Zieldaten).
Mapping	✅	PartitionKey-Referenz auf eine Gruppe von Einträgen in der `mappings`-Tabelle.
Source	—	Quellressource (Tabelle, Entität, Pfad oder Aktion). Überschreibt die `SourceTable` der Mapping-Zeilen für diesen Job (siehe unten).
Target	—	Zielressource (Tabelle, Entität, Pfad oder Aktion). Überschreibt die `TargetTable` der Mapping-Zeilen für diesen Job (siehe unten).
Order	✅	Ganzzahl. Legt die Ausführungsreihenfolge fest — muss über alle Jobs eindeutig sein.
WatermarkField	—	Feldname im Quellsystem, der als Änderungsindikator genutzt wird (meistens ein Datums-/Zeitstempelfeld). Nur bei `WatermarkType` = `date` oder `datetime` erforderlich; bei `string` (Dataverse Change Tracking) bleibt das Feld leer.
WatermarkType	✅	Typ des Watermark-Wertes: `date`, `datetime` oder `string` (Details: Watermarks).
Filter	—	Filterausdruck für die Quellanfrage. Format ist systemabhängig (siehe unten).
Schedule	—	CRON-Ausdruck (6-stellig, NCrontab). Wenn leer, läuft der Job bei jedem Timer-Aufruf.
Action	—	Steuert, welche Änderungsarten gelesen werden, oder benennt eine Aktion. Leer = `NewUpdate`. Wirkt bei den CRUD-Werten (`Delete`, `DeleteOnUpdate`) nur bei D365CE als Quellsystem (siehe unten); ein nicht erkannter Wert schaltet den Job auf `InvokeAction` (siehe unten).
Priority	—	`Standard` (Vorgabe), `High` oder `Low`. Steuert die Service-Bus-Queue.
ResponseJob	—	RowKey eines anderen Jobs, der nach erfolgreichem Schreiben automatisch ausgeführt wird.
IsValid	—	Reserviert. Die Spalte kommt in bestehenden Tabellen vor, wird von der DataBridge aber nicht gelesen und hat keine Wirkung.

PartitionKey ist nicht frei wählbar

Die DataBridge liest die Tabelle ausschließlich mit dem Filter PartitionKey eq 'job'. Zeilen mit einem abweichenden PartitionKey werden ohne Fehlermeldung und ohne Warnung ignoriert — der Job existiert dann für die DataBridge schlicht nicht.

Dasselbe gilt für die connections-Tabelle (dort connection). Nur bei mappings ist der PartitionKey frei wählbar — er dient dort der Gruppierung.

Monitoring & Alerts

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

Ein funktionierendes Monitoring erkennt Probleme, bevor sie auffallen. Die DataBridge kann über Azure Monitor Alert Rules so konfiguriert werden, dass bei Fehlern, Queue-Staus oder Dead-Letter-Einträgen automatisch Benachrichtigungen ausgelöst werden.

Aufbau des Alert-Systems

Das Azure-Alert-System besteht aus zwei Komponenten:

Alert Rule Action Group
────────────────── ──────────────────────────
Bedingung definieren → Wer wird benachrichtigt?
Scope: Ressource E-Mail, SMS, Webhook, Azure Role
Condition: KQL / Metric
Schwellwert festlegen

Empfohlene Reihenfolge:

Zuerst die Action Group anlegen (Empfänger)
Dann die Alert Rules darauf zeigen lassen

Action Group anlegen

Azure Portal → Monitor → Warnungen → Action Groups → Erstellen

Operationen

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

Alle zehn Tools sind als ReadOnly = true, Idempotent = true und Destructive = false markiert (MCP-Tool-Annotationen, die dem aufrufenden Client mitgeben, dass wiederholte Aufrufe risikolos sind). Kein Tool schreibt, löscht oder sendet — weder in der jobs-/mappings-Tabelle, noch in den Service-Bus-Queues, noch in einem Quell-/Zielsystem.

Grenze ist Metadaten vs. Nutzdaten, nicht nur lesend vs. schreibend

Auch innerhalb der reinen Lesezugriffe gibt es eine bewusste zweite Grenze: Betriebs-/ Konfigurationsdaten (Job-Namen, Schemata, Fehlermeldungen, Zeitstempel) sind unkritisch und werden vollständig zurückgegeben. Fachliche Nutz-/Kundendaten — z. B. der Inhalt einer Service-Bus-Nachricht — werden dagegen nie zurückgegeben, selbst wenn das zugrunde liegende Tool ansonsten “nur liest”. Details dazu unten bei den Peek-Tools.

Performance & Laufzeiten

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

Die folgenden Abfragen können direkt im Logs-Bereich von Application Insights (Kusto Query Language) ausgeführt werden.

Laufzeiten und Fehler

Laufzeiten aller Funktionen (letzte 24 Stunden)

requests
| where timestamp > ago(24h)
| summarize
 Aufrufe = count(),
 DurchschnittMs = avg(duration),
 P95Ms = percentile(duration, 95),
 Fehler = countif(success == false)
 by name
| order by DurchschnittMs desc

Verlauf einer einzelnen Funktion (letzte 7 Tage)

requests
| where timestamp > ago(7d)
| where name == "GetChanges"
| summarize
 P50Ms = percentile(duration, 50),
 P95Ms = percentile(duration, 95),
 Fehler = countif(success == false),
 Läufe = count()
 by bin(timestamp, 1h)
| order by timestamp asc

Durchschnittliche Laufzeit der letzten 30 Tage (täglich)

requests
| where timestamp > ago(30d)
| summarize
 DurchschnittMs = avg(duration),
 P95Ms = percentile(duration, 95)
 by name, bin(timestamp, 1d)
| order by name asc, timestamp asc

Fehlerquote je Funktion (letzte 7 Tage)

requests
| where timestamp > ago(7d)
| summarize
 Gesamt = count(),
 Fehler = countif(success == false),
 FehlerPct = round(100.0 * countif(success == false) / count(), 1)
 by name
| order by FehlerPct desc

Warnungen und Fehler im Zeitverlauf

traces
| where timestamp > ago(7d)
| where severityLevel >= 2 // 2 = Warning, 3 = Error
| summarize Anzahl = count() by severityLevel, bin(timestamp, 1h), operation_Name
| order by timestamp asc

Top-10 häufigste Fehlermeldungen

exceptions
| where timestamp > ago(7d)
| summarize Anzahl = count() by outerMessage
| top 10 by Anzahl desc

Einzelne Ausführung nachvollziehen

Alle Einträge einer Ausführung (per operation_Id)

union requests, traces, exceptions
| where operation_Id == "<operation_Id hier einfügen>"
| project timestamp, itemType, severityLevel, message, outerMessage, operation_Name
| order by timestamp asc

Fehlerläufe mit allen zugehörigen Traces (letzte 24 Stunden)

let fehlgeschlagene =
 requests
 | where timestamp > ago(24h)
 | where success == false
 | project operation_Id, FunktionsName = name, Startzeit = timestamp;
traces
| where timestamp > ago(24h)
| join kind=inner fehlgeschlagene on operation_Id
| project Startzeit, FunktionsName, severityLevel, message
| order by Startzeit desc, severityLevel desc

Abhängigkeiten

Langsamste Abhängigkeiten (letzte 24 Stunden)

Zeigt die ausgehenden Aufrufe an Quell- und Zielsysteme mit den höchsten Laufzeiten:

Release v2.2

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

Was ist neu

Neue Funktionen

Neuer Connector: generische REST-API über OpenAPI-Spezifikation: Neben BC, CE, NAV und den SQL-Connectoren steht jetzt ein generischer HTTP-Connector zur Verfügung, der ein beliebiges REST-API anhand seiner OpenAPI-/Swagger-Beschreibung anbindet (neuer Verbindungstyp OPENAPI). Damit lassen sich Systeme ohne eigenen Connector über ihr veröffentlichtes API-Schema anbinden, statt eine dedizierte Implementierung zu benötigen. Details, Konfigurationsbeispiel und unterstützte Auth-Methoden siehe OpenAPI-Connector.
Neue Authentifizierungsart „API-Key“ für HTTP-Connectoren: Zusätzlich zu Basic-Auth und OAuth2 unterstützen alle HTTP-basierten Connectoren (BC, NAV, OpenAPI) jetzt die Authentifizierung über einen statischen API-Key, der als Header an jede Anfrage angehängt wird (apiKeyHeader / apiKeyValue in der Connection). Zusätzlich kann der OAuth2-Token-Endpunkt über tokenUrl frei konfiguriert werden, statt fest auf den Microsoft-Login-Endpunkt zu zeigen — relevant für Systeme mit eigenem oder abweichendem Token-Server.
Action-Jobs (InvokeAction): Jobs können jetzt statt eines CRUD-Datenabgleichs eine einzelne benannte Aktion auf dem Zielsystem auslösen (z. B. eine OpenAPI-Action/operationId oder einen D365CE-OrganizationRequest). Ein solcher Job benötigt kein Mapping in der Mapping-Tabelle — die Aktion und ihre Parameter werden direkt aus der Queue-Nachricht und dem Job selbst gebildet. Siehe Action — welche Änderungsarten gelesen werden.
Ressourcenpfad direkt am Job konfigurierbar: Jobs können nun ihre Quell- und Zielressource (Tabelle, Entität oder Pfad) direkt in den neuen Job-Feldern Source/Target tragen, statt sie zwingend über die Mapping-Tabelle zu beziehen. Bestehende, ausschließlich über die Mapping-Tabelle konfigurierte Jobs funktionieren unverändert weiter; ohne Eintrag in Source/Target greift wie bisher die Mapping-Tabelle.
Kind-Datensätze einbetten (EmbedChildren, D365CE): Eine neue Source-Operation erlaubt es, die Datensätze eines referenzierten Kind-Jobs (z. B. Angebotspositionen zu einem Angebot) direkt in die Queue-Nachricht des Eltern-Datensatzes einzubetten, sodass beide gemeinsam in einer Anfrage beim Ziel ankommen. Der Filter des Kind-Jobs kann dabei über {{...%parent.Feldname%...}} auf Werte des Eltern-Datensatzes zugreifen.
Neue Diagnose-Endpunkte GET /job und GET /mapping: Zwei neue, rein lesende HTTP-Endpunkte (/job, /job/{rowKey}, /mapping, /mapping/{rowKey}) geben die aktuell geladene Job- bzw. Mapping-Konfiguration zurück — praktisch zur Fehlersuche, ohne direkt in der Table-Storage nachsehen zu müssen.
Eingebauter MCP-Server für KI-Assistenten (z. B. Claude Code, GitHub Copilot, Microsoft 365 Copilot): Ein neuer, rein lesender Model-Context-Protocol-Endpunkt (POST /api/mcp) macht Jobs, Mappings sowie Service-Bus-Diagnosedaten (Queue-Laufzeit-Status, non-destruktives Peek von Nachrichten und Dead-Letter-Nachrichten) als KI-Tools ansprechbar — dediziert dafür gibt es keinen eigenen HTTP-Endpunkt. Zwei der zehn Tools gehen noch einen Schritt weiter: list_connector_tables und get_connector_table_schema lesen die echten Tabellen-/Feld-Metadaten (Typ, Nullable, maximale Länge, Primary Key) direkt aus dem Quell-/Zielsystem einer Connection — für BC, NAV, CE (Dataverse) und OpenAPI —, sodass sich ein Mapping gegen das tatsächliche Schema validieren lässt, statt sich auf die Mapping-Konfiguration allein zu verlassen. Für die SQL-Connectoren (MSSQL, MySQL, Oracle, PostgreSQL) ist das noch nicht implementiert.

Die beiden Peek-Tools geben bewusst niemals den Nachrichteninhalt zurück, nur dessen Größe in Bytes (BodySize) — der Body kann fachliche Kunden-/Geschäftsdaten des jeweiligen Jobs enthalten, die Kopf-/Fehlerdaten (JobName, ErrorMessage, Stacktrace, Zustellversuche, …) reichen für die Diagnose. Die Tool-Beschreibungen selbst sind auf Englisch verfasst, da sie vom aufrufenden KI-Modell gelesen werden, nicht von einem Menschen. Details, Einrichtung (inkl. GitHub Copilot/VS Code und Microsoft 365 Copilot Studio), die vollständige Tool-Liste mit Lese-Umfang je Tool sowie die Funktionsweise: MCP-Server.
System-assigned Managed Identity für die Function App: Die Azure Function App erhält beim Deployment automatisch eine system-zugewiesene Managed Identity. Ihre Objekt-ID (principalId) steht als Deployment-Output (functionPrincipalId) für nachgelagerte Rollenzuweisungen zur Verfügung. Die Identity wird immer angelegt.
Optional (Preview): Storage & Service Bus über Managed Identity: Über den neuen Schalter enableManagedIdentity (Standard: aus) lassen sich die Verbindungen zu Storage und Service Bus von Schlüsseln auf identitätsbasierten Zugriff umstellen. Ist der Schalter aktiv, weist das Bicep-Deployment der Identity die nötigen Rollen zu (Storage Table/Blob/Queue, Service Bus Sender/Receiver/Data Owner — Data Owner wird für die Queue-Status-Abfrage des MCP-Tools list_queue_statuses benötigt) und die App-Settings verwenden AzureWebJobsStorage__accountName bzw. …__fullyQualifiedNamespace statt der Schlüssel-Verbindungszeichenfolgen.

Standardmäßig bleibt alles beim Schlüssel-basierten Zugriff — ein reines ZIP-/Image-Update ändert daran nichts. Die Umstellung erfolgt nur, wenn das Bicep-Script mit aktiviertem Schalter neu deployt wird (siehe Installationshinweise).
Leere Quell-Schlüssel gezielt ignorieren (IgnoreEmptySourceKey, D365CE): Ist das Quellfeld eines Ziel-Schlüssels leer, brach die Verarbeitung der Nachricht bisher immer mit einem Fehler ab — auch dann, wenn ein weiterer Schlüssel den Datensatz noch hätte finden können. Mit dem neuen Feld IgnoreEmptySourceKey am TargetKey (Standard: aus) lässt sich das je Schlüssel abschalten: Der betroffene Schlüssel wird übersprungen und die Suche läuft mit dem nächsten Schlüssel nach KeyRank weiter.

Das ist vor allem im Multikey-Szenario relevant, wenn ein optionales Feld wie eine externe ID nicht in jedem Quelldatensatz gefüllt ist, ein nachrangiger Schlüssel den Zieldatensatz aber sicher findet.

Findet kein Schlüssel einen Datensatz und waren alle leer gebliebenen Schlüssel entsprechend markiert, wird ein neuer Datensatz angelegt statt ein Fehler gemeldet. War auch nur einer der leeren Schlüssel nicht markiert, bleibt es beim Fehler. Details siehe IgnoreEmptySourceKey.

Bestehende Mappings sind nicht betroffen — ohne gesetztes Feld bleibt das bisherige Verhalten unverändert.

D365NAV — Microsoft Dynamics NAV

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

Der D365NAV-Konnektor verbindet die DataBridge mit Microsoft Dynamics NAV über OData. Er ist auf die ältere NAV-API-Struktur ausgelegt und unterstützt auch OnPremise-Installationen mit NTLM-Authentifizierung.

Eigenschaft	Wert
Lesen	✅ unterstützt
Schreiben	✅ unterstützt
Job-Filter	✅ wird als OData-`$filter` an NAV übergeben
Status	Freigegeben
Getestete Mindestversion	NAV 2018

Die Mindestversion wird nicht geprüft

Die Angabe beschreibt den getesteten Stand. Die DataBridge fragt die NAV-Version nicht ab. Ältere Installationen können funktionieren, sofern sie OData mit $metadata bereitstellen — abgesichert ist das jedoch nicht.

Grafana-Dashboard

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

Seit v2.1 liefert jede Installation ein vorkonfiguriertes Grafana-Dashboard mit. Es zeigt auf einen Blick, ob die DataBridge läuft, wie schnell sie arbeitet und wo Fehler auftreten — ohne dass dafür KQL-Abfragen geschrieben werden müssen.

Ohne Zutun vorhanden

Das Dashboard wird bei jedem Deployment automatisch angelegt. Es gibt keinen Schalter zum Abwählen und keine manuelle Einrichtung. Zusätzliche Kosten entstehen nicht — die Abfragen laufen gegen die ohnehin vorhandene Application-Insights- und Service-Bus-Instanz.

Konfiguration

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

Die dsyr.DataBridge hat keine Konfigurationsdateien. Alle Laufzeit-Einstellungen — Verbindungen zu Quell- und Zielsystemen, Synchronisations-Jobs, Feld-Mappings und Änderungsstände — leben in vier Azure Tables innerhalb der zugehörigen Ressourcengruppe.

Das hat einen entscheidenden Vorteil: Anpassungen werden ohne Redeployment wirksam. Die Tabellen werden beim nächsten Funktionsaufruf automatisch neu eingelesen.

Tabelle	Inhalt
connections	Zugangsdaten zu Quell- und Zielsystemen
jobs	Welche Tabellen werden wann in welche Richtung synchronisiert
mappings	Welche Felder werden wie übertragen und transformiert
watermarks	Letzter synchronisierter Stand pro Job

Mappings (mappings)

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

Die mappings-Tabelle ist die mächtigste Konfigurationsebene der DataBridge. Sie legt für jedes Feld fest: woher kommt der Wert, wohin geht er, und wie wird er unterwegs transformiert.

Ein Mapping ist eine Gruppe von Zeilen in der Tabelle — alle mit demselben PartitionKey. Jede Zeile beschreibt genau eine Feld-Zuordnung.

Tabellenstruktur

Spalte	Pflicht	Beschreibung
PartitionKey	✅	Name des Mappings. Wird im Job unter `Mapping` referenziert. Im Gegensatz zu `jobs` und `connections` ist der PartitionKey hier frei wählbar — er dient der Gruppierung.
RowKey	✅	Eindeutiger Bezeichner innerhalb des Mappings. Konvention: `_quellfeld__zielfeld_`
SourceTable	✅	Name der Quelltabelle/-entität. Muss innerhalb eines Mappings konsistent sein.
SourceField	—	Name des Quellfeldes. Kann leer sein (bei `DefaultValue`) oder mit `_` beginnen — dann handelt es sich um ein virtuelles Feld.
TargetTable	✅	Name der Zieltabelle/-entität. Muss innerhalb eines Mappings konsistent sein.
TargetField	✅	Name des Zielfeldes. Muss dem tatsächlichen API-/Spaltenname entsprechen.
TargetKey	—	JSON-Objekt. Definiert, wie ein bestehender Datensatz im Zielsystem identifiziert wird (für Upsert-Logik).
SourceOperation	—	JSON-Objekt der Form `{ "Operations": [ … ] }`. Transformation beim Lesen aus der Quelle.
TargetOperation	—	JSON-Objekt der Form `{ "Operations": [ … ] }`. Transformationen beim Schreiben ins Ziel.

RowKey-Namenskonvention

Die empfohlene Konvention für den RowKey: _quellfeld__zielfeld_

Nutzung

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

Der Server spricht Standard-MCP über Streamable HTTP — grundsätzlich verbindet sich jeder MCP-fähige Client über dieselbe URL (.../api/mcp?code=<Function-Key>). Die folgenden Abschnitte zeigen die konkrete Einrichtung für die gängigsten Clients.

Claude Code

Dieses Repository bringt bereits eine passende .mcp.json mit:

{
 "mcpServers": {
 "databridge": {
 "type": "http",
 "url": "${DATABRIDGE_MCP_URL:-http://localhost:7062}/api/mcp?code=${DATABRIDGE_FUNCTION_KEY:-local}"
 }
 }
}

Lokal (Core Tools / Debugger): Der lokale Function-Host prüft den Auth-Level Function nicht — der Platzhalterwert local in der URL reicht aus. Voraussetzung ist nur, dass die Function App tatsächlich auf Port 7062 läuft (nicht der func-Standard 7071!):

Umgebungsvariablen

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

Die DataBridge Function App wird über Anwendungseinstellungen (Application Settings) konfiguriert. Diese sind im Azure Portal unter Function App → Einstellungen → Umgebungsvariablen zu finden und zu bearbeiten.

Seit v2.1 bereits beim Deployment setzbar

Der Timer-Ausdruck und alle vier Telemetrie-Einstellungen lassen sich direkt beim Deployment vorgeben — als Bicep-Parameter (Beispiele in bicep/params/databridge.sample.bicepparam) oder im Marketplace-Assistenten unter Product Settings. Ein nachträgliches Pflegen in den App-Settings ist damit nur noch für Änderungen im laufenden Betrieb nötig.

Release v2.1

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

Was ist neu

Neue Funktionen

Statische Schlüsselwerte für Lookups: Ein Lookup kann jetzt gegen einen fest hinterlegten Wert aufgelöst werden, ohne dass dafür ein Quellfeld existieren muss. Dazu wird im Schlüssel (Keyvalue) statt eines attributeName ein StaticValue angegeben. Nützlich, wenn ein Lookup immer auf denselben Zieldatensatz zeigen soll (z.B. eine feste Kategorie oder ein Standard-Datensatz).
Mehrere Ziel-Schlüssel je Mapping mit Rangfolge: Ein Table-Mapping bzw. ein Lookup kann nun mehrere Ziel-Schlüssel (TargetKeys) besitzen. Die Schlüssel werden anhand des neuen Felds KeyRank in aufsteigender Reihenfolge geprüft; sobald ein Schlüssel im Zielsystem einen Datensatz findet, wird dieser verwendet und die weiteren Schlüssel werden übersprungen. Damit lassen sich unterschiedliche Schlüssel gegen das CRM zulassen (z.B. zuerst eine externe ID, danach ersatzweise eine Nummer). Bestehende Mappings mit einem einzelnen TargetKey funktionieren unverändert weiter.
Automatische Anlage bei Lookups abschaltbar: Über die neue Option DoNotCreate am Lookup lässt sich steuern, dass ein nicht gefundener Ziel-Datensatz nicht automatisch angelegt wird. Ist die Option gesetzt, wird der Lookup nur aufgelöst, wenn der Datensatz bereits existiert — andernfalls bleibt das Feld leer, statt einen neuen Datensatz zu erzeugen.
String-zu-Decimal-Konvertierung: Der Decimal-Resolver akzeptiert jetzt auch Quellwerte vom Typ string und wandelt sie in einen Dezimalwert um (Interpretation im Format en-US, d.h. Punkt als Dezimaltrennzeichen). Leere Strings werden zu null, nicht konvertierbare Werte werfen wie bisher einen Fehler.
Vorab-Zwischenspeicherung von Lookups (Pre-Caching): Beim Verarbeiten eines Batches werden benötigte Lookup-Werte vorab gebündelt aufgelöst und zwischengespeichert. Dadurch werden wiederholte Einzelabfragen gegen das Zielsystem vermieden, was die Verarbeitung großer Änderungsmengen beschleunigt.
Sampling von Abhängigkeiten (Dependencies): Ausgehende Aufrufe an Quell- und Zielsysteme (D365 OData, SQL, Table Storage, Service Bus) werden von Application Insights automatisch als Abhängigkeiten erfasst und verursachten bisher den Großteil des Datenvolumens — bei minutengenauem Polling ein Vielfaches aller Log-Einträge zusammen. Diese Aufrufe werden nun gefiltert: Fehlgeschlagene sowie langsame Aufrufe werden immer vollständig gesendet, erfolgreiche und schnelle nur zu einem konfigurierbaren Anteil (Standard: 10 %). Das reduziert das tägliche Datenvolumen erheblich; Exceptions, Requests und alle Log-Einträge eines Fehler-Laufs bleiben unverändert vollständig erhalten. Steuerbar über die neuen Einstellungen TELEMETRY_DEPENDENCY_SAMPLE_RATE und TELEMETRY_DEPENDENCY_SLOW_MS; Details unter Betrieb → Logging.

Zu beachten

Container-Betrieb

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

Die DataBridge lässt sich als Container-Image bauen und betreiben. Das Image basiert auf der Azure-Functions-Laufzeit und enthält dieselbe Anwendung wie das reguläre Deployment.

Beta — nicht für den Kundenbetrieb

Der Container-Betrieb ist eine Beta-Funktion und nicht für den produktiven Kundenbetrieb vorgesehen. Auch der auf dieser Seite beschriebene Weg selbst ist noch Beta: Abläufe, Dateinamen und Parameter können sich ohne Ankündigung ändern.

Für Kundeninstallationen gilt weiterhin der reguläre Weg über den Azure Marketplace oder Bicep.

Wer die DataBridge als Container einsetzen möchte, wendet sich bitte vorab an WYSA — dort wird der konkrete Anwendungsfall geprüft und der aktuelle Stand mitgeteilt.

Konnektoren

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

Jedes Quell- oder Zielsystem wird über einen Konnektor angebunden. Ein Konnektor übernimmt die systemspezifische Kommunikation: Authentifizierung, Datenabfrage, Änderungserkennung und das Schreiben von Datensätzen.

Unterstützte Konnektoren

Konnektor	Beschreibung	Lesen	Job-Filter	Schreiben	Status
D365BC	Dynamics 365 Business Central	✅	✅	✅	Freigegeben
D365CE	Dynamics 365 / Dataverse	✅	✅	✅	Freigegeben
D365NAV	Microsoft Dynamics NAV	✅	✅	✅	Freigegeben
MSSQL	Microsoft SQL Server	⚠️ Preview	✅	—	Preview
MySQL	MySQL / MariaDB	⚠️ Preview	—	—	Preview, nicht produktionsreif
Oracle	Oracle Database	⚠️ Preview	—	—	Preview, nicht produktionsreif
PostgreSQL	PostgreSQL	⚠️ Preview	—	—	Preview
OpenAPI	Generische REST-API über OpenAPI-Spezifikation	✅	⚠️ API-abhängig	✅ (inkl. Löschen)	In Entwicklung

Die Konnektoren D365BC, D365CE und D365NAV kommunizieren über HTTP/OData-APIs. MSSQL, MySQL, Oracle und PostgreSQL verwenden direkte Datenbankverbindungen (ADO.NET). Der OpenAPI-Konnektor kommuniziert ebenfalls über HTTP, leitet Pfade, Wrapper-Schlüssel und Feldtypen jedoch aus einer OpenAPI-Spezifikation ab, statt sie fest zu verdrahten.

MSSQL — Microsoft SQL Server

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

Preview

Der MSSQL-Konnektor ist als Vorabversion eingestuft. Lesen ist funktionsfähig, Schreiben wird nicht unterstützt. Vor einem produktiven Einsatz bitte WYSA kontaktieren.

Der MSSQL-Konnektor ermöglicht das Lesen von Daten aus Microsoft SQL Server-Datenbanken (OnPremise und Azure SQL) und deren Übertragung in andere Systeme.

Eigenschaft	Wert
Lesen	⚠️ Preview
Schreiben	— nicht unterstützt
Job-Filter	✅ wird als `WHERE`-Klausel übernommen
Status	Preview

Wie die übrigen drei SQL-Konnektoren wertet MSSQL den Filter des Jobs aus und erzeugt gültiges Paging für sein Datenbanksystem.

Updates & Upgrades

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

Diese Seite beschreibt das Vorgehen bei einem Update. Die vollständigen Änderungen und Installationshinweise je Release stehen in der Versionshistorie.

Vorgehen bei einem Update

Die Konfiguration in Table Storage bleibt bei einem Update unverändert — es sei denn, ein Breaking Change erfordert Anpassungen.

Schritte

Release Notes prüfen — Breaking Changes und Installationshinweise des Zielrelease und aller dazwischenliegenden Versionen lesen (Versionshistorie)
Wartungsfenster einplanen — GetChanges über ein App-Setting deaktivieren:
```
AzureWebJobs.GetChanges.Disabled = true
```
Bei Bedarf lassen sich die Verarbeiter analog abschalten (AzureWebJobs.ProcessStandardQueueItems.Disabled usw.)
Warten, bis alle Queue-Nachrichten verarbeitet wurden (Queue-Länge im Azure Portal prüfen)
Neue Version einspielen — je nach Betriebsart:
- Container: Image-Tag auf die neue Version setzen
- Marketplace: Assistenten erneut durchlaufen (bei unveränderten Standardwerten ergibt sich keine Änderung an bestehenden Einstellungen)
- Bicep / Pipeline: Deployment erneut ausführen
- Zip-Upload: Paket über die Pipeline oder manuell einspielen
Konfigurationsanpassungen aus den Installationshinweisen vornehmen

GetChanges wieder aktivieren:

AzureWebJobs.GetChanges.Disabled = false (oder Eintrag löschen)

Ersten Lauf beobachten — z. B. über die Custom Metric ChangesDetected je Job oder die Fehlerquoten-Abfrage unter Performance & Laufzeiten

App-Settings lösen einen Neustart aus

Jede Änderung an den App-Settings startet die Function App neu. Das ist beim Ein- und Ausschalten der Funktionen in Schritt 2 und 6 eingeplant.

Release v2.0

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

Was ist neu

Neue Funktionen

Containerisierung mit Docker Compose: Die DataBridge kann nun direkt über docker compose (bzw. Podman) lokal gestartet werden. Eine neue compose.yml sowie eine Beispiel-Umgebungsdatei (.podman/podman.env.sample) sind enthalten. Das Start-Skript start-local.sh / start-local.ps1 baut den Container, startet ihn und gibt alle HTTP-Trigger-URLs inkl. Authentication-Key direkt aus.
Robustere Initialisierung in GetChanges: Die Timer-Funktion GetChanges initialisiert den CoreService jetzt threadsicher (Mutex-Pattern). Schlägt die Initialisierung fehl, wird sie beim nächsten Timer-Durchlauf automatisch erneut versucht (Self-Repair) — analog zu ProcessQueueItems.
ASP.NET Core HTTP-Integration: Die Azure Functions App nutzt nun das ASP.NET Core-Integrationsmodell (ConfigureFunctionsWebApplication). Dies ist die empfohlene Methode ab .NET 8+ und ermöglicht vollständigere HTTP-Features.
Custom Metrics: Die DataBridge sendet eigene, pre-aggregierte Metriken an Application Insights (Namespace DataBridge). Erste Metrik: ChangesDetected mit Dimension JobName — Anzahl erkannter Änderungen pro Job und GetChanges-Lauf, inkl. Null-Werten. Sichtbar im Metrics Explorer und in der Tabelle customMetrics; Details unter Betrieb → Logging.
Gepuffertes Logging mit selektiver App-Insights-Weiterleitung: Alle Log-Einträge einer Funktionsausführung werden zunächst im Arbeitsspeicher gepuffert und erst am Ende der Ausführung — abhängig vom Ergebnis — selektiv an Azure Application Insights gesendet. Im Fehlerfall stehen damit auch alle Debug-Einträge rückwirkend zur Verfügung, ohne dass sie bei erfolgreichen Läufen Kosten verursachen. Das Verhalten lässt sich über die Umgebungsvariablen TELEMETRY_CONTROL und TELEMETRY_INFO_SAMPLE_RATE steuern. Eine vollständige Beschreibung befindet sich unter Betrieb → Logging.
Trace-Level für Live-Diagnose: Log-Einträge auf Level Trace (LogTrace) werden nie an Application Insights gesendet — auch nicht bei Fehler-Läufen. Sie sind ausschließlich live sichtbar: lokal in der Konsole bzw. im Container-Log, in Azure im Log Stream der Function App. Details unter Betrieb → Logging.

Watermarks (watermark)

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

Die Tabelle watermark ist die Gedächtnisfunktion der DataBridge. Nach jedem Job-Lauf wird hier gespeichert, bis zu welchem Stand die Daten gelesen wurden. Beim nächsten Lauf startet der Quellabruf genau an diesem Punkt.

Diese Tabelle wird vom Deployment angelegt und zur Laufzeit automatisch befüllt — manuelle Einträge sind normalerweise nicht nötig. Es gibt jedoch Situationen, in denen ein gezielter Eingriff sinnvoll ist.

Tabellenstruktur

Spalte	Wert	Beschreibung
PartitionKey	`watermark`	Fest vorgegeben — immer `watermark`
RowKey	Jobname	Entspricht dem RowKey des zugehörigen Jobs in der `jobs`-Tabelle
Timestamp	automatisch	Systemseitig gesetzt, nicht bearbeitbar
Watermark	Letzter Stand	Format abhängig vom `WatermarkType` des Jobs (siehe unten)
LastCronRun	Zeitstempel	Beginn der letzten Ausführung des Jobs. Basis für die CRON-Intervallprüfung.

Watermark-Typen

Der Typ wird im Job über das Feld WatermarkType festgelegt und bestimmt, wie der gespeicherte Wert interpretiert wird.

MCP-Server

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

Die dsyr.DataBridge unterstützt das Model Context Protocol (MCP) — den offenen Standard, über den KI-Assistenten strukturiert auf externe Systeme zugreifen. Ein eingebauter, read-only MCP-Server macht dieselben Daten, die auch über die HTTP-APIs (GetJobByRowKey, GetMappingByRowKey) verfügbar sind, sowie die Service-Bus-Queue-Diagnose zusätzlich als MCP-Tools ansprechbar — sodass ein KI-Assistent (Claude Code, GitHub Copilot, Microsoft 365 Copilot, …) direkt gegen eine laufende DataBridge-Instanz Fragen stellen kann, statt Tabellen manuell in Azure Storage Explorer oder per REST-Aufruf durchzusehen.

Ältere Releases

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

Für die Versionen vor 2.0 existiert keine vollständige Release-Dokumentation. Überliefert sind die Breaking Changes der jeweiligen Übergänge — sie sind hier unverändert festgehalten, damit die Migrationshistorie nicht verloren geht.

Vor der Migration lesen

Wer von einer Version vor 2.0 aktualisiert, muss die Schritte aller dazwischenliegenden Übergänge nacheinander durchführen — zusätzlich zu den Installationshinweisen aus v2.0 und v2.1.

1.0 → 1.1

Breaking Changes:

Einführung von vier neuen Service-Bus-Warteschlangen: sbqignored, sbqtransitivestandart, sbqtransitivelow, sbqtransitivehigh
Einführung der neuen Anwendungseinstellung SkipOutdatedMessages in der Azure Function; beim Upgrade von 1.0 auf false zu setzen

Schreibweise der Queue-Namen

Der Name sbqtransitivestandart ist im Produkt genau so geschrieben (mit t am Ende) und darf beim Anlegen der Warteschlange nicht „korrigiert" werden — sonst findet die DataBridge die Queue nicht.

Betrieb & Wartung

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

Eine laufende DataBridge-Instanz braucht Beobachtung. Dieses Kapitel erklärt, wie man den Betrieb nachvollzieht, Fehler diagnostiziert, Warnungen automatisiert und die Instanz auf neue Versionen aktualisiert.

Seite	Inhalt
Logging	Wie Logs entstehen, Sampling von Traces und Abhängigkeiten, Custom Metrics, KQL-Abfragen
Monitoring & Alerts	Azure Alert Rules, Action Groups, empfohlene Schwellwerte
Grafana-Dashboard	Automatisch ausgeliefertes Betriebsdashboard in Application Insights
Updates & Upgrades	Upgrade-Pfade zwischen Versionen, Breaking Changes

MySQL — MySQL / MariaDB

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

Preview — nicht produktionsreif

Der MySQL-Konnektor ist als Vorabversion eingestuft und für den produktiven Einsatz derzeit nicht geeignet. Er ist weder freigegeben noch für den Regelbetrieb abgesichert.

Wer MySQL oder MariaDB anbinden möchte, wendet sich bitte vorab an WYSA — dort wird der konkrete Anwendungsfall geprüft und der aktuelle Stand mitgeteilt.

Der MySQL-Konnektor ist für das Lesen von Daten aus MySQL- und MariaDB-Datenbanken vorgesehen.

Eigenschaft	Wert
Lesen	⚠️ Preview, nicht produktionsreif
Schreiben	— nicht unterstützt
Job-Filter	✅ wird als `WHERE`-Klausel übernommen
Status	Preview

Wie beim MSSQL-Konnektor wird der Inhalt des Feldes Filter am Job — nach Ersetzung des Platzhalters %watermark% — wörtlich hinter WHERE eingesetzt. Ohne Eintrag im Feld Filter entsteht keine WHERE-Klausel und der Job liest bei jedem Lauf die vollständige Tabelle. Der Ausdruck muss gültiges MySQL-SQL sein; es findet keine Parametrisierung statt. Details zur Filter-Syntax siehe MSSQL — Filter.

Oracle — Oracle Database

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

Preview — nicht produktionsreif

Der Oracle-Konnektor ist als Vorabversion eingestuft und für den produktiven Einsatz derzeit nicht geeignet. Er ist weder freigegeben noch für den Regelbetrieb abgesichert.

Wer eine Oracle-Datenbank anbinden möchte, wendet sich bitte vorab an WYSA — dort wird der konkrete Anwendungsfall geprüft und der aktuelle Stand mitgeteilt.

Der Oracle-Konnektor ist für das Lesen von Daten aus Oracle-Database-Instanzen vorgesehen.

Eigenschaft	Wert
Lesen	⚠️ Preview, nicht produktionsreif
Schreiben	— nicht unterstützt
Job-Filter	✅ wird als `WHERE`-Klausel übernommen
Status	Preview

Wie beim MSSQL-Konnektor wird der Inhalt des Feldes Filter am Job — nach Ersetzung des Platzhalters %watermark% — wörtlich hinter WHERE eingesetzt. Ohne Eintrag im Feld Filter entsteht keine WHERE-Klausel und der Job liest bei jedem Lauf die vollständige Tabelle. Der Ausdruck muss gültiges PL/SQL sein; es findet keine Parametrisierung statt. Details zur Filter-Syntax siehe MSSQL — Filter.

Versionshistorie

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

Hier findet sich die Release-Dokumentation für alle Versionen der dsyr.DataBridge.

Jede Version beschreibt die wesentlichen Änderungen aus Anwender-Sicht sowie Installationshinweise für Administratoren, die ein bestehendes System aktualisieren. Die Details zu etwaigen Breaking Changes stehen jeweils im Abschnitt Installationshinweise der verlinkten Release-Seite.

Release	Schwerpunkt	Breaking Change
v2.3	Tabellen- und Spalten-Metadaten der SQL-Connectoren (MSSQL, MySQL, Oracle, PostgreSQL) über den MCP-Server, Mapping-Abfrage per Name, schlankeres NAV-Logging, Managed Identity (System/User-assigned) für D365BC und D365CE mit neuem Verbindungsfeld `authmethod`; für Entwickler: lokale Podman-Testumgebung mit HTTP-Mocks, Service-Bus-Emulator und Debug-Modus	✅
v2.2	Neuer OpenAPI-Connector, eingebauter MCP-Server für KI-Assistenten, Action-Jobs, System-assigned Managed Identity für die Function App, Verbesserungen am Grafana-Dashboard	✅
v2.1	Erweiterte Lookup-Funktionen, Sampling von Abhängigkeiten, Grafana-Dashboard, Watermark-Korrekturen	✅
v2.0	Umstellung auf .NET 10, Containerisierung, gepuffertes Logging, Custom Metrics	❗
Ältere Releases	Migrationshinweise für die Übergänge 1.0 → 1.1 und 1.1 → 2.0	❗

Vor einem Update lesen

Die Abschnitte Installationshinweise der jeweiligen Version enthalten die Details zu Breaking Changes und notwendigen Migrationsschritten. Beim Überspringen von Versionen sind die Hinweise aller dazwischenliegenden Releases zu beachten — die Spalte oben zeigt nur, ob ein Übergang überhaupt einen Breaking Change enthält, keine vollständige Liste.

PostgreSQL

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

Preview

Der PostgreSQL-Konnektor ist als Vorabversion eingestuft. Lesen ist funktionsfähig, Schreiben wird nicht unterstützt. Vor einem produktiven Einsatz bitte WYSA kontaktieren.

Der PostgreSQL-Konnektor ermöglicht das Lesen von Daten aus PostgreSQL-Datenbanken und deren Übertragung in andere Systeme.

Eigenschaft	Wert
Lesen	⚠️ Preview
Schreiben	— nicht unterstützt
Job-Filter	✅ wird als `WHERE`-Klausel übernommen
Status	Preview

Wie beim MSSQL-Konnektor wird der Inhalt des Feldes Filter am Job — nach Ersetzung des Platzhalters %watermark% — wörtlich hinter WHERE eingesetzt. Ohne Eintrag im Feld Filter entsteht keine WHERE-Klausel und der Job liest bei jedem Lauf die vollständige Tabelle. Der Ausdruck muss gültiges PostgreSQL-SQL sein; es findet keine Parametrisierung statt. Details zur Filter-Syntax siehe MSSQL — Filter.

OpenAPI — generischer REST-Konnektor

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

Der OpenAPI-Konnektor verbindet die DataBridge mit einer beliebigen REST-API, für die eine OpenAPI-Spezifikation (JSON oder YAML) existiert. Anders als bei den übrigen HTTP- Konnektoren werden Pfade, Wrapper-Schlüssel ({"clients": [...]} vs. {"client": {...}}) und Feldtypen nicht pro Ressource fest verdrahtet, sondern zur Laufzeit aus der Spezifikation aufgelöst. Ein Mapping muss dafür lediglich SourceTable/TargetTable auf den Ressourcennamen setzen (z. B. clients).

Eigenschaft	Wert
Lesen	✅ unterstützt
Schreiben (Create/Update)	✅ unterstützt
Löschen	✅ unterstützt
Aktionsaufrufe (InvokeAction)	✅ unterstützt
Job-Filter	⚠️ wird als Query-String an die Liste-Anfrage angehängt (kein `$filter`-Standard, API-abhängig)
Status	In Entwicklung / Preview

Status: in Entwicklung

Der Konnektor befindet sich noch in aktiver Entwicklung. Die OpenAPI-Spezifikation wird über den in openApiSpecUrl konfigurierten Endpunkt geladen. Bekannte Einschränkungen:

Der Diagnose-Endpunkt CheckList meldet für OpenAPI-Mappings fälschlich „could not find table“. Er vergleicht die Tabellennamen mit den Pfaden der Spezifikation (/v1/customers) statt mit den Ressourcennamen (customers). Auf das Lesen und Schreiben hat das keinen Einfluss.
get_connector_table_schema weist keinen Primärschlüssel aus. Intern erkennt der Konnektor den Schlüssel am Namen der Property (id, Id, ID, uuid, key).

D365BC

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

D365CE

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

D365NAV

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

Docker / Podman

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

Entwickler

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

Mapping

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

MCP-Server

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

MSSQL

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

MySQL

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

Nutzer

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

OpenAPI

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

Oracle

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

PostgreSQL

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

Service Bus

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

dsyr.DataBridge

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

dsyr.DataBridge

Ihre Geschäftsdaten – synchron, automatisch und sicher in Ihrer eigenen Azure-Umgebung.

Überblick Einrichtung starten

Schluss mit Doppelpflege und manuellem Export.

Die dsyr.DataBridge verbindet Microsoft Dynamics 365 Business Central mit Dataverse – und bei Bedarf weitere Systeme. Daten fließen automatisch dorthin, wo sie gebraucht werden, ohne dass sie jemals Ihr Haus verlassen.

Themen

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

Watermark

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