# Umgebungsvariablen > Alle Konfigurationsparameter der DataBridge Function App — mit Standardwerten und Erläuterung. --- Site [llms.txt](/llms.txt) --- Die DataBridge Function App wird über **Anwendungseinstellungen** (Application Settings) konfiguriert. Diese sind im Azure Portal unter **Function App → Einstellungen → Umgebungsvariablen** zu finden und zu bearbeiten. > **Seit v2.1 bereits beim Deployment setzbar** > > Der Timer-Ausdruck und alle vier Telemetrie-Einstellungen lassen sich direkt beim > Deployment vorgeben — als Bicep-Parameter (Beispiele in > `bicep/params/databridge.sample.bicepparam`) oder im Marketplace-Assistenten unter > **Product Settings**. Ein nachträgliches Pflegen in den App-Settings ist damit nur noch > für Änderungen im laufenden Betrieb nötig. > **Jede Änderung startet die Function App neu** > > Das Speichern einer Anwendungseinstellung löst einen Neustart aus. Laufende Verarbeitungen > werden abgebrochen; die betroffenen Queue-Nachrichten werden erneut zugestellt. --- ## Infrastruktur-Verbindungen Diese Variablen verbinden die Function App mit den zugehörigen Azure-Diensten. Sie werden durch das Deployment automatisch befüllt. | Variable | Pflicht | Beschreibung | |---|:---:|---| | `AzureWebJobsStorage` | ✅¹ | Connection String zum Azure Storage Account (Table Storage für die Konfiguration + Function-interner Storage). | | `ExportQueueServiceBus` | ✅¹ | Connection String zum Service Bus Namespace (alle Verarbeitungs-Queues) | | `APPLICATIONINSIGHTS_CONNECTION_STRING` | faktisch | Connection String zu Application Insights. Ohne den Wert **startet die DataBridge trotzdem**, gibt aber nur eine Warnung aus und sendet keinerlei Telemetrie — kein Logging, keine Metriken, keine Fehlerdiagnose. | ¹ **Schlüssel- oder identitätsbasiert.** Standardmäßig werden die beiden Connection Strings gesetzt. Zusätzlich setzt das Deployment in diesem Modus `TARGET_BASED_SCALING_ENABLED=0`: Target-based Scaling ist damit abgeschaltet, der Host skaliert direkt über den Metrics Monitor und die entsprechende Warnung im Log entfällt. Ist der Preview-Schalter `enableManagedIdentity` (Bicep) aktiv, entfallen sie und werden durch die identitätsbasierten Varianten ersetzt — die Function nutzt dann die Managed Identity: | Variable (Identity-Modus) | Beschreibung | |---|---| | `AzureWebJobsStorage__accountName` | Name des Storage Accounts. Der Functions-Host leitet Blob/Queue/Table-Endpunkte daraus ab und authentifiziert über die Managed Identity. | | `ExportQueueServiceBus__fullyQualifiedNamespace` | Voll qualifizierter Service-Bus-Namespace (z. B. `sbfoo.servicebus.windows.net`) für den identitätsbasierten Zugriff. | Lokal (`local.settings.json`) bleiben die schlüsselbasierten Connection Strings maßgeblich. > **`ExportQueueServiceBus` steht an zwei Stellen** > > Das Deployment hinterlegt den Service-Bus-Connection-String **doppelt**: einmal als > Anwendungseinstellung und einmal als Eintrag unter *Connection strings* (Typ `ServiceBus`). > > Die DataBridge sucht den Wert in dieser Reihenfolge: > `ConnectionStrings:ExportQueueServiceBus` → `SERVICEBUSCONNSTR_ExportQueueServiceBus` → > `SQLCONNSTR_…` → `CUSTOMCONNSTR_…` → Anwendungseinstellung ohne Präfix. > > Wird der Namespace ausgetauscht, sind **beide** Stellen anzupassen — sonst greift > weiterhin der alte Wert aus der höher priorisierten Quelle. > > Im Identity-Modus (`enableManagedIdentity`) entfällt das: dort gibt es keinen > Connection-String-Eintrag, sondern nur `ExportQueueServiceBus__fullyQualifiedNamespace`. --- ## Laufzeit-Einstellungen | Variable | Typ | Standardwert | Pflicht | Beschreibung | |---|---|---|:---:|---| | `GetChangesTimerExpression` | CRON (6-stellig) | `*/15 * * * * *` | ✅ | Taktung des `GetChanges`-Timers. Bei einer Neuinstallation alle 15 Sekunden. | | `SkipOutdatedMessages` | Boolean | `false` | — | Wenn `true`: Nachrichten, deren Quell-Zeitstempel älter ist als der Zieldatensatz, werden nicht verarbeitet, sondern nach `sbqignored` verschoben. | > **`GetChangesTimerExpression` ist zwingend** > > Die Variable hat **keinen** Standardwert im Code — der Wert kommt aus dem Deployment. > Fehlt die Einstellung, schlägt die Timer-Bindung fehl und `GetChanges` läuft gar nicht. > **`SkipOutdatedMessages` wirkt nur bei D365-Systemen** > > Die Einstellung wird ausschließlich von den Konnektoren für Business Central, Dataverse > und NAV ausgewertet — bei SQL-Quellen hat sie keine Wirkung. Zusätzlich greift sie nur, > wenn im Job ein `WatermarkField` gesetzt ist. > > Nach einem Standard-Deployment steht der Wert auf `false`. Nur wenn die Variable > **vollständig fehlt**, gilt der Code-Fallback `true` — im Marketplace-Assistenten liegt > die Option unter **Product Settings → Preview**. ### CRON-Ausdruck — Format Der CRON-Ausdruck nutzt das **6-stellige NCrontab-Format** (inkl. Sekunden): ``` ┌─────────── Sekunde (0–59) │ ┌───────── Minute (0–59) │ │ ┌─────── Stunde (0–23) │ │ │ ┌───── Tag (1–31) │ │ │ │ ┌─── Monat (1–12) │ │ │ │ │ ┌─ Wochentag (0–6, Sonntag=0) │ │ │ │ │ │ */15 * * * * * → alle 15 Sekunden (Vorgabe) 0 */2 * * * * → alle 2 Minuten 0 */5 * * * * → alle 5 Minuten 0 0 */1 * * * → stündlich ``` Einzelne Jobs können über das Feld `Schedule` einen eigenen, seltener greifenden Zeitplan bekommen — siehe [Jobs](../../konfiguration/jobs/#schedule--jobbezogener-cron-ausdruck). --- ## Logging & Telemetrie Die DataBridge steuert ihr Telemetrie-Volumen über zwei Mechanismen: gepuffertes Logging für Log-Einträge und Sampling für ausgehende Aufrufe. Ausführlich beschrieben unter [Betrieb → Logging](../../betrieb/logging/). | Variable | Typ | Standardwert | Beschreibung | |---|---|---|---| | `TELEMETRY_CONTROL` | String | `TRACE_SAMPLE` | Globaler Override für **beide** Sampling-Mechanismen. Werte: `TRACE_SAMPLE` (selektives Sampling, entspricht auch einem leeren Wert), `TRACE_ALL` (sendet alles), `TRACE_NONE` (unterdrückt alles). | | `TELEMETRY_INFO_SAMPLE_RATE` | Integer 0–100 | `20` | Anteil der `Information`-Einträge, die bei **erfolgreichen** Läufen gesendet werden. Bei Läufen mit Warnungen oder Fehlern immer 100 %. | | `TELEMETRY_DEPENDENCY_SAMPLE_RATE` | Integer 0–100 | `10` | Anteil der **erfolgreichen und schnellen** Aufrufe an Quell- und Zielsysteme (D365 OData, SQL, Table Storage, Service Bus), die gesendet werden. Fehlgeschlagene und langsame Aufrufe sind davon nicht betroffen. | | `TELEMETRY_DEPENDENCY_SLOW_MS` | Integer (ms) | `2000` | Schwellwert, ab dem ein Aufruf als „langsam" gilt und immer gesendet wird — auch bei Erfolg. | ### Telemetrie-Verhalten im Überblick | Lauf-Ergebnis | Trace | Debug | Information | Warning | Error | |---|:---:|:---:|:---:|:---:|:---:| | Fehlerfreier Lauf | nie | — | ~20 % (konfigurierbar) | ✅ | ✅ | | Lauf mit Warnungen | nie | — | ✅ alle | ✅ | ✅ | | Lauf mit Fehler | nie | ✅ alle | ✅ alle | ✅ | ✅ | `Trace`-Einträge erreichen Application Insights **grundsätzlich nie** — auch nicht bei Fehler-Läufen. Sie sind ausschließlich live im Log Stream der Function App bzw. im Container-Log sichtbar. ### Abhängigkeiten | Aufruf | Wird gesendet | |---|---| | Fehlgeschlagen | immer vollständig | | Langsam (≥ `TELEMETRY_DEPENDENCY_SLOW_MS`) | immer vollständig | | Erfolgreich und schnell | anteilig gemäß `TELEMETRY_DEPENDENCY_SAMPLE_RATE` | Die Entscheidung fällt hier **pro Aufruf** und nicht pro Funktionsausführung — ein fehlgeschlagener Lauf enthält deshalb nicht zwangsläufig die erfolgreichen Aufrufe davor. > **`TRACE_ALL` nicht dauerhaft setzen** > > `TRACE_ALL` deaktiviert beide Sampling-Mechanismen und kann das Datenvolumen um ein > Vielfaches erhöhen — bis zum Erreichen der Tagesobergrenze, ab der gar keine Telemetrie > mehr ankommt. Nur gezielt für die Dauer einer Analyse aktivieren. --- ## Funktionen gezielt deaktivieren Einzelne Azure Functions können ohne Redeployment deaktiviert werden. Das ist nützlich, um z. B. die Quellabruf-Funktion zu stoppen, ohne die Queue-Verarbeitung zu unterbrechen. | Variable | Betrifft | Wert zum Deaktivieren | |---|---|---| | `AzureWebJobs.GetChanges.Disabled` | Timer-Funktion (Quellabruf) | `true` | | `AzureWebJobs.ProcessStandardQueueItems.Disabled` | Standard-Prioritäts-Queue | `true` | | `AzureWebJobs.ProcessHighPriorityQueueItems.Disabled` | Hoch-Prioritäts-Queue | `true` | | `AzureWebJobs.ProcessLowPriorityQueueItems.Disabled` | Niedrig-Prioritäts-Queue | `true` | Das Namensschema `AzureWebJobs..Disabled` gilt für **jede** Function der App. Neben den vier betrieblich relevanten oben sind das: `ExecuteJob` · `ExecuteHttpRequest` · `GetInfo` · `Validate` · `CheckList` · `StartGetChangesOrchestration` · `GetChangesOrchestrator` · `GetChangesActivity` · `JobState` Die letzten vier gehören zur optionalen Durable-Orchestrierung, die im Regelbetrieb ohnehin nicht aktiv ist. > **Diese Variablen legt das Deployment nicht an** > > Die Toggles sind weder Teil des Bicep-Deployments noch des Marketplace-Assistenten. Sie > müssen bei Bedarf manuell in den Anwendungseinstellungen angelegt und danach wieder > entfernt bzw. auf `false` gesetzt werden. > **Tipp: Wartungsfenster** > > Um während einer Wartung keine neuen Nachrichten zu erzeugen, `GetChanges.Disabled = true` > setzen. Die Queue-Funktionen können aktiv bleiben und bereits vorhandene Nachrichten > weiter verarbeiten. --- ## Plattform-Einstellungen — nicht verändern Diese Werte setzt das Deployment. Sie steuern die Azure-Functions-Laufzeit selbst und haben keinen fachlichen Bezug zur DataBridge: | Variable | Wert | Bedeutung | |---|---|---| | `FUNCTIONS_EXTENSION_VERSION` | `~4` | Version der Azure-Functions-Runtime | | `FUNCTIONS_WORKER_RUNTIME` | `dotnet-isolated` | Worker-Modell (.NET Isolated Worker) | | `WEBSITE_CONTENTAZUREFILECONNECTIONSTRING` | = `AzureWebJobsStorage` | Ablage des Function-Contents | | `WEBSITE_RUN_FROM_PACKAGE` | `1` | Ausführung direkt aus dem Deployment-Paket | > **Änderungen führen zu einer nicht startfähigen App** > > Diese Einstellungen sind nicht dafür gedacht, angepasst zu werden. Ein abweichender Wert > kann dazu führen, dass die Function App gar nicht mehr startet oder keine Funktionen mehr > registriert werden. ### Nur im Container-Betrieb | Variable | Wert | Bedeutung | |---|---|---| | `AzureWebJobsSecretStorageType` | `files` | Weist die Runtime an, Function-Keys ins Dateisystem zu schreiben. Ohne diesen Wert sind HTTP-Trigger mit Function-Authentifizierung nicht aufrufbar. | --- ## Key Vault (optional) Statt Connection Strings direkt in den Anwendungseinstellungen zu speichern, können diese in einem **Azure Key Vault** hinterlegt werden. Die Function App referenziert das Secret dann per Key Vault Reference: ``` @Microsoft.KeyVault(SecretUri=https://.vault.azure.net/secrets//) ``` Diese Referenz wird direkt als Wert der jeweiligen Umgebungsvariable eingetragen. Azure löst sie zur Laufzeit automatisch auf — ohne Änderungen am Code. > **Key Vault wird nicht mitdeployt** > > Das Bicep-Deployment legt **keinen Key Vault** an. Die **System Managed Identity** der > Function App wird hingegen seit v2.2 **automatisch** angelegt. Vor der Nutzung des Key Vault > sind daher manuell einzurichten: > > 1. Key Vault anlegen und das Secret hinterlegen > 2. Der (bereits vorhandenen) **System Managed Identity** der Function App die Berechtigung > **Get** auf die Key Vault Secrets erteilen > > Ohne diese Schritte bleibt die Referenz unaufgelöst und die App startet mit einem > fehlerhaften Verbindungswert. Für die Zugangsdaten zu Quell- und Zielsystemen gibt es einen **zweiten, davon unabhängigen Weg** über den Parameter `keyVaultUrl` im Verbindungs-JSON — siehe [Verbindungen](../../konfiguration/verbindungen/#key-vault--verbindungsdaten-sicher-speichern).