Gegen echtes Azure debuggen

Hier läuft kein Podman-Stack mit — die lokal gestartete DataBridge verbindet sich direkt mit einem echten Storage Account, einem echten Service Bus Namespace und den echten Quell-/Zielsystemen (BC, CE, NAV, SQL). Das ist der klassische Weg, um ein Problem aus einer konkreten Umgebung (z. B. dsyr-wysatest) lokal nachzuvollziehen oder mit dem Debugger zu untersuchen.

local.settings.json vorbereiten

1. src/DataBridge/sample.local.settings.json nach src/DataBridge/local.settings.json kopieren (falls noch nicht vorhanden — die Datei ist in .gitignore, geht also nicht versehentlich in einen Commit).
2. Die Platzhalter durch echte Werte aus dem Azure Portal bzw. Key Vault ersetzen: AzureWebJobsStorage (Storage-Account-Connection-String), ExportQueueServiceBus (Service-Bus-Connection-String) sowie die Connection-Strings/Secrets der Quell- und Zielsysteme, je nachdem was getestet werden soll. Diese Werte niemals committen und nicht in Chats/Tickets einfügen.
3. Wenn enableManagedIdentity in der Zielumgebung aktiv ist (siehe Identity-Verbindungen bzw. SettingsService), fehlen dort Connection-Strings ganz — stattdessen AzureWebJobsStorage__accountName und ExportQueueServiceBus__fullyQualifiedNamespace setzen und lokal per az login angemeldet sein, damit DefaultAzureCredential greift. Das erfordert eine Rollenzuweisung für den eigenen Benutzer auf Storage und Service Bus (Data-Rollen, nicht nur Management), sonst schlägt der Verbindungstest beim Start fehl.

In der IDE starten

Identisch zum Podman-Host-Modus — alle drei IDEs nutzen dasselbe Projekt src/DataBridge/DataBridge.csproj und dasselbe Profil DataBridge aus src/DataBridge/Properties/launchSettings.json (startet mit --port 7062).

Rider

1. Lösung src/DataBridge.slnx öffnen.
2. Run-Profil DataBridge auswählen, dann auf das Käfer-Symbol (Debug) klicken bzw. Shift+F9.
3. Breakpoints setzen, z. B. im Connector des Systems, das gerade untersucht wird.

Visual Studio

1. src/DataBridge.slnx öffnen, DataBridge als Startprojekt setzen.
2. Profil DataBridge im Dropdown neben dem Play-Pfeil wählen, dann F5.
3. Breakpoints setzen.

VS Code

1. Terminal in src/DataBridge öffnen, func start ausführen (liest local.settings.json automatisch).
2. Mit C# Dev Kit: Debug: Attach to .NET Process auf den laufenden func-Prozess. Mit der Azure Functions-Erweiterung genügt F5 direkt im Projektordner.
3. Breakpoints setzen.

Der MCP-Server databridge (nicht databridge-dev) aus .mcp.json zeigt per Voreinstellung auf http://localhost:7062 — passt also automatisch, solange kein DATABRIDGE_MCP_URL gesetzt ist, das auf eine andere Instanz zeigt.

Logging

Hier läuft Logging doppelt, weil local.settings.json einen echten APPLICATIONINSIGHTS_CONNECTION_STRING enthält (aus sample.local.settings.json übernommen und mit echten Werten gefüllt, siehe oben):

1. Direkt in der IDE-Konsole — wie im Host-Modus gegen Podman: Rider-Run-Fenster, Visual-Studio-Ausgabefenster bzw. das func start-Terminal in VS Code. host.json setzt Trace für DataBridge/Function, also die volle Ausführlichkeit, unabhängig von Application Insights.
2. In der echten Application Insights-Instanz — mit denselben Regeln wie in Produktion: gepuffertes Sampling, TELEMETRY_INFO_SAMPLE_RATE, TELEMETRY_CONTROL, siehe Betrieb → Logging. Trace-Einträge erreichen Application Insights dabei nie — nur die IDE-Konsole zeigt sie.

GetChanges/Process*QueueItems steuern

Anders als im Podman-Host-Modus gibt es hier keinen up.sh-Schalter — die App-Settings stehen direkt in local.settings.json und werden von Hand gesetzt:

{
  "Values": {
    "AzureWebJobs.GetChanges.Disabled": "true",
    "AzureWebJobs.ProcessStandardQueueItems.Disabled": "true",
    "AzureWebJobs.ProcessHighPriorityQueueItems.Disabled": "true",
    "AzureWebJobs.ProcessLowPriorityQueueItems.Disabled": "true"
  }
}

"true" deaktiviert die jeweilige Funktion, "false" bzw. Weglassen aktiviert sie. Vor dem Debuggen bewusst entscheiden:

• Nur einen bestimmten Job untersuchen, sonst nichts verarbeiten: alle vier auf "true" lassen und stattdessen gezielt POST /api/ExecuteJob aufrufen (löst GetChanges für einen einzelnen Job aus, unabhängig vom Timer).
• Den echten Timer-/Queue-Ablauf beobachten: die passenden Einträge auf "false" setzen. Das bedeutet aber, dass die lokal debuggte Instanz zusätzlich zu jeder produktiv laufenden Instanz derselben Umgebung Änderungen erkennt bzw. Queue-Nachrichten verarbeitet.

Podman- und Cloud-Settings parallel halten

src/DataBridge/local.settings.json ist für beide Debug-Varianten dieselbe Datei — wer öfter zwischen Podman-Host-Modus und Cloud-Debugging wechselt, verliert sonst bei jedem up.sh --host die mühsam eingetragenen echten Zugangsdaten (siehe Warnhinweis oben). Zwei Optionen:

Eigene Kopie + Copy-Befehl (empfohlen, geringer Aufwand). Einmalig eine zweite, selbst gepflegte Datei anlegen, die up.sh/up.ps1 nie anfassen — z. B. src/DataBridge/local.settings.cloud.json (Kopie von sample.local.settings.json mit echten Werten, siehe oben). Diese Namensform (local.settings.*.json) ist bereits über src/DataBridge/.gitignore ausgeschlossen, landet also nicht versehentlich in einem Commit. Vor dem Cloud-Debuggen einmal darüberkopieren:

• Windows (PowerShell)
• Linux / macOS

Copy-Item src\DataBridge\local.settings.cloud.json src\DataBridge\local.settings.json -Force

cp src/DataBridge/local.settings.cloud.json src/DataBridge/local.settings.json

Der Rückweg ist kein manueller Schritt: Der nächste dev/up.sh --host/dev\up.ps1 -HostMode überschreibt local.settings.json ohnehin automatisch wieder aus der Podman-Vorlage (dev/local.settings.dev.json).

Getrennter Checkout/Git-Worktree. Für häufigen, unterbrechungsfreien Wechsel: einen zweiten Checkout des Repos ausschließlich fürs Cloud-Debuggen anlegen, mit eigener, dauerhaft gefüllter local.settings.json, komplett getrennt vom Ordner, in dem dev/up.sh --host läuft. Mehr Verwaltungsaufwand beim Einrichten, dafür kein Kopieren mehr im Alltag — einfach die passende IDE im jeweils anderen Ordner öffnen.