Verbindungskonfiguration

Die Verbindungskonfiguration ist ein Schritt des Assistenten, der direkt auf die Konnektorkonfiguration folgt. In diesem Schritt kann der Benutzer die Eigenschaften festlegen, die für das Herstellen einer Verbindung zum Quellsystem erforderlich sind, damit die Datenaufnahme (Ingestion) in Snowflake starten kann. Die Prozedur PUBLIC.SET_CONNECTION_CONFIGURATION(connection_configuration VARIANT) ist der Einstiegspunkt für diese Assistentenphase. Diese Prozedur kann von der UI oder vom Arbeitsblatt aus aufgerufen werden. Beim Überschreiben mit kundenspezifischer Logik muss diese Prozedur ersetzt werden, um den kundenspezifischen Java-Handler anzugeben.

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

Der Schritt „Verbindungskonfiguration“ 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 Eingabe

  3. Aktualisierung der Konfiguration

  4. Interner Callback

  5. Validierung der Verbindung

  6. Aktualisierung des Status

Anforderungen

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

Darüber hinaus gibt es eine Anforderung, die vom SDK-Benutzer abhängt:

  • Kundenspezifische Implementierung der Prozedur PUBLIC.TEST_CONNECTION()

Validierung des Status

Um die Verbindungskonfiguration auszuführen, muss der interne Status des Konnektors CONFIGURING sein, mit dem Konfigurationsstatus CONFIGURED oder CONNECTED. Der erste Konfigurationsstatus wird direkt nach dem Schritt „Konnektorkonfiguration“ gesetzt, der zweite ist vorhanden, wenn aus irgendeinem Grund die Verbindungskonfiguration in späteren Schritten aktualisiert werden muss.

Diese Validierung kann weder durch die Verwendung von ConnectionConfigurationHandlerBuilder 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 Eingabe

Die Eingabe muss ein variant-Wert sein, der eine Zuordnung von Eigenschaften enthält, was jedoch nicht in allen Fällen funktioniert. Aus diesem Grund bietet das SDK eine interne gespeicherte Prozedur namens PUBLIC.SET_CONNECTION_CONFIG_VALIDATE(config VARIANT). Standardmäßig gibt diese Prozedur nur 'responseCode': 'OK' zurück. Wenn Sie sie überschreiben, kann die angegebene Konfiguration während der Validierung aktualisiert werden. Dieses Feature ermöglicht die Verwendung kundenspezifischer Logik, wie z. B. das Kürzen der Eingabe oder die Konvertierung in Groß-/Kleinschreibung. Um eine in irgendeiner Weise veränderte Konfiguration zurückzugeben, muss die Antwort eine zusätzliche Eigenschaft "config" in der Variant-Antwort enthalten. Diese Eigenschaft sollte die aktualisierte Konfiguration als Variant enthalten. Die Prozedur kann angepasst werden, indem das SQL-Skript überschrieben wird oder indem ConnectionConfigurationHandlerBuilder verwendet und eine kundenspezifische Implementierung der ConnectionConfigurationInputValidator-Schnittstelle bereitgestellt wird.

Die folgende Antwort ist eine gültige Antwort aus der kundenspezifischen Implementierung mit Transformation:

{
    "response_code" : "OK",
    "config": {
        "key1": "value1",
        "key2": "value2"
    }
}
Copy

Aktualisierung der Konfiguration

Sobald die Validierung erfolgreich war, 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 connection_configuration. Für diese Konfiguration bestehen beim Speichern keinen zusätzlichen Anforderungen, sodass die Menge der bereitgestellten Eigenschaften dem Benutzer überlassen ist.

Interner Callback

Der interne Callback ist ein weiterer anpassbarer Schritt. Standardmäßig wird PUBLIC.SET_CONNECTION_CONFIGURATION_INTERNAL(connection_configuration VARIANT) aufgerufen, das 'response_code': 'OK' zurückgibt. So können Sie zum Beispiel andere Prozeduren verändern, indem Sie ihnen eine Integration für den externen Zugriff zuweisen. Die Prozedur kann über das SQL-Skript oder durch Verwendung von ConnectionConfigurationHandlerBuilder überschrieben werden, um eine kundenspezifische Implementierung der ConnectionConfigurationCallback-Schnittstelle bereitzustellen.

Validierung der Verbindung

Bei diesem Schritt wird eine PUBLIC.TEST_CONNECTION-Prozedur ausgelöst. Diese Prozedur versucht, das Quellsystem nach den Daten abzufragen. Diese Prozedur ist nicht standardmäßig implementiert und muss vom SDK-Benutzer bereitgestellt werden. Außerdem kann die Implementierung der ConnectionValidator-Schnittstelle für ConnectionConfigurationHandlerBuilder bereitgestellt werden, um diese Phase anzupassen. In diesem Fall ist es nicht erforderlich, eine gespeicherte Prozedur zu implementieren. Es wird empfohlen, in diesem Verfahren nur eine minimale Konnektivitätsprüfung durchzuführen, um sicherzustellen, dass die Möglichkeiten für den externen Zugriff von Snowflake korrekt konfiguriert sind und der Konnektor über alle erforderlichen Berechtigungen verfügt, um sie zu nutzen.

Aktualisierung des Status

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

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

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

Anzeigen der Konfiguration

Es gibt eine Prozedur PUBLIC.GET_CONNECTION_CONFIGURATION(), die den Benutzern ADMIN und VIEWER zur Verfügung steht und die die aktuelle Verbindungskonfiguration aus der internen Tabelle zurückgibt.

Antwort

Erfolgreiche Antwort

Wenn die Prozedur erfolgreich abgeschlossen wird, gibt sie eine Antwort von der Prozedur TEST_CONNECTION zurück: Wir empfehlen die Verwendung des folgenden Formats:

{
  "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 – Ungültiger Konnektorstatus. Erwarteter Status: [CONFIGURING]

  • INVALID_CONNECTOR_CONFIGURATION_STATUS – Ungültiger Status der Konnektorkonfiguration. Erwarteter Status: CONFIGURED

  • INTERNAL_ERROR – Es gibt intern eine Problem; die Meldung sollte beschreibend sein.

  • PROCEDURE_NOT_FOUND – Die Prozedur, die aufgerufen wurde, existiert nicht. In diesem Fall geht es meist um die TEST_CONNECTION-Prozedur.

  • UNKNOWN_SQL_ERROR – Dieser Fehler tritt auf, wenn beim Aufruf interner Prozeduren etwas Unerwartetes passiert.

  • INVALID_RESPONSE – Dieser Fehler tritt auf, wenn die von der internen Prozedur empfangene Antwort nicht response_code enthält oder eine Fehlerantwort nicht message enthält, sondern response_code.

  • UNKNOWN_ERROR – Dies bedeutet, dass etwas Unerwartetes passiert ist; die Meldung der ausgelösten Ausnahme wird weitergeleitet.

  • Kundenspezifische Fehlercodes, die von der Prozedur TEST_CONNECTION() empfangen werden – vom Entwickler des Konnektors definiert

  • Kundenspezifische Fehlercodes, die von der Prozedur SET_CONNECTION_CONFIGURATION_INTERNAL() empfangen werden – vom Entwickler des Konnektors definiert

Sprache: Deutsch