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

Allgemein

• 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).

• 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).

BC

• 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.

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.