# Installation > Die DataBridge über den Azure Marketplace oder per Bicep in Azure einrichten. --- Site [llms.txt](/llms.txt) --- Für die Installation gibt es zwei Wege: | Weg | Wann geeignet | |---|---| | **[Azure Marketplace](#weg-1--azure-marketplace-empfohlen)** | Regelfall. Läuft vollständig im Azure Portal, keine lokale Software nötig. | | **[Bicep / Azure CLI](#weg-2--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. ![Ressourcengruppe anlegen](/images/AzureSetup_Step1_ResourceGroup_Add.png) ### 2. DataBridge aus dem Marketplace auswählen In der Ressourcengruppe **Erstellen** wählen und im Marketplace nach der WYSA DataBridge suchen. ![DataBridge im Marketplace auswählen](/images/AzureSetup_Step2_Select_wysa_DataBridge.png) ### 3. Region und Kurzname festlegen | Feld | Bedeutung | |---|---| | **Region** | Azure-Region, in der alle Ressourcen angelegt werden | | **Shortname for DataBridge** | Namensbestandteil für **alle** Ressourcen dieser Instanz | ![Region und Kurzname](/images/AzureSetup_Step3_Select_Region_And_ShortName.png) > **Der Kurzname prägt alle Ressourcennamen** > > Aus dem Kurznamen werden sämtliche Ressourcennamen abgeleitet — Bindestriche werden dabei > intern entfernt: > > `st` (Storage) · `sb` (Service Bus) · `appi-` (Application Insights) · > `asp-` (App Service Plan) · `func-` (Function App) · `dash-` (Dashboard) > > Der Name muss innerhalb Azure eindeutig sein und sollte die Umgebung erkennbar machen > (z. B. `kunde-databridge-test`). ### 4. Produkteinstellungen Unter **Product Settings** werden die fachlichen Einstellungen gruppiert: | Bereich | Einstellungen | |---|---| | **Function Settings** | `GetChanges Timer Expression` — Taktung des Quellabrufs (Vorgabe: alle 15 Sekunden) | | **Telemetry** | Sampling-Override sowie die drei Sampling-Raten für Logs und Abhängigkeiten | | **Alert** | Alerts aktivieren, Benachrichtigungs-E-Mail und die vier Dead-Letter-Schwellwerte | | **Preview** | `SkipOutdatedMessages` | ![Skipping und Alerts](/images/AzureSetup_Step4_Define_Skipping_And_Alerts.png) > **Alerts sind standardmäßig aus** > > `Enable Alerts` steht auf **No**. Wird es auf **Yes** gesetzt, ist zusätzlich eine > Benachrichtigungs-E-Mail einzutragen — sonst werden keine Alerts angelegt. Details: > [Monitoring & Alerts](../../betrieb/monitoring/). Alle Telemetrie-Einstellungen können auf den Vorgabewerten bleiben und später jederzeit in den [Umgebungsvariablen](../umgebungsvariablen/) angepasst werden. ### 5. Service Bus | Feld | Vorgabe | Bedeutung | |---|---|---| | **Maximum Delivery Count** | `3` | Zustellversuche, bevor eine Nachricht in die Dead-Letter-Queue geht | | **Message Time To Live (TTL)** | `P14D` | Aufbewahrungszeit einer Nachricht (ISO 8601) | | **Lock Duration** | `PT30S` | Sperrdauer während der Verarbeitung | ![Service-Bus-Einstellungen](/images/AzureSetup_Step5_Define_ServiceBus_Settings.png) ### 6. Storage Account ![Storage Account](/images/AzureSetup_Step6_Define_StorageAccount.png) Als Speicherkonto-Typ steht ausschließlich `StorageV2` zur Verfügung. ### 7. App Service Plan | Feld | Vorgabe | Bedeutung | |---|---|---| | **Maximum Scale-Out Count** | `12` | Obergrenze für parallele Instanzen | | **App Service Plan SKU** | `Consumption (Y1)` | Alternativ `Premium (EP1)` bis `Premium (EP3)` | ![App Service Plan](/images/AzureSetup_Step7_Define_AppPlan.png) Anschließend über **Überprüfen und erstellen** das Deployment starten. > **Erneutes Durchlaufen bei einem Update** > > Der Assistent kann für ein Update erneut ausgeführt werden. Solange die Vorgabewerte > übernommen werden, ergibt sich keine Änderung an bestehenden Einstellungen. --- ## 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 ```bash 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 ```bash az account show ``` Vergleiche die angezeigte Abonnement-ID mit der ID im Azure Portal. Falls mehrere Abonnements vorhanden sind, das richtige setzen: ```bash az account set --subscription "" ``` ### 4. Ressourcen deployen ```bash az deployment group create --template-file ./bicep/main.bicep --resource-group --parameters name= -c ``` Das Flag `-c` zeigt eine Vorschau der Änderungen an. Mit `Y` oder `J` bestätigen. > **Instanzname immer setzen** > > Der Parameter `name` wird als Namensbestandteil für **alle** angelegten Ressourcen > verwendet. Der Standardwert lautet `customername-databridge` und ist unbedingt zu > überschreiben — andernfalls kommt es zu Namenskonflikten mit anderen Installationen. ### Bicep-Parameter im Überblick **Infrastruktur:** | Parameter | Standardwert | Beschreibung | |---|---|---| | `name` | `customername-databridge` | Namensbestandteil für alle Ressourcen. **Immer überschreiben.** | | `location` | Region der Ressourcengruppe | Zielregion für alle Ressourcen | | `storageKind` | `StorageV2` | Speicherkonto-Typ (einziger erlaubter Wert) | | `appServiceSku` | `Y1` | `Y1` (Consumption) oder `EP1`–`EP3` (Premium) | | `functionScaleLimit` | `12` | Obergrenze für parallele Instanzen | | `maxDeliveryCount` | `3` | Zustellversuche pro Nachricht (1–100) | | `defaultMessageTimeToLive` | `P14D` | Aufbewahrungszeit für Nachrichten (ISO 8601) | | `lockDuration` | `PT30S` | Sperrdauer während der Verarbeitung (ISO 8601) | | `tagsByResource` | *(leer)* | Tags je Ressourcentyp | **Laufzeit und Telemetrie:** | Parameter | Standardwert | Beschreibung | |---|---|---| | `getChangesTimerExpression` | `*/15 * * * * *` | Taktung des Quellabrufs | | `skipOutdatedMessages` | `false` | Nachrichten mit älterem Quell-Zeitstempel überspringen | | `telemetryControl` | `TRACE_SAMPLE` | `TRACE_SAMPLE`, `TRACE_ALL` oder `TRACE_NONE` | | `telemetryInfoSampleRate` | `20` | Anteil der Information-Einträge bei erfolgreichen Läufen (%) | | `telemetryDependencySampleRate` | `10` | Anteil erfolgreicher, schneller Abhängigkeits-Aufrufe (%) | | `telemetryDependencySlowMs` | `2000` | Schwellwert für „langsam" in Millisekunden | **Alerts:** | Parameter | Standardwert | Beschreibung | |---|---|---| | `enableAlerts` | `false` | Alerts für Dead-Letter-Queue und Queue-Länge anlegen | | `notificationEmail` | *(leer)* | Empfänger der Alert-Benachrichtigungen. Nur bei `enableAlerts = true` erforderlich. | | `dlqLowThreshold` | `1` | Schwellwert Severity „Informational" | | `dlqMediumThreshold` | `50` | Schwellwert Severity „Warning" | | `dlqHighThreshold` | `200` | Schwellwert Severity „Error" | | `dlqCriticalThreshold` | `500` | Schwellwert Severity „Critical" | > **Parameter in einer Datei ablegen** > > Statt alle Werte auf der Kommandozeile zu übergeben, können sie in einer > `.bicepparam`-Datei gepflegt und mit `--parameters .bicepparam` übergeben werden. > Eine kommentierte Vorlage liegt unter `bicep/params/databridge.sample.bicepparam`. --- ## Was angelegt wird Nach erfolgreichem Deployment existieren in der Ressourcengruppe: | Ressource | Name | Details | |---|---|---| | **Function App** | `func-` | Windows, .NET 10 Isolated Worker, Functions v4, FTPS-only | | **App Service Plan** | `asp-` | Y1 (Consumption) oder EP1–EP3 (Premium) | | **Storage Account** | `st` | StorageV2, Standard_LRS, TLS 1.2 | | **Service Bus Namespace** | `sb` | SKU Basic, mit allen sieben Queues | | **Application Insights** | `appi-` | 90 Tage Aufbewahrung | | **Grafana-Dashboard** | `dash-` | Wird immer mit angelegt, kein Opt-out | | **Alerts + Action Group** | `ag-` | Nur bei `enableAlerts = true` | **Service-Bus-Queues:** `sbqexport` · `sbqhighexport` · `sbqlowexport` · `sbqignored` · `sbqtransitivehigh` · `sbqtransitivestandart` · `sbqtransitivelow` > **Schreibweise `sbqtransitivestandart`** > > Der Name der Standard-Transitive-Queue endet auf `-standart`. So wird sie angelegt und so > sucht die DataBridge sie. **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: | Reihenfolge | Tabelle | Inhalt | |---|---|---| | 1 | `connections` | Zugangsdaten für alle Quell- und Zielsysteme | | 2 | `mappings` | Feld-Mappings zwischen Quell- und Zieltabellen | | 3 | `jobs` | Synchronisations-Jobs (welche Tabelle, welche Richtung, welcher Schedule) | | 4 | `watermark` | Wird zur Laufzeit automatisch befüllt — kein manueller Eintrag nötig | 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](../../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](../umgebungsvariablen/). --- ## Installation prüfen Sobald Konfigurationstabellen und Umgebungsvariablen gesetzt sind, kann die Installation geprüft werden: ```http GET https://func-.azurewebsites.net/api/GetInfo?code= ``` Eine erfolgreiche Antwort sieht so aus: ```json { "Version": "2.1.2026.802" } ``` > **Der Function-Key ist erforderlich** > > `GetInfo` ist mit Function-Level-Authentifizierung geschützt. Ohne den Parameter `code` > antwortet der Endpunkt mit **401 Unauthorized**. > > Den Schlüssel findet man im Azure Portal unter **Function App → Funktionen → `GetInfo` → > Funktionsschlüssel**. 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.