# Release v2.0 > Umstellung auf .NET 10, Containerisierung mit Docker Compose, gepuffertes Logging und Custom Metrics. --- Site [llms.txt](/llms.txt) --- ## 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](../../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](../../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](../../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. | Setting | Typ | Standard | Beschreibung | |---|---|---|---| | `TELEMETRY_CONTROL` | String | *(leer)* | `TRACE_ALL` sendet alle Log-Einträge unabhängig vom Ergebnis; `TRACE_NONE` unterdrückt alle Einträge; `TRACE_SAMPLE` entspricht dem Standardverhalten (selektives Sampling, wie leer) | | `TELEMETRY_INFO_SAMPLE_RATE` | Integer (0–100) | `20` | Prozentsatz der Information-Einträge, die bei erfolgreichen Läufen an App Insights gesendet werden | ### 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.