Konnektorkonfiguration

Die Konnektorkonfiguration ist der erste erforderliche Schritt in der Assistentenphase. Er stellt sicher, dass der Konnektor über die Konfiguration der Objekte verfügt, die allen Konnektortypen unabhängig von Quellsystem und Domäne gemeinsam sind. Die Prozedur PUBLIC.CONFIGURE_CONNECTOR(config VARIANT) ist der Einstiegspunkt von der UI oder dem Arbeitsblatt aus, um dies zu tun. Wenn Sie diese Prozedur mit kundenspezifischer Logik überschreiben, müssen Sie beachten, dass sie ersetzt werden muss, da sie auf die statische Java-Methode ConfigureConnectorHandler.configureConnector als Handler verweist.

Zum Aufrufen dieser Prozedur muss dem Benutzer die Anwendungsrolle ADMIN zugewiesen sein.

Der Schritt „Konnektorkonfiguration“ besteht intern aus mehreren Phasen. Einige von ihnen sind vollständig anpassbar und tun standardmäßig gar nichts. Die Phasen sind wie folgt:

  1. Validierung des Status

  2. Validierung der Felder

  3. Validierung der Eingabe

  4. Aktualisierung der Konfiguration

  5. Interner Callback

  6. Aktualisierung des Status

Anforderungen

„Konnektorkonfiguration“ erfordert mindestens die folgenden SQL-Dateien, die während der Installation der nativen App ausgeführt werden müssen:

  • core.sql

  • configuration/app_config.sql

  • configuration/connector_configuration.sql

Validierung des Status

Um die Konnektorkonfiguration durchzuführen, muss der Konnektor den internen Status CONFIGURING haben. Diese Validierung kann weder durch die Verwendung von ConfigureConnectorHandlerBuilder noch durch das Überschreiben einer gespeicherten Prozedur überschrieben werden. Es ist jedoch möglich, einen kundenspezifischen Handler zu implementieren, der diese Art der Validierung nicht durchführt.

Validierung der Felder

Die Konnektorkonfiguration muss eine Menge von spezifischen Feldern enthalten. Alle sind optional, aber jedes andere Feld löst eine Ausnahme aus. Die erlaubten Schlüssel sind:

  • warehouse

  • destination_database

  • destination_schema

  • operational_warehouse

  • global_schedule

  • data_owner_role

  • agent_username

  • agent_role

Warehouse

Das Warehouse wird vom Konnektor verwendet, um den Scheduler zu starten, Aufgaben auszuführen und Abfragen zu starten.

Destination_database

Die Zieldatenbank wird verwendet, um die vom Konnektor aufgenommenen Daten zu speichern. Diese Datenbank sollte sich außerhalb des Konnektors befinden. Es kann sich dabei um eine bestehende Datenbank handeln, allerdings muss der Konnektor über Berechtigungen zum Schreiben in die Datenbank verfügen. Es kann sich aber auch um eine neu erstellte Datenbank handeln. Dies geschieht jedoch nicht automatisch, sondern muss als Teil des internen Callbacks während der Konnektorkonfiguration oder beim Abschließen der Konfiguration implementiert werden.

Destination_schema

Das Zielschema ist das Schema, das in der obigen Zieldatenbank verwendet wird.

Operational_warehouse

Gelegentlich muss der Konnektor die eigentlichen Ingestion-Prozesse, die ein Warehouse erfordern, von den Prozessen trennen, die mit den internen Operationen des Konnektors zusammenhängen. Geben Sie dieses zweite Warehouse an, um die Datenlast zwischen ihnen aufzuteilen.

Global_schedule

Diese Eigenschaft definiert den aktiven Zeitplan für die Scheduler-Aufgabe. Derzeit verarbeitet der Scheduler nur Ressourcen mit einer eigenen Einstellung scheduleType=GLOBAL. Der Wert für diese Eigenschaft sollte ähnlich der unten stehenden sein:

"global_schedule": {
    "scheduleType": "CRON",
    "scheduleDefinition": "*/10 * * * *"
}
Copy

Data_owner_role

Rolle, die verwendet werden kann, um die Eigentümerschaft an der Sync-Datenbank zu vergeben, damit die Daten nach der Deinstallation des Konnektors erhalten bleiben.

Agent_username

Benutzername, der vom Agenten des Push-basierten Konnektors bei der Verbindung mit Snowflake verwendet wird.

Agent_role

Rolle, die vom Agenten des Push-basierten Konnektors bei der Verbindung mit Snowflake verwendet wird.

Validierung der Eingabe

Die Eingabe muss ein gültiger Variant-Wert sein. Außerdem bietet das SDK eine interne gespeicherte Prozedur mit dem Namen PUBLIC.CONFIGURE_CONNECTOR_VALIDATE(config VARIANT). Standardmäßig gibt diese Prozedur nur 'response_code': 'OK' zurück. Dies kann jedoch durch Überschreiben dieser gespeicherten Prozedur geändert werden. Alternativ kann dies angepasst werden, indem ConfigureConnectorHandlerBuilder verwendet und eine kundenspezifische Implementierung der ConfigureConnectorValidator-Schnittstelle bereitgestellt wird.

Aktualisierung der Konfiguration

Sobald die Validierungen erfolgreich abgeschlossen sind, wird die Konfiguration in der internen Tabelle APP_CONFIG gespeichert. Der dafür zuständige Dienst speichert den bereitgestellten Variant-Wert unter dem Schlüssel connector_configuration.

Interner Callback

Der interne Callback ist ein weiterer anpassbarer Schritt. Standardmäßig wird PUBLIC.CONFIGURE_CONNECTOR_INTERNAL(config VARIANT) aufgerufen, das 'response_code': 'OK' zurückgibt. Die Prozedur kann über das SQL-Skript oder durch Verwendung von ConfigureConnectorHandlerBuilder überschrieben werden, um eine kundenspezifische Implementierung der ConfigureConnectorCallback-Schnittstelle bereitzustellen.

Aktualisierung des Status

Wenn alle oben genannten Phasen erfolgreich abgeschlossen sind, wird der interne Status des Konnektors wie folgt aktualisiert:

{
    "status": "CONFIGURING",
    "configurationStatus": "CONFIGURED"
}
Copy

Eine Abbildung der Zustandsübergänge finden Sie unter Konnektorablauf.

Antwort

Erfolgreiche Antwort

Wenn die Prozedur erfolgreich abgeschlossen wird, wird eine Antwort in folgendem Format zurückgegeben:

{
  "response_code": "OK",
}
Copy

Fehlerantwort

Im Falle eines Fehlers erfolgt die Antwort in folgendem Format:

{
  "response_code": "<ERROR_CODE>",
  "message": "<error message>"
}
Copy

Mögliche Fehlercodes sind:

  • INVALID_CONNECTOR_STATUS – Die Prozedur wurde auf einem bereits konfigurierten Konnektor aufgerufen.

  • CONNECTOR_CONFIGURATION_PARSING_ERROR – Die angegebene Konfiguration ist keine gültiges JSON.

  • CONNECTOR_STATUS_NOT_FOUND – Der Datensatz mit dem Konnektorstatus existiert nicht in der Datenbank.

  • CONNECTOR_STATUS_PARSING_ERROR – Der in der Tabelle APP_STATE unter dem Schlüssel connector_status gespeicherte Wert hat ein falsches Format und kann von der Anwendung nicht geparst werden.

Sprache: Deutsch