Umgebungsvariablen
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.
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.
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. 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.
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. |
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.
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.
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.
| 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 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.<Funktionsname>.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.
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.
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 |
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>.vault.azure.net/secrets/<name>/)
Diese Referenz wird direkt als Wert der jeweiligen Umgebungsvariable eingetragen. Azure löst sie zur Laufzeit automatisch auf — ohne Änderungen am Code.
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:
- Key Vault anlegen und das Secret hinterlegen
- 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.