Release v2.2

Was ist neu

Neue Funktionen

• Neuer Connector: generische REST-API über OpenAPI-Spezifikation: Neben BC, CE, NAV und den SQL-Connectoren steht jetzt ein generischer HTTP-Connector zur Verfügung, der ein beliebiges REST-API anhand seiner OpenAPI-/Swagger-Beschreibung anbindet (neuer Verbindungstyp OPENAPI). Damit lassen sich Systeme ohne eigenen Connector über ihr veröffentlichtes API-Schema anbinden, statt eine dedizierte Implementierung zu benötigen. Details, Konfigurationsbeispiel und unterstützte Auth-Methoden siehe OpenAPI-Connector.

• Neue Authentifizierungsart „API-Key“ für HTTP-Connectoren: Zusätzlich zu Basic-Auth und OAuth2 unterstützen alle HTTP-basierten Connectoren (BC, NAV, OpenAPI) jetzt die Authentifizierung über einen statischen API-Key, der als Header an jede Anfrage angehängt wird (apiKeyHeader / apiKeyValue in der Connection). Zusätzlich kann der OAuth2-Token-Endpunkt über tokenUrl frei konfiguriert werden, statt fest auf den Microsoft-Login-Endpunkt zu zeigen — relevant für Systeme mit eigenem oder abweichendem Token-Server.

• Action-Jobs (InvokeAction): Jobs können jetzt statt eines CRUD-Datenabgleichs eine einzelne benannte Aktion auf dem Zielsystem auslösen (z. B. eine OpenAPI-Action/operationId oder einen D365CE-OrganizationRequest). Ein solcher Job benötigt kein Mapping in der Mapping-Tabelle — die Aktion und ihre Parameter werden direkt aus der Queue-Nachricht und dem Job selbst gebildet. Siehe Action — welche Änderungsarten gelesen werden.

• Ressourcenpfad direkt am Job konfigurierbar: Jobs können nun ihre Quell- und Zielressource (Tabelle, Entität oder Pfad) direkt in den neuen Job-Feldern Source/Target tragen, statt sie zwingend über die Mapping-Tabelle zu beziehen. Bestehende, ausschließlich über die Mapping-Tabelle konfigurierte Jobs funktionieren unverändert weiter; ohne Eintrag in Source/Target greift wie bisher die Mapping-Tabelle.

• Kind-Datensätze einbetten (EmbedChildren, D365CE): Eine neue Source-Operation erlaubt es, die Datensätze eines referenzierten Kind-Jobs (z. B. Angebotspositionen zu einem Angebot) direkt in die Queue-Nachricht des Eltern-Datensatzes einzubetten, sodass beide gemeinsam in einer Anfrage beim Ziel ankommen. Der Filter des Kind-Jobs kann dabei über {{...%parent.Feldname%...}} auf Werte des Eltern-Datensatzes zugreifen.

• Neue Diagnose-Endpunkte GET /job und GET /mapping: Zwei neue, rein lesende HTTP-Endpunkte (/job, /job/{rowKey}, /mapping, /mapping/{rowKey}) geben die aktuell geladene Job- bzw. Mapping-Konfiguration zurück — praktisch zur Fehlersuche, ohne direkt in der Table-Storage nachsehen zu müssen.

• Eingebauter MCP-Server für KI-Assistenten (z. B. Claude Code, GitHub Copilot, Microsoft 365 Copilot): Ein neuer, rein lesender Model-Context-Protocol-Endpunkt (POST /api/mcp) macht Jobs, Mappings sowie Service-Bus-Diagnosedaten (Queue-Laufzeit-Status, non-destruktives Peek von Nachrichten und Dead-Letter-Nachrichten) als KI-Tools ansprechbar — dediziert dafür gibt es keinen eigenen HTTP-Endpunkt. Zwei der zehn Tools gehen noch einen Schritt weiter: list_connector_tables und get_connector_table_schema lesen die echten Tabellen-/Feld-Metadaten (Typ, Nullable, maximale Länge, Primary Key) direkt aus dem Quell-/Zielsystem einer Connection — für BC, NAV, CE (Dataverse) und OpenAPI —, sodass sich ein Mapping gegen das tatsächliche Schema validieren lässt, statt sich auf die Mapping-Konfiguration allein zu verlassen. Für die SQL-Connectoren (MSSQL, MySQL, Oracle, PostgreSQL) ist das noch nicht implementiert.

  Die beiden Peek-Tools geben bewusst niemals den Nachrichteninhalt zurück, nur dessen Größe in Bytes (BodySize) — der Body kann fachliche Kunden-/Geschäftsdaten des jeweiligen Jobs enthalten, die Kopf-/Fehlerdaten (JobName, ErrorMessage, Stacktrace, Zustellversuche, …) reichen für die Diagnose. Die Tool-Beschreibungen selbst sind auf Englisch verfasst, da sie vom aufrufenden KI-Modell gelesen werden, nicht von einem Menschen. Details, Einrichtung (inkl. GitHub Copilot/VS Code und Microsoft 365 Copilot Studio), die vollständige Tool-Liste mit Lese-Umfang je Tool sowie die Funktionsweise: MCP-Server.

• System-assigned Managed Identity für die Function App: Die Azure Function App erhält beim Deployment automatisch eine system-zugewiesene Managed Identity. Ihre Objekt-ID (principalId) steht als Deployment-Output (functionPrincipalId) für nachgelagerte Rollenzuweisungen zur Verfügung. Die Identity wird immer angelegt.

• Optional (Preview): Storage & Service Bus über Managed Identity: Über den neuen Schalter enableManagedIdentity (Standard: aus) lassen sich die Verbindungen zu Storage und Service Bus von Schlüsseln auf identitätsbasierten Zugriff umstellen. Ist der Schalter aktiv, weist das Bicep-Deployment der Identity die nötigen Rollen zu (Storage Table/Blob/Queue, Service Bus Sender/Receiver/Data Owner — Data Owner wird für die Queue-Status-Abfrage des MCP-Tools list_queue_statuses benötigt) und die App-Settings verwenden AzureWebJobsStorage__accountName bzw. …__fullyQualifiedNamespace statt der Schlüssel-Verbindungszeichenfolgen.

  Standardmäßig bleibt alles beim Schlüssel-basierten Zugriff — ein reines ZIP-/Image-Update ändert daran nichts. Die Umstellung erfolgt nur, wenn das Bicep-Script mit aktiviertem Schalter neu deployt wird (siehe Installationshinweise).

• Leere Quell-Schlüssel gezielt ignorieren (IgnoreEmptySourceKey, D365CE): Ist das Quellfeld eines Ziel-Schlüssels leer, brach die Verarbeitung der Nachricht bisher immer mit einem Fehler ab — auch dann, wenn ein weiterer Schlüssel den Datensatz noch hätte finden können. Mit dem neuen Feld IgnoreEmptySourceKey am TargetKey (Standard: aus) lässt sich das je Schlüssel abschalten: Der betroffene Schlüssel wird übersprungen und die Suche läuft mit dem nächsten Schlüssel nach KeyRank weiter.

  Das ist vor allem im Multikey-Szenario relevant, wenn ein optionales Feld wie eine externe ID nicht in jedem Quelldatensatz gefüllt ist, ein nachrangiger Schlüssel den Zieldatensatz aber sicher findet.

  Findet kein Schlüssel einen Datensatz und waren alle leer gebliebenen Schlüssel entsprechend markiert, wird ein neuer Datensatz angelegt statt ein Fehler gemeldet. War auch nur einer der leeren Schlüssel nicht markiert, bleibt es beim Fehler. Details siehe IgnoreEmptySourceKey.

  Bestehende Mappings sind nicht betroffen — ohne gesetztes Feld bleibt das bisherige Verhalten unverändert.

Fehlerbehebungen & Verbesserungen

• Ausweichen auf den nächsten Schlüssel funktioniert bei leeren Schlüsseln: War bei mehreren Ziel-Schlüsseln der erste in der Quelle leer, lief die anschliessende Suche im Zielsystem auf einen unbehandelten Fehler — die nachrangigen Schlüssel kamen gar nicht mehr zum Zug, obwohl sie den Datensatz gefunden hätten. Die Schlüsselsuche behandelt diesen Fall jetzt sauber und arbeitet die Schlüssel wie vorgesehen der Reihe nach ab.

• sample.local.settings.json war kein gültiges JSON: Eine überzählige schließende geschweifte Klammer am Dateiende hätte beim Kopieren als Vorlage für local.settings.json zu einem sofortigen JSON-Parse-Fehler geführt. Behoben.

• Oracle- und MySQL-Konnektor: Paging funktionierte nicht: Beide Konnektoren erzeugten für jede Seite ab der zweiten eine ungültige SQL-Abfrage und brachen mit einem Datenbankfehler ab. Betroffen waren ausschließlich Tabellen, die mehr Datensätze als die konfigurierte maxPageSize je Lauf lieferten. Beide Konnektoren erzeugen jetzt dialektkorrektes Paging (Oracle: OFFSET…FETCH NEXT, MySQL: LIMIT…OFFSET).

• PostgreSQL-Konnektor: Job-Filter (und damit die Watermark) wurde beim Lesen ignoriert: Der Konnektor las unabhängig vom im Job hinterlegten Filter bei jedem Lauf die komplette Tabelle neu, statt nur die seit der letzten Watermark geänderten Datensätze. Der Filter wird jetzt wie bei den übrigen SQL-Konnektoren als WHERE-Klausel übernommen.

• SQL-Konnektoren (MSSQL, Oracle, MySQL, PostgreSQL): Abbruch bei Watermark-Spalten, die kein Datum sind: War die als WatermarkField konfigurierte Spalte kein DateTime-Typ (z. B. eine fortlaufende ID oder ein rowversion-Wert), brach der Lesevorgang beim ersten Datensatz ab. Der Wert wird jetzt auch bei anderen Spaltentypen sicher verarbeitet; als Watermark-Spalte empfohlen bleibt weiterhin ein echtes Datum, da davon auch die Sortierung der Änderungen abhängt.

Das in v2.1 eingeführte Grafana-Dashboard wurde zweimal überarbeitet, zunächst:

• Direkt aus der Azure Function erreichbar: Das Dashboard ist jetzt zusätzlich direkt von der Function App aus verlinkt und nicht mehr nur über die Ressourcengruppe auffindbar.
• Erfolgsraten berücksichtigen den Zeitraum: Die vier Erfolgsraten-Anzeigen (GetChanges sowie die Verarbeitung nach Priorität) werten jetzt den im Dashboard gewählten Zeitraum aus, statt einen festen Standardzeitraum zu verwenden.
• Neue Auswertung „GetChanges per Jobs": Eine zusätzliche Zeitreihe zeigt die erkannten Änderungen je Job im Zeitverlauf.

und in einem zweiten Durchgang deutlich erweitert:

• Zwei neue Custom Metrics: MessagesProcessed (Dimensionen JobName, Outcome mit den Werten Success/Failed/Transitive) und ProcessingDurationMs (Dimension JobName) werden jetzt beim Verarbeiten jeder Queue-Nachricht getrackt — queue-übergreifend, da alle drei Prioritäts-Queues durch denselben Verarbeitungscode laufen. Details siehe Metriken.
• Service-Bus-Anbindung: Zwei neue Kopfzeilen-Kacheln (Active Messages, Deadletter) zeigen die aktuell wartenden bzw. dead-letterten Nachrichten, summiert über alle drei Export-Queues — direkt aus den Azure-Monitor-Platform-Metriken des Service-Bus-Namespace, ohne eigene KQL-Abfrage.
• Kombinierte Ansicht statt drei getrennter Queue-Zeilen: Ausführungen, Laufzeiten und Job-Aufschlüsselung der Queue-Verarbeitung (ProcessLowPriorityQueueItems/ProcessStandardQueueItems/ProcessHighPriorityQueueItems) laufen jetzt in einer gemeinsamen Zeile „ProcessQueueItems" statt in getrennten, queue-spezifischen Panels — inklusive einer neuen kombinierten Erfolgsraten-Kachel in der Kopfzeile.
• Erfolg und Fehler je Job für die Queue-Verarbeitung: Zwei neue Zeitreihen-Panels („ProcessItems Success per Job", „ProcessItems Errors per Job") zeigen erfolgreiche bzw. fehlgeschlagene bzw. in eine Retry-Queue umgeleitete (Transitive) Nachrichten aufgeschlüsselt nach Job.
• Zwei neue Dashboard-Filter: Die Variable Bin Size (5 Minuten bis 1 Tag, Standard 10 Minuten) steuert die Gruppierung aller Zeitreihen-Panels; die Variable Job Namen (Mehrfachauswahl, live aus den vorhandenen Jobs ermittelt) schränkt alle job-bezogenen Panels auf die gewählten Jobs ein. Beide gelten nicht für die Kopfzeilen-Kacheln und die Exceptions-Heatmap (siehe Grafana-Dashboard für die genaue Wirkung je Panel).
• Fehler-Überblick als Heatmap: Das Exceptions-Panel wurde von einem Balkendiagramm auf eine Heatmap umgestellt.

Vollständig neu dokumentiert, inklusive der bekannten Grenzen (z. B. keine job-genaue Erfolgsquote für GetChanges, keine Job-Filterung auf Exceptions): siehe Grafana-Dashboard.

Das aktualisierte Dashboard wird beim nächsten Bicep-Deployment automatisch übernommen — es sind keine manuellen Schritte nötig. Neu ist dafür ein zusätzlicher Bicep-Parameter, der den Namen des Service-Bus-Namespace an das Dashboard-Modul durchreicht (serviceBusNamespaceName in modules/dashboard.bicep) — bei Deployment über die vorhandene main.bicep ist das bereits verdrahtet und erfordert keine Anpassung durch Administratoren.

Installationshinweise

Dieser Abschnitt richtet sich an Administratoren, die ein bestehendes System aktualisieren.

Ein reines ZIP-/Image-Update genügt — es sind keine manuellen Konfigurationsschritte erforderlich. Die Managed Identity wird beim nächsten Bicep-Deployment automatisch angelegt.

Der neue OpenAPI-Connector, Action-Jobs, die job-eigenen Source/Target-Felder sowie EmbedChildren sind rein additiv: Bestehende Connections, Jobs und Mappings sind nicht betroffen und laufen ohne Anpassung unverändert weiter. Es sind keine neuen App-Settings und keine Bicep-Änderungen erforderlich, um die neuen Funktionen bereitzustellen — sie werden erst durch entsprechende Einträge in den Konfigurationstabellen (connections, jobs, mappings) aktiv genutzt.

Das neue Mapping-Feld IgnoreEmptySourceKey ist optional: Ohne Anpassung der Mappings bleibt das Verhalten wie bisher. Soll es genutzt werden, wird es im TargetKey-JSON der betroffenen Mapping-Zeile ergänzt ("IgnoreEmptySourceKey": true) — ein Neustart der Function App ist dafür nicht nötig, die Konfiguration wird aus dem Table Storage gelesen.

Neue Azure-Ressourcen (Bicep)

• System-assigned Managed Identity (Microsoft.Web/sites → identity): Wird beim Deployment der Function App aktiviert (identity.type = 'SystemAssigned'). Ihre Objekt-ID wird als Deployment-Output functionPrincipalId (aus dem Modul-Output principalId) ausgegeben und dient als Grundlage für nachgelagerte Rollenzuweisungen. Es entstehen keine zusätzlichen Kosten.

Managed Identity für Storage & Service Bus aktivieren (Preview)

Optional. Nur relevant, wenn Storage und Service Bus ohne Schlüssel betrieben werden sollen.

• Schalter enableManagedIdentity (im Marketplace-Assistenten unter Product Settings → Preview, bzw. Bicep-Parameter) auf Ja/true setzen und das Bicep-Script neu deployen.
• Owner oder User Access Administrator auf der Ressourcengruppe ist dafür erforderlich, da das Deployment Rollenzuweisungen anlegt.
• Beim Deployment mit aktiviertem Schalter muss die Function-Version zur Bicep-Version passen (die neue Function-Version unterstützt beide Zugriffsarten; ältere Versionen erwarten die Schlüssel-Verbindungszeichenfolgen).
• Der WEBSITE_CONTENTAZUREFILECONNECTIONSTRING-Content-Share bleibt weiterhin schlüsselbasiert (Azure Files unterstützt hier keine Identität).
• Kurz nach der Aktivierung können durch die RBAC-Propagation vereinzelt transiente Authentifizierungsfehler auftreten; diese fangen sich beim nächsten GetChanges-Lauf automatisch.

Container-Image

Falls die DataBridge containerisiert betrieben wird, ist das Image auf den neuen Tag zu aktualisieren:

acrwysatest.azurecr.io/containered-connector:v2.2.0

Die .NET-Basis bleibt unverändert (.NET 10, Isolated Worker) — es handelt sich lediglich um einen neuen Versions-Tag, kein Wechsel des Basis-Images.