Installation
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.
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
| Feld | Bedeutung |
|---|---|
| Region | Azure-Region, in der alle Ressourcen angelegt werden |
| Shortname for DataBridge | Namensbestandteil für alle Ressourcen dieser Instanz |
Aus dem Kurznamen werden sämtliche Ressourcennamen abgeleitet — Bindestriche werden dabei intern entfernt:
st<name> (Storage) · sb<name> (Service Bus) · appi-<name> (Application Insights) ·
asp-<name> (App Service Plan) · func-<name> (Function App) · dash-<name> (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 |
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.
Alle Telemetrie-Einstellungen können auf den Vorgabewerten bleiben und später jederzeit in den 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 |
6. Storage Account
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) |
Anschließend über Überprüfen und erstellen das Deployment starten.
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
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.
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" |
Statt alle Werte auf der Kommandozeile zu übergeben, können sie in einer
.bicepparam-Datei gepflegt und mit --parameters <datei>.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-<name> | Windows, .NET 10 Isolated Worker, Functions v4, FTPS-only |
| App Service Plan | asp-<name> | Y1 (Consumption) oder EP1–EP3 (Premium) |
| Storage Account | st<name> | StorageV2, Standard_LRS, TLS 1.2 |
| Service Bus Namespace | sb<name> | SKU Basic, mit allen sieben Queues |
| Application Insights | appi-<name> | 90 Tage Aufbewahrung |
| Grafana-Dashboard | dash-<name> | Wird immer mit angelegt, kein Opt-out |
| Alerts + Action Group | ag-<name> | Nur bei enableAlerts = true |
Service-Bus-Queues:
sbqexport · sbqhighexport · sbqlowexport · sbqignored ·
sbqtransitivehigh · sbqtransitivestandart · sbqtransitivelow
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.2.0
Option B: Zip-Upload per Azure Portal
- Im Azure Portal die Function App öffnen
- Entwicklungstools → Erweiterte Tools (Kudu) öffnen
- In Kudu: Tools → Zip Push Deploy
- Die bereitgestellte
.zip-Datei per Drag & Drop hochladen - 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 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"
}
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.