Verbindungen (connections)

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

Unterstützte Connector-Typen

Universelle JSON-Parameter

Diese Parameter sind für alle Connector-Typen gültig und werden in das Json-Feld eingetragen. Alle sind optional:

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:

JSON-Parameter je Connector-Typ

D365BC — Business Central

Für Cloud-Umgebungen (OAuth2 Client Credentials):

{
  "clientId": "<App-Registration Client ID>",
  "clientSecret": "<App-Registration Client Secret>",
  "tenantId": "<Entra Tenant ID>",
  "environment": "<BC-Umgebungsname, z. B. production>",
  "companyId": "<BC Company ID (GUID)>"
}

Für OnPremise-Umgebungen (Basic Auth):

{
  "userName": "<domain\\benutzername>",
  "password": "<Passwort>",
  "url": "https://<server>:<port>/<pfad>"
}

Zusätzlicher optionaler Parameter:

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

{
  "connectionstring": "<XRM-Connection-String>"
}

Das Format des XRM-Connection-Strings beschreibt die Microsoft-Dokumentation.

Beispiel:

AuthType=ClientSecret;Url=https://<org>.crm4.dynamics.com;ClientId=<id>;ClientSecret=<secret>

D365NAV — Microsoft Dynamics NAV

Für Cloud-Umgebungen (OAuth2 Client Credentials):

{
  "clientId": "<App-Registration Client ID>",
  "clientSecret": "<App-Registration Client Secret>",
  "tenantId": "<Entra Tenant ID>",
  "environment": "<NAV-Umgebungsname>",
  "companyId": "<Company ID (GUID)>"
}

Für OnPremise-Umgebungen:

{
  "userName": "<domain\\benutzername>",
  "password": "<Passwort>",
  "url": "https://<server>:<port>/<pfad>/",
  "baseAddress": "https://<server>:<port>/",
  "authenticationMethod": "NTLM"
}

Zusätzliche NAV-Parameter:

OPENAPI — generischer REST-Konnektor

{
  "baseUrl": "https://api.example.com",
  "openApiSpecUrl": "https://api.example.com/openapi.yaml",
  "clientId": "<Client-ID>",
  "clientSecret": "<Client-Secret>",
  "tenantId": "<Entra Tenant ID>",
  "tokenUrl": "https://api.example.com/oauth/token",
  "apiKeyHeader": "X-API-Key",
  "apiKeyValue": "<API-Key>",
  "customHeaders": { "X-Custom-Header": "wert" }
}

Vollständige Parameterliste, Authentifizierungsauswahl, Paginierung und Besonderheiten: Konnektoren → OpenAPI.

SQL-Datenbanken (MSSQL, MYSQL, ORACLE, PGSQL)

Alle SQL-Konnektoren verwenden einen einzelnen Connection String:

{
  "connectionstring": "<datenbankspezifischer Connection String>"
}

Zusätzlicher optionaler Parameter:

Diagnose-Schalter (D365BC und D365NAV)

Für die Fehlersuche lassen sich zusätzliche Protokollierungen einschalten. Alle drei Schalter stehen standardmäßig auf false:

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:

{
  "keyVaultUrl": "https://<vault>.vault.azure.net/secrets/<secret-name>/"
}

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.

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.