# Voraussetzungen > Benutzerkonten, Berechtigungen, Azure-Provider und Software, die vor der Installation bereitstehen müssen. --- Site [llms.txt](/llms.txt) --- 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. > **`Microsoft.Dashboard` ist seit v2.1 erforderlich** > > Das [Grafana-Dashboard](../../betrieb/grafana-dashboard/) wird bei jedem Deployment > angelegt — ohne Möglichkeit, es abzuwählen. Ist der Provider nicht registriert, **schlägt > das gesamte Deployment fehl**. --- ## Empfohlene Instanzen-Struktur Pro Umgebung wird eine eigene DataBridge-Instanz (= Ressourcengruppe) benötigt. Als Regelfall werden **zwei Instanzen** empfohlen: | Instanz | Zweck | |---|---| | **Test** | Validierung von Mappings und Konfigurationsänderungen | | **Produktion** | Liveverbindung zwischen den Produktivsystemen | 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: | Merkmal | Wert | |---|---| | Laufzeit | .NET 10, Isolated Worker | | Azure Functions Runtime | v4 | | Betriebssystem | Windows | | App Service Plan | Y1 (Consumption) oder EP1–EP3 (Premium), wählbar beim Deployment | 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 | System | Lesen | Schreiben | Anmerkung | |---|:---:|:---:|---| | Dynamics 365 Business Central | ✅ | ✅ | Cloud und OnPremise | | Dynamics 365 / Dataverse | ✅ | ✅ | Change Tracking erforderlich (siehe unten) | | Microsoft Dynamics NAV | ✅ | ✅ | OnPremise, wahlweise Basic Auth oder NTLM | | Microsoft SQL Server | ⚠️ Preview | — | | | MySQL / MariaDB | ⚠️ Preview | — | | | Oracle Database | ⚠️ Preview | — | | | PostgreSQL | ⚠️ Preview | — | | 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](../../konnektoren/). --- ## 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. | System | Mindestrechte | |---|---| | **Dataverse** | Rolle „Systemadministrator" + mindestens eine Power Platform-Lizenz | | **Business Central** | Administrationsrechte + BC-Lizenz zugewiesen | ### 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: | Anwendungsbenutzer | Zweck | Benötigte Rechte | |---|---|---| | **Deployment-User** | Installation und Updates der DataBridge | Azure: Contributor auf Ressourcengruppe (bei aktiviertem `enableManagedIdentity`: **Owner** oder **User Access Administrator**, da Rollen zugewiesen werden) · Dataverse: S2S-Benutzer + Systemadministrator | | **Dataverse-User** | Datenaustausch mit Dataverse im laufenden Betrieb | Dataverse: S2S-Benutzer + Systemadministrator oder individuelle Sicherheitsrolle | | **BC-User** | Datenaustausch mit Business Central im laufenden Betrieb | BC: Registriert + individuelle Sicherheitsrolle | 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 > **Bei Installation über den Azure Marketplace entfällt dieser Abschnitt** > > Wird die DataBridge über den Marketplace-Assistenten installiert, ist **keine lokale > Software** erforderlich — die Einrichtung läuft vollständig im Azure Portal. Für das Deployment per **Bicep / Azure CLI** muss auf dem ausführenden Rechner installiert sein: | Software | Download | Mindestversion | |---|---|---| | **Azure CLI** | [learn.microsoft.com](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-windows) | aktuell | | **Bicep Extension** | über Azure CLI | ≥ 0.35 | Bicep-Extension installieren und verifizieren: ```bash 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.