Warehouse aktualisieren

Die Aktualisierung des Warehouses ist ein Schritt, der direkt nach dem Schritt Konnektor anhalten aufgerufen werden kann. Dieser Schritt ermöglicht es dem Benutzer, das Warehouse zu aktualisieren, das während Connector Configuration eingerichtet wurde und für die Ausführung von SDK-gesteuerten Aufgaben verwendet wird. Beim Überschreiben mit kundenspezifischer Logik muss diese Prozedur ersetzt werden, um einen kundenspezifischen Java-Handler anzugeben.

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

Der Schritt „Warehouse aktualisieren“ 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. Interner Callback

  4. SDK-Callback

  5. Aktualisierung der Konfiguration

Anforderungen

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

  • core.sql

  • configuration/app_config.sql

  • configuration/connector_configuration.sql

  • configuration/update_warehouse.sql

Validierung des Status

Um eine Aktualisierung des Warehouses auszuführen, muss der interne Status des Konnektors PAUSED sein.

Diese Validierung kann weder durch Verwendung von UpdateWarehouseHandlerBuilder noch durch das Überschreiben von gespeicherten Prozeduren ü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 String-Wert mit dem neuen Warehouse sein. Dieses bereitgestellte Warehouse wird dann mit einer Implementierung von UpdateWarehouseInputValidator validiert. Standardmäßig werden die folgenden Validierungen durchgeführt, die jeweils eine Ausnahme auslösen, wenn die erforderlichen Kriterien nicht erfüllt sind:

  1. Validieren, ob das angegebene Warehouse ein gültiger Snowflake-Bezeichner ist.

  2. Validieren, ob sich das neue Warehouse von dem bereits konfigurierten unterscheidet.

  3. Validieren, ob die Anwendungsinstanz auf das neue Warehouse zugreifen kann (mit der Abfrage SHOW WAREHOUSES).

Dieser Eingabevalidierungsschritt kann nur durch Verwendung von UpdateWarehouseHandlerBuilder und das Erstellen einer neuen, kundenspezifischen Handler-Instanz angepasst werden.

Interner Callback

Der interne Callback ist ein weiterer anpassbarer Schritt. Standardmäßig wird die Prozedur PUBLIC.UPDATE_WAREHOUSE_INTERNAL aufgerufen, deren Standardimplementierung 'response_code': 'OK' zurückgibt. Dieser Schritt kann verwendet werden, um kundenspezifische Logik für den Warehouse-Aktualisierungsprozess bereitzustellen, z. B. durch Ändern der vom Anwendungsentwickler erstellten Aufgaben. Der Callback kann über das SQL-Skript oder durch Verwendung von UpdateWarehouseHandlerBuilder überschrieben werden, um eine kundenspezifische Implementierung der UpdateWarehouseCallback-Schnittstelle bereitzustellen.

SDK-Callback

SDK-Callback ist ähnlich wie die interne Callback-Phase. Dessen Zweck ist es, die SDK-gesteuerten Komponenten zu aktualisieren, z. B. Aufgaben, die vom Task Reactor erstellt wurden.

Diese Validierung kann weder durch Verwendung von UpdateWarehouseHandlerBuilder noch durch das Überschreiben von gespeicherten Prozeduren überschrieben werden. Es ist möglich, einen kundenspezifischen Handler zu implementieren, der diese Art der Validierung nicht durchführt, aber davon wird dringend abgeraten.

Aktualisierung der Konfiguration

Sobald die Validierungen und Callbacks erfolgreich durchgeführt wurden, wird das neue Warehouse in der internen Tabelle APP_CONFIG gespeichert. Der dafür zuständige Dienst speichert das bereitgestellte Warehouse unter dem Schlüssel connector_configuration und ersetzt damit den zuvor konfigurierten Wert.

Anzeigen der Konfiguration

Für die Anwendungsrollen ADMIN und VIEWER steht die Ansicht PUBLIC.CONNECTOR_CONFIGURATION zur Verfügung, die die aktuelle Konfiguration aus der internen Tabelle APP_CONFIG zurückgibt.

Antwort

Erfolgreiche Antwort

Wenn die Prozedur erfolgreich abgeschlossen wird, gibt sie eine Antwort mit dem OK-Antwortcode zurück:

{
  "response_code": "OK"
}
Copy

Fehlerantwort

Im Falle eines Fehlers hat die Antwort das folgende Format:

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

Mögliche Fehlercodes sind:

  • INVALID_CONNECTOR_STATUS – Ungültiger Konnektorstatus. Erwarteter Status: [PAUSED]

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

  • PROCEDURE_NOT_FOUND – Die Prozedur, die aufgerufen wurde, existiert nicht.

  • 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).

  • EMPTY_IDENTIFIER – Der bereitgestellte Bezeichner ist ein NULL-Wert oder ein leerer String-Wert.

  • INVALID_IDENTIFIER – Der bereitgestellte Warehouse-Bezeichner ist nicht gültig.

  • WAREHOUSE_ALREADY_USED – Das bereitgestellte Warehouse wird bereits von der Anwendung verwendet.

  • INACCESSIBLE_WAREHOUSE – Das bereitgestellte Warehouse kann von der Anwendungsinstanz nicht genutzt werden (kein Zugriff).

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

Sprache: Deutsch