Einrichtung

• 1: Voraussetzungen
• 2: Installation
• 3: Umgebungsvariablen
• 4: Container-Betrieb

1 - Voraussetzungen

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 können im Azure Portal unter Abonnement → Ressourcenanbieter aktiviert werden.

Empfohlene Instanzen-Struktur

Pro Umgebung wird eine eigene DataBridge-Instanz (= Ressourcengruppe) benötigt. Als Regelfall werden zwei Instanzen empfohlen:

Eine Entwicklungsinstanz ist meist nicht nötig, da die Entwicklung der DataBridge selbst bei WYSA liegt und sich eine Synchronisation im Entwicklungssystem selten lohnt.

Eine dritte Instanz für Entwicklung ist dann sinnvoll, wenn im Entwicklungssystem eigene Anpassungen an Dataverse oder Business Central entstehen, die vor dem Test gegen eine laufende Synchronisation geprüft werden sollen — etwa neue Felder, geänderte Optionssets oder umgebaute Entitäten. In diesem Fall werden drei Ressourcengruppen benötigt (Entwicklung, Test, Produktion).

Laufzeitumgebung

Die DataBridge läuft als Azure Function App. Die folgenden Eckdaten werden vom Deployment gesetzt und müssen nicht vorbereitet werden — sie sind hier als Referenz für die Abstimmung mit der IT aufgeführt:

Beim containerisierten Betrieb wird zusätzlich Zugriff auf die WYSA-Container-Registry benötigt. Das aktuelle Image ist acrwysatest.azurecr.io/containered-connector:v2.3.0.

Unterstützte Quell- und Zielsysteme

Für die vier SQL-Systeme gelten die unten beschriebenen Anforderungen an Anwendungsbenutzer und Change Tracking nicht — dort werden lediglich ein Connection String und die Netzwerkerreichbarkeit aus Azure heraus benötigt. Die Konnektoren sind als Vorabversion eingestuft und unterstützen kein Schreiben; Details auf den Konnektor-Seiten.

Benutzerkonten

Die folgenden Anforderungen gelten für die Anbindung von Dataverse und Business Central. Für SQL-Quellsysteme genügt ein Datenbankbenutzer mit Leserechten.

Administrations-/Betreuungsbenutzer (Entra-Benutzer)

Für die Einrichtung und Pflege von Dataverse und Business Central wird ein menschlicher Benutzer benötigt, der in Entra ID existiert und entsprechend lizensiert ist.

Anwendungsbenutzer (Service Principal / App Registration)

Anwendungsbenutzer ermöglichen der DataBridge den automatisierten, sicheren Zugriff auf die Systeme — ohne personengebundene Credentials.

Minimum: 1 Anwendungsbenutzer pro DataBridge-Instanz.

Empfehlung: 3 Anwendungsbenutzer für maximale Sicherheit und klare Trennung:

Alle Anwendungsbenutzer müssen als App Registration in Entra ID angelegt und in den jeweiligen Systemen als S2S-Benutzer registriert sein.

Dataverse: Change Tracking aktivieren

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

Aktivierung: Power Platform Admin Center → Umgebung → Tabellen → Tabelle auswählen → Eigenschaften → „Änderungsnachverfolgung aktivieren" ✅

Benötigte Software für die Installation

Für das Deployment per Bicep / Azure CLI muss auf dem ausführenden Rechner installiert sein:

Bicep-Extension installieren und verifizieren:

az bicep install
az bicep version   # Ausgabe sollte ≥ 0.35 zeigen

Die Installation selbst kann durch WYSA durchgeführt werden, sofern der Deployment-Anwendungsbenutzer mit Contributor-Rechten auf der Ressourcengruppe bereitgestellt wurde. Soll der Preview-Schalter enableManagedIdentity genutzt werden, benötigt der Deployment-User Owner oder User Access Administrator, da dabei Rollenzuweisungen angelegt werden.

2 - Installation

Für die Installation gibt es zwei Wege:

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.

2. DataBridge aus dem Marketplace auswählen

In der Ressourcengruppe Erstellen wählen und im Marketplace nach der WYSA DataBridge suchen.

3. Region und Kurzname festlegen

4. Produkteinstellungen

Unter Product Settings werden die fachlichen Einstellungen gruppiert:

Alle Telemetrie-Einstellungen können auf den Vorgabewerten bleiben und später jederzeit in den Umgebungsvariablen angepasst werden.

5. Service Bus

6. Storage Account

Als Speicherkonto-Typ steht ausschließlich StorageV2 zur Verfügung.

7. App Service Plan

Anschließend über Überprüfen und erstellen das Deployment starten.

Weg 2 — Bicep / Azure CLI

1. Bicep-Dateien bereitstellen

Die Bicep-Templates befinden sich im Repository unter bicep/. Klone das Repository oder lade die Dateien auf den Rechner, von dem aus die Installation durchgeführt wird.

2. Bei Azure anmelden

az login

Es öffnet sich ein Browser-Fenster. Melde dich mit dem Deployment-Anwendungsbenutzer oder dem Administrations-Benutzer an, der Contributor-Rechte auf der Ziel-Ressourcengruppe hat. Den Haken bei „Zugriffseinwilligung für alle Benutzer" nicht setzen.

3. Abonnement prüfen

az account show

Vergleiche die angezeigte Abonnement-ID mit der ID im Azure Portal. Falls mehrere Abonnements vorhanden sind, das richtige setzen:

az account set --subscription "<Abonnement-ID>"

4. Ressourcen deployen

az deployment group create --template-file ./bicep/main.bicep --resource-group <Name-der-Ressourcengruppe> --parameters name=<instanzname> -c

Das Flag -c zeigt eine Vorschau der Änderungen an. Mit Y oder J bestätigen.

Bicep-Parameter im Überblick

Infrastruktur:

Laufzeit und Telemetrie:

Alerts:

Was angelegt wird

Nach erfolgreichem Deployment existieren in der Ressourcengruppe:

Service-Bus-Queues: sbqexport · sbqhighexport · sbqlowexport · sbqignored · sbqtransitivehigh · sbqtransitivestandart · sbqtransitivelow

Table-Storage-Tabellen: connections, jobs, mappings, watermark — sie werden vom Deployment leer angelegt.

Phase 2 — Function App befüllen

Beim Marketplace-Weg entfällt dieser Schritt in der Regel; das Paket wird mit ausgeliefert. Beim Bicep-Weg wird der Anwendungscode separat eingespielt.

Option A: Container-Image

Wird die DataBridge containerisiert betrieben, verweist die Function App auf das bereitgestellte Image:

acrwysatest.azurecr.io/containered-connector:v2.3.0

Option B: Zip-Upload per Azure Portal

1. Im Azure Portal die Function App öffnen
2. Entwicklungstools → Erweiterte Tools (Kudu) öffnen
3. In Kudu: Tools → Zip Push Deploy
4. Die bereitgestellte .zip-Datei per Drag & Drop hochladen
5. Nach dem Upload startet die Function App automatisch neu

Option C: Deployment-Pipeline

Das Deployment kann über eine CI/CD-Pipeline automatisiert werden. WYSA stellt hierfür Azure-Pipeline-Definitionen zur Verfügung (cicd/-Verzeichnis). Alternativ kann eine eigene Azure-DevOps- oder GitHub-Actions-Pipeline verwendet werden.

Nach der Installation: Konfigurationstabellen befüllen

Nach dem Deployment laufen die Azure Functions — aber noch ohne Konfiguration. Die vier Table-Storage-Tabellen existieren, sind aber leer:

Die Tabellen können über den Azure Storage Explorer oder direkt im Azure Portal (Storage Account → Tables) bearbeitet werden.

Details zu den Tabellen und den erwarteten Feldern sind im Kapitel Konfiguration beschrieben.

Umgebungsvariablen prüfen

Alle Verbindungs-Strings sowie der Timer-Ausdruck und die Telemetrie-Einstellungen werden vom Deployment gesetzt. Nachträglich anzupassen sind sie nur, wenn vom Vorgabewert abgewichen werden soll.

Eine vollständige Übersicht findet sich auf der Seite Umgebungsvariablen.

Installation prüfen

Sobald Konfigurationstabellen und Umgebungsvariablen gesetzt sind, kann die Installation geprüft werden:

GET https://func-<name>.azurewebsites.net/api/GetInfo?code=<Function-Key>

Eine erfolgreiche Antwort sieht so aus:

{
  "Version": "2.1.2026.802"
}

Alternativ: Im Azure Portal → Function App → Funktionen → GetInfo → Testen/Ausführen — dort wird der Schlüssel automatisch mitgegeben.

Für eine inhaltliche Prüfung der Konfiguration stehen zusätzlich die Diagnose-Funktionen Validate (prüft die hinterlegte Konfiguration) und CheckList (gleicht Mappings gegen die Attribute der beteiligten Systeme ab) zur Verfügung.

3 - Umgebungsvariablen

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.

Infrastruktur-Verbindungen

Diese Variablen verbinden die Function App mit den zugehörigen Azure-Diensten. Sie werden durch das Deployment automatisch befüllt.

¹ Schlüssel- oder identitätsbasiert. Standardmäßig werden die beiden Connection Strings gesetzt. Zusätzlich setzt das Deployment in diesem Modus TARGET_BASED_SCALING_ENABLED=0: Target-based Scaling ist damit abgeschaltet, der Host skaliert direkt über den Metrics Monitor und die entsprechende Warnung im Log entfällt. Ist der Preview-Schalter enableManagedIdentity (Bicep) aktiv, entfallen sie und werden durch die identitätsbasierten Varianten ersetzt — die Function nutzt dann die Managed Identity:

Lokal (local.settings.json) bleiben die schlüsselbasierten Connection Strings maßgeblich.

Laufzeit-Einstellungen

CRON-Ausdruck — Format

Der CRON-Ausdruck nutzt das 6-stellige NCrontab-Format (inkl. Sekunden):

┌─────────── Sekunde  (0–59)
│ ┌───────── Minute   (0–59)
│ │ ┌─────── Stunde   (0–23)
│ │ │ ┌───── Tag      (1–31)
│ │ │ │ ┌─── Monat    (1–12)
│ │ │ │ │ ┌─ Wochentag (0–6, Sonntag=0)
│ │ │ │ │ │
*/15 * * * * *  →  alle 15 Sekunden (Vorgabe)
0 */2 * * * *   →  alle 2 Minuten
0 */5 * * * *   →  alle 5 Minuten
0 0 */1 * * *   →  stündlich

Einzelne Jobs können über das Feld Schedule einen eigenen, seltener greifenden Zeitplan bekommen — siehe Jobs.

Logging & Telemetrie

Die DataBridge steuert ihr Telemetrie-Volumen über zwei Mechanismen: gepuffertes Logging für Log-Einträge und Sampling für ausgehende Aufrufe. Ausführlich beschrieben unter Betrieb → Logging.

Telemetrie-Verhalten im Überblick

Trace-Einträge erreichen Application Insights grundsätzlich nie — auch nicht bei Fehler-Läufen. Sie sind ausschließlich live im Log Stream der Function App bzw. im Container-Log sichtbar.

Abhängigkeiten

Die Entscheidung fällt hier pro Aufruf und nicht pro Funktionsausführung — ein fehlgeschlagener Lauf enthält deshalb nicht zwangsläufig die erfolgreichen Aufrufe davor.

Funktionen gezielt deaktivieren

Einzelne Azure Functions können ohne Redeployment deaktiviert werden. Das ist nützlich, um z. B. die Quellabruf-Funktion zu stoppen, ohne die Queue-Verarbeitung zu unterbrechen.

Das Namensschema AzureWebJobs.<Funktionsname>.Disabled gilt für jede Function der App. Neben den vier betrieblich relevanten oben sind das:

ExecuteJob · ExecuteHttpRequest · GetInfo · Validate · CheckList · StartGetChangesOrchestration · GetChangesOrchestrator · GetChangesActivity · JobState

Die letzten vier gehören zur optionalen Durable-Orchestrierung, die im Regelbetrieb ohnehin nicht aktiv ist.

Plattform-Einstellungen — nicht verändern

Diese Werte setzt das Deployment. Sie steuern die Azure-Functions-Laufzeit selbst und haben keinen fachlichen Bezug zur DataBridge:

Nur im Container-Betrieb

Key Vault (optional)

Statt Connection Strings direkt in den Anwendungseinstellungen zu speichern, können diese in einem Azure Key Vault hinterlegt werden. Die Function App referenziert das Secret dann per Key Vault Reference:

@Microsoft.KeyVault(SecretUri=https://<vault>.vault.azure.net/secrets/<name>/)

Diese Referenz wird direkt als Wert der jeweiligen Umgebungsvariable eingetragen. Azure löst sie zur Laufzeit automatisch auf — ohne Änderungen am Code.

Für die Zugangsdaten zu Quell- und Zielsystemen gibt es einen zweiten, davon unabhängigen Weg über den Parameter keyVaultUrl im Verbindungs-JSON — siehe Verbindungen.

4 - Container-Betrieb

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.

Sinnvoll ist der Container-Betrieb derzeit vor allem für lokale Tests und Entwicklung: Die HTTP-Trigger lassen sich damit ohne Azure-Deployment aufrufen.

Voraussetzungen

Alle Befehle auf dieser Seite werden aus dem Ordner src/ ausgeführt — dort liegen Dockerfile, compose.yml und die Start-Scripts.

Image bauen

Das Dockerfile liegt in src/. Bei Bedarf lässt sich dort das Basis-Image anpassen.

• Docker
• Podman

docker build --tag acrwysatest.azurecr.io/containered-connector:v2.3.0 .

podman build --tag acrwysatest.azurecr.io/containered-connector:v2.3.0 .

Allgemein aufgebaut ist der Tag so:

{acr-name}.azurecr.io/{image-name}:{version}

In die Azure Container Registry veröffentlichen

Zunächst an Azure und anschließend an der Registry anmelden:

az login

az acr login --name acrwysatest

Danach das gebaute Image veröffentlichen:

docker push acrwysatest.azurecr.io/containered-connector:v2.3.0

Damit steht das Image unter der angegebenen Versionsnummer in der Registry bereit.

az acr update -n acrwysatest --admin-enabled true

Lokal betreiben

Umgebungsdatei anlegen

In src/.podman/ liegt die Vorlage podman.env.sample. Diese kopieren und unter dem Namen podman.<Umgebung>.env ablegen, zum Beispiel podman.wysatest.env:

cp .podman/podman.env.sample .podman/podman.wysatest.env

Anschließend die Datei mit den Verbindungsdaten der Zielumgebung füllen. Sie enthält unter anderem AzureWebJobsStorage, ConnectionStrings__ExportQueueServiceBus, APPLICATIONINSIGHTS_CONNECTION_STRING, den Timer-Ausdruck GetChangesTimerExpression sowie die Funktions-Toggles.

Danach in src/compose.yml prüfen, dass env_file auf die richtige Datei verweist:

    env_file:
      - .podman/podman.wysatest.env

Der Container veröffentlicht seinen Port unter 7071 und setzt AzureWebJobsSecretStorageType=files, damit die Function-Keys im Container abgelegt werden können.

Start-Script (empfohlen)

Der einfachste Weg sind die mitgelieferten Start-Scripts in src/. Sie bauen das Image, starten den Container und geben anschließend alle HTTP-Trigger-URLs inklusive Authentication-Key aus.

• Linux / macOS
• Windows (PowerShell)

bash start-local.sh

.\start-local.ps1

Die Ausgabe sieht dann ungefähr so aus:

============================================
 DataBridge lokal gestartet
============================================
 Master Key: abc123...

 HTTP-Trigger URLs:

 [GET]  http://127.0.0.1:7071/api/GetInfo?code=abc123...
 [GET]  http://127.0.0.1:7071/api/CheckList?code=abc123...
 [POST] http://127.0.0.1:7071/api/ExecuteJob?code=abc123...
 [POST] http://127.0.0.1:7071/api/ExecuteHttpRequest?code=abc123...
============================================

Die URLs lassen sich direkt im Browser öffnen oder in Bruno beziehungsweise curl verwenden.

Manueller Start

Wer den Container selbst steuern möchte, startet ihn aus dem Ordner src/:

podman compose up --build -d

Logs anzeigen:

podman compose logs -f

Container beenden:

podman compose down

Installation prüfen

Ob der Container korrekt läuft, lässt sich über die HTTP-Trigger prüfen — GetInfo liefert die Version, CheckList und Validate prüfen Mappings und Konfiguration. Die Details dazu stehen unter Installation.