# Verbindungen (connections) > Die connections-Tabelle speichert Zugangsdaten zu allen Quell- und Zielsystemen. --- Site [llms.txt](/llms.txt) --- Die Tabelle `connections` ist die Grundlage jeder DataBridge-Konfiguration. Sie enthält die Zugangsdaten zu allen Systemen, mit denen die DataBridge kommuniziert — sowohl Quell- als auch Zielsysteme. --- ## Tabellenstruktur | Spalte | Wert | Beschreibung | |---|---|---| | **PartitionKey** | `connection` | Muss immer `connection` lauten | | **RowKey** | frei wählbar | Eindeutiger Name dieser Verbindung. Wird in der `jobs`-Tabelle als Referenz verwendet. | | **Timestamp** | automatisch | Systemseitig gesetzt, nicht bearbeitbar | | **Type** | Connector-Typ | Gibt an, um welches System es sich handelt (siehe Tabelle unten) | | **Json** | JSON-Objekt | System-spezifische Verbindungsparameter (unterscheidet sich je nach `Type`) | > **PartitionKey ist nicht frei wählbar** > > Die DataBridge liest die Tabelle ausschließlich mit dem Filter > `PartitionKey eq 'connection'`. Zeilen mit einem abweichenden PartitionKey werden **ohne > Fehlermeldung und ohne Warnung ignoriert** — die Verbindung existiert dann für die > DataBridge nicht, und jeder Job, der sie referenziert, wird als unvollständig verworfen. ### Unterstützte Connector-Typen | Type-Wert | System | Lesen | Schreiben | |---|---|---|---| | `D365BC` | Dynamics 365 Business Central | ✅ | ✅ | | `D365CE` | Dynamics 365 / Dataverse | ✅ | ✅ | | `D365NAV` | Microsoft Dynamics NAV | ✅ | ✅ | | `MSSQL` | Microsoft SQL Server | ⚠️ Preview | — | | `MYSQL` | MySQL / MariaDB | ⚠️ Preview | — | | `ORACLE` | Oracle Database | ⚠️ Preview | — | | `PGSQL` | PostgreSQL | ⚠️ Preview | — | | `OPENAPI` | Generische REST-API über OpenAPI-Spezifikation | ✅ | ✅ (inkl. Löschen) | > **SQL-Konnektoren sind Preview und nur lesend** > > Die vier SQL-Konnektoren sind als **interne Vorabversion** eingestuft. Schreiben wird > nicht unterstützt — ein SQL-System als Ziel führt zur Laufzeit zu einem Fehler. > > Auch beim Lesen bestehen Einschränkungen: Nur der MSSQL-Konnektor wertet den Filter des > Jobs aus. Details auf den jeweiligen [Konnektor-Seiten](../../konnektoren/). --- ## Universelle JSON-Parameter Diese Parameter sind für alle Connector-Typen gültig und werden in das `Json`-Feld eingetragen. Alle sind optional: | Parameter | Standardwert | Beschreibung | |---|---|---| | `keyVaultUrl` | *(leer)* | URL zu einem Azure-Key-Vault-Secret. Wenn gesetzt, werden **alle** übrigen Parameter aus dem Secret geladen — das `Json`-Feld selbst enthält dann nur diesen einen Eintrag. | | `maxPageSize` | `5000` | Maximale Anzahl Datensätze pro Abruf-Seite. Kann bei Performance-Problemen reduziert werden. | | `language` | `de-DE` | Kultur für die Interpretation von Zahlen- und Datumsformaten. | | `httpClientTimeoutSeconds` | `100` | Zeitlimit für einzelne Aufrufe in Sekunden. Relevant bei langsamen Quell- oder Zielsystemen. | ### Zusätzliche Parameter für HTTP-Konnektoren (D365BC, D365NAV, OpenAPI) Diese Parameter stehen allen HTTP-basierten Konnektoren zur Verfügung, auch wenn sie bislang vor allem für den OpenAPI-Konnektor relevant sind: | Parameter | Standardwert | Beschreibung | |---|---|---| | `apiKeyHeader` | *(leer)* | Name des HTTP-Headers für API-Key-Authentifizierung (z. B. `X-API-Key`). Gesetzt ⇒ API-Key-Authentifizierung wird verwendet. | | `apiKeyValue` | *(leer)* | Wert des API-Keys | | `tokenUrl` | *(leer)* | Eigener OAuth2-Token-Endpunkt. Ohne Angabe wird weiterhin der Microsoft-Login-Endpunkt verwendet. | | `authmethod` | *(leer)* | Erzwingt eine Authentifizierungsmethode: `BasicAuthentication`, `OAuth2`, `APIKey` oder `ManagedIdentity` (Groß-/Kleinschreibung egal). Ohne Angabe wird die Methode aus den vorhandenen Zugangsdaten abgeleitet. **`ManagedIdentity` wird nie automatisch gewählt**, sondern nur über diesen Parameter. Ein unbekannter Wert führt zu einem Fehler. | > **Auswahl der Authentifizierungsmethode** > > Sind `apiKeyHeader` **und** `apiKeyValue` gesetzt, hat API-Key-Authentifizierung Vorrang vor > Basic Auth und OAuth2. Andernfalls gilt weiterhin: `userName` + `password` ⇒ Basic Auth, > sonst `clientId` + `clientSecret` + `tenantId` ⇒ OAuth2 Client Credentials. > Ist `authmethod` gesetzt, gilt ausschließlich dieser Wert. > > Für Managed Identity gilt: > > - `"authmethod": "ManagedIdentity"` ohne `clientId` verwendet die **system-zugewiesene** Identity der Function App. > - Mit `clientId` wird die **benutzer-zugewiesene** Identity mit dieser Client-ID verwendet. > - `clientSecret` und `tenantId` werden nicht benötigt. Der Token wird mit dem `scope` der Connection angefordert (BC-Standard: `https://api.businesscentral.dynamics.com/.default`). > - Die Identity muss im Zielsystem berechtigt sein (bei BC als Microsoft-Entra-Anwendung in Business Central mit Berechtigungssätzen), siehe [D365BC](../../konnektoren/d365bc/). > > Hinweis: Beim D365NAV-Konnektor existiert zusätzlich `authenticationMethod` (nur `NTLM`). Das ist ein anderer Parameter als `authmethod`. --- ## JSON-Parameter je Connector-Typ ### D365BC — Business Central Für **Cloud-Umgebungen** (OAuth2 Client Credentials): ```json { "clientId": "", "clientSecret": "", "tenantId": "", "environment": "", "companyId": "" } ``` Für **OnPremise-Umgebungen** (Basic Auth): ```json { "userName": "", "password": "", "url": "https://:/" } ``` Zusätzlicher optionaler Parameter: | Parameter | Standardwert | Beschreibung | |---|---|---| | `scope` | `https://api.businesscentral.dynamics.com/.default` | OAuth2-Scope beim Token-Abruf. Nur anzupassen, wenn ein abweichender Endpunkt genutzt wird. | Die Auswahl des Authentifizierungsverfahrens erfolgt **automatisch**: Sind `userName` und `password` gesetzt, verwendet die DataBridge Basic Auth, andernfalls OAuth2 Client Credentials aus `clientId`, `clientSecret` und `tenantId`. ### D365CE — Dataverse / Customer Engagement ```json { "connectionstring": "" } ``` Alternativ über **Managed Identity** (ohne Secret): ```json { "url": "https://.crm4.dynamics.com", "clientid": "" } ``` Ohne `clientid` wird die system-zugewiesene Identity verwendet. Ist `connectionstring` gesetzt, hat er immer Vorrang. Details siehe [D365CE](../../konnektoren/d365ce/). Das Format des XRM-Connection-Strings beschreibt die [Microsoft-Dokumentation](https://learn.microsoft.com/en-us/power-apps/developer/data-platform/xrm-tooling/use-connection-strings-xrm-tooling-connect). Beispiel: ``` AuthType=ClientSecret;Url=https://.crm4.dynamics.com;ClientId=;ClientSecret= ``` ### D365NAV — Microsoft Dynamics NAV Für **Cloud-Umgebungen** (OAuth2 Client Credentials): ```json { "clientId": "", "clientSecret": "", "tenantId": "", "environment": "", "companyId": "" } ``` Für **OnPremise-Umgebungen**: ```json { "userName": "", "password": "", "url": "https://://", "baseAddress": "https://:/", "authenticationMethod": "NTLM" } ``` > **`url` ist immer erforderlich — auch bei NTLM** > > `baseAddress` ersetzt `url` **nicht**. Sämtliche Anfrage-Adressen werden aus `url` > gebildet; fehlt der Parameter, bricht der Konnektor beim ersten Aufruf ab. > > `baseAddress` wird ausschließlich bei `authenticationMethod = NTLM` für den > Credential-Cache verwendet und ist ansonsten entbehrlich. > > Ein fehlender Schrägstrich am Ende von `url` wird automatisch ergänzt. Zusätzliche NAV-Parameter: | Parameter | Standardwert | Beschreibung | |---|---|---| | `scope` | `https://api.businesscentral.dynamics.com/.default` | OAuth2-Scope beim Token-Abruf | | `baseAddress` | *(leer)* | Basis-Adresse für den NTLM-Credential-Cache. Nur bei `authenticationMethod = NTLM` relevant. | | `authenticationMethod` | `Basic` | Siehe Hinweis unten | > **`authenticationMethod` wirkt nur beim Wert `NTLM`** > > Nur `NTLM` (Groß-/Kleinschreibung egal) schaltet auf NTLM-Authentifizierung um — und > auch das nur, wenn zusätzlich `userName` und `password` gesetzt sind. > > Bei **jedem anderen Wert** — auch beim Vorgabewert `Basic` — entscheidet die DataBridge > automatisch anhand der vorhandenen Felder: `userName` + `password` ergibt Basic Auth, > sonst `clientId` + `clientSecret` + `tenantId` für OAuth2. ### OPENAPI — generischer REST-Konnektor ```json { "baseUrl": "https://api.example.com", "openApiSpecUrl": "https://api.example.com/openapi.yaml", "clientId": "", "clientSecret": "", "tenantId": "", "tokenUrl": "https://api.example.com/oauth/token", "apiKeyHeader": "X-API-Key", "apiKeyValue": "", "customHeaders": { "X-Custom-Header": "wert" } } ``` Vollständige Parameterliste, Authentifizierungsauswahl, Paginierung und Besonderheiten: [Konnektoren → OpenAPI](../../konnektoren/openapi/). ### SQL-Datenbanken (MSSQL, MYSQL, ORACLE, PGSQL) Alle SQL-Konnektoren verwenden einen einzelnen Connection String: ```json { "connectionstring": "" } ``` Zusätzlicher optionaler Parameter: | Parameter | Standardwert | Beschreibung | |---|---|---| | `commandTimeOut` | `30` | Zeitlimit für einzelne SQL-Befehle in Sekunden. Bei großen Tabellen oder langsamen Abfragen zu erhöhen. | --- ## Diagnose-Schalter (D365BC und D365NAV) Für die Fehlersuche lassen sich zusätzliche Protokollierungen einschalten. Alle drei Schalter stehen standardmäßig auf `false`: | Parameter | Beschreibung | |---|---| | `logCreateRequests` | Protokolliert die vollständigen Anfragen beim Anlegen von Datensätzen | | `logUpdateRequests` | Protokolliert die vollständigen Anfragen beim Aktualisieren von Datensätzen | | `logReceivedData` | Protokolliert die vollständigen Antwortdaten des Systems | > **Nicht dauerhaft aktiviert lassen** > > Diese Schalter erzeugen erhebliche Datenmengen in Application Insights und können > Geschäftsdaten im Klartext protokollieren. Nur gezielt für die Dauer einer Analyse > aktivieren und danach wieder zurücksetzen. --- ## Key Vault — Verbindungsdaten sicher speichern Statt Credentials direkt in Table Storage zu speichern, kann ein Azure-Key-Vault-Secret referenziert werden. Das `Json`-Feld enthält dann nur die Referenz: ```json { "keyVaultUrl": "https://.vault.azure.net/secrets//" } ``` Das Secret selbst enthält das **vollständige** JSON-Objekt der Verbindung — also alle Parameter, die sonst direkt im `Json`-Feld stünden. Beim Verbindungsaufbau lädt die DataBridge das Secret und ersetzt damit die gesamte Verbindungskonfiguration. Optional lässt sich eine bestimmte Secret-Version adressieren, indem die Versions-ID an den Pfad angehängt wird. > **Key Vault wird nicht mitdeployt** > > Das Bicep-Deployment legt **keinen Key Vault** an. Die **System Managed Identity** der > Function App wird seit v2.2 hingegen **automatisch** angelegt. Vor der Nutzung des Key Vault > ist daher manuell einzurichten: > > 1. Key Vault anlegen und das Secret hinterlegen > 2. Der (bereits vorhandenen) **System Managed Identity** die Berechtigung **Get** auf die > Key Vault Secrets erteilen > > Ohne diese Schritte schlägt die Auflösung der Referenz beim Verbindungsaufbau fehl. --- ## Hinweise - Der **RowKey** ist der Bezeichner, der in der `jobs`-Tabelle unter `SourceConnection` bzw. `TargetConnection` eingetragen wird. Sprechende Namen wählen (z. B. `bc-produktion`, `dataverse-test`). - Eine Verbindung kann von mehreren Jobs gleichzeitig genutzt werden. - Beim Start prüft die DataBridge jede Verbindung mit einem Verbindungstest. Schlägt er fehl, bricht der laufende Aufruf ab und die Initialisierung wird beim nächsten Aufruf erneut versucht. - Änderungen in der `connections`-Tabelle werden bei der nächsten Initialisierung eingelesen — kein Redeployment nötig.