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

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.

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.

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

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.

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.

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

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.

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

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

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.

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.

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.

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.

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 aktuell noch in aktiver Entwicklung. Insbesondere die Auflösung der OpenAPI-Spezifikation lädt im aktuellen Codestand (OpenApiConnector.GetOpenApiDocument) eine lokale Testdatei von einer festen Pfadangabe, nicht den über openApiSpecUrl konfigurierten Endpunkt. Vor einem produktiven Einsatz ist das zu prüfen bzw. zu beheben.