Release v2.0

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.

• ASP.NET Core HTTP-Integration: Die Azure Functions App nutzt nun das ASP.NET Core-Integrationsmodell (ConfigureFunctionsWebApplication). Dies ist die empfohlene Methode ab .NET 8+ und ermöglicht vollständigere HTTP-Features.

• Custom Metrics: Die DataBridge sendet eigene, pre-aggregierte Metriken an Application Insights (Namespace DataBridge). Erste Metrik: ChangesDetected mit Dimension JobName — Anzahl erkannter Änderungen pro Job und GetChanges-Lauf, inkl. Null-Werten. Sichtbar im Metrics Explorer und in der Tabelle customMetrics; Details unter Betrieb → Logging.

• Gepuffertes Logging mit selektiver App-Insights-Weiterleitung: Alle Log-Einträge einer Funktionsausführung werden zunächst im Arbeitsspeicher gepuffert und erst am Ende der Ausführung — abhängig vom Ergebnis — selektiv an Azure Application Insights gesendet. Im Fehlerfall stehen damit auch alle Debug-Einträge rückwirkend zur Verfügung, ohne dass sie bei erfolgreichen Läufen Kosten verursachen. Das Verhalten lässt sich über die Umgebungsvariablen TELEMETRY_CONTROL und TELEMETRY_INFO_SAMPLE_RATE steuern. Eine vollständige Beschreibung befindet sich unter Betrieb → Logging.

• Trace-Level für Live-Diagnose: Log-Einträge auf Level Trace (LogTrace) werden nie an Application Insights gesendet — auch nicht bei Fehler-Läufen. Sie sind ausschließlich live sichtbar: lokal in der Konsole bzw. im Container-Log, in Azure im Log Stream der Function App. Details unter Betrieb → Logging.

Fehlerbehebungen & Verbesserungen

• Korrekte Zeitstempel und Request-Zuordnung für gepufferte Traces: Gepufferte Log-Einträge tragen in Application Insights jetzt den Zeitpunkt des ursprünglichen Log-Aufrufs statt des Sendens am Invocation-Ende. Zusätzlich wird operation_ParentId gesetzt, sodass Traces in der End-to-End-Transaktionsansicht korrekt unter dem Request der Invocation eingeordnet werden statt als verwaiste Einträge zu erscheinen.

• CheckList erkennt _-Felder korrekt: Die Diagnose-Funktion CheckList hat _-präfixierte Source-Felder (z.B. _wysa_address1_countryid) fälschlich als fehlende Attribute gemeldet. Diese Felder werden zur Laufzeit über SourceOperations aufgelöst und sind keine direkten Connector-Attribute — sie werden nun korrekt übersprungen.

• HTTP-Funktionen auf async umgestellt: GetInfo, CheckList und ExecuteHttpRequest verwendeten synchrone I/O-Operationen (WriteString, .Wait()), die mit dem ASP.NET Core-Modus nicht kompatibel sind. Alle drei Funktionen sind jetzt vollständig auf async/await umgestellt.

• Blockierendes Initialisierungsproblem in GetChanges behoben: Die bisherige Initialisierung blockierte den Thread (.Wait()). Dies wurde auf async/await umgestellt, womit Deadlocks unter Last verhindert werden.

• Versionsverwaltung in der Pipeline zentralisiert: Major- und Minor-Version (2.0) werden nun zentral in der Pipeline-Datei gepflegt statt verteilt in den Build-Templates.

• Automatischer Pipeline-Trigger: Die Build-Pipeline startet jetzt automatisch bei Push auf main und preview (vorher: nur manuell auslösbar).

• Global-Artifact-Veröffentlichung nur von main: Das NuGet-Paket dsyr-databridge wird nur noch beim Build aus dem main-Branch veröffentlicht, nicht mehr aus preview.

• NuGet-Pakete aktualisiert: Alle Abhängigkeiten wurden auf aktuelle Versionen angehoben (u.a. Azure.Identity 1.21, Microsoft.Data.SqlClient 7.0, MySql.Data 9.7, Npgsql 10.0.2, Oracle.ManagedDataAccess.Core 23.26.200).

• BcConnector: Duplikate bei HTTP-Fehlern verhindert: Beim Nachschlagen von Datensätzen (RetrieveRecordByKey, RetrieveRecordByFilter) wurde bei unerwarteten HTTP-Statuscodes bisher stillschweigend null zurückgegeben — das System legte daraufhin fälschlich einen neuen Datensatz an und erzeugte Duplikate. Beide Methoden werfen jetzt eine Exception mit dem konkreten Statuscode, wenn der Server weder Erfolg noch 404 zurückliefert.

• Veraltete ARM-Templates entfernt: Legacy-ARM-Deployment-Profile und veraltete AppInsights-ARM-Dateien wurden aus dem Repository entfernt.

• Docker-Build-Kontext bereinigt: Das .dockerignore wurde erweitert, sodass nur noch der tatsächlich benötigte Anwendungscode ins Image gelangt (.git/, docfx/, bicep/, cicd/, bruno/ und lokale Start-Scripts werden nun explizit ausgeschlossen).

Installationshinweise

Neue / geänderte App-Settings (Azure Function)

Folgende neue App-Settings stehen zur Verfügung. Beide sind optional — ohne Konfiguration gelten die dokumentierten Standardwerte.

Neue Azure-Ressourcen (Bicep)

Es wurden keine neuen Azure-Ressourcen hinzugefügt.

Breaking Changes & Migrationsschritte

1. Laufzeitversion auf .NET 10 aktualisieren Die Azure Function App muss auf .NET 10 (Isolated Worker) aktualisiert werden. Im Azure Portal: Function App → Konfiguration → Allgemeine Einstellungen → .NET-Version → 10 (LTS, Isolated) Im Bicep-Script wird netFrameworkVersion automatisch auf 10.0 gesetzt — ein Redeployment über die Pipeline genügt.

2. Container-Image aktualisieren Falls die DataBridge containerisiert betrieben wird: Das neue Image basiert auf .NET 10. Tag: acrwysatest.azurecr.io/containered-connector:v2.0.0 Bestehende Images auf .NET 8 Basis sind nicht kompatibel und müssen ersetzt werden.

3. Build-Agent in eigenen Pipelines prüfen Die offizielle Pipeline nutzt jetzt windows-2025 als Build-Agent. Eigene abgeleitete Pipelines sollten entsprechend angepasst werden.