Mettre à jour l’entrepôt

La mise à jour de l’entrepôt est une étape qui peut être lancée directement après l’étape Connecteur de pause. Cette étape permet à l’utilisateur de mettre à jour l’entrepôt, configuré lors de Connector Configuration, qui est utilisé pour l’exécution des tâches contrôlées par SDK. En cas d’écrasement avec une logique personnalisée, cette procédure doit être remplacée pour spécifier un gestionnaire (handler) Java personnalisé.

Pour lancer cette procédure, l’utilisateur doit avoir le rôle d’application ADMIN.

L’étape de mise à jour de l’entrepôt se compose en interne de plusieurs phases. Certaines d’entre elles sont entièrement personnalisables et, par défaut, n’ont pas d’impact. Les phases sont les suivantes :

  1. Validation du statut

  2. Validation des entrées

  3. Rappel interne

  4. Rappel de SDK

  5. Mise à jour de la configuration

Exigences

La configuration de l’entrepôt nécessite au moins l’exécution des fichiers sql suivants lors de l’installation de la Native App :

  • core.sql

  • configuration/app_config.sql

  • configuration/connector_configuration.sql

  • configuration/update_warehouse.sql

Validation du statut

Pour effectuer la mise à jour de l’entrepôt, le statut interne du connecteur doit être PAUSED.

Cette validation ne peut être écrasée ni à l’aide de UpdateWarehouseHandlerBuilder, ni en écrasant la procédure stockée. Toutefois, il est possible d’implémenter un gestionnaire (handler) personnalisé, qui n’aura pas ce type de validation.

Validation des entrées

L’entrée doit être une String contenant le nouvel entrepôt. Cet entrepôt fourni est ensuite validé à l’aide d’une implémentation de UpdateWarehouseInputValidator. Par défaut, les validations suivantes sont effectuées, chacune générant une exception si les critères requis ne sont pas remplis :

  1. Validation si l’entrepôt fourni est un identificateur Snowflake valide.

  2. Validation si le nouvel entrepôt est différent de celui déjà configuré.

  3. Validation si l’instance d’application peut accéder au nouvel entrepôt (en utilisant la requête SHOW WAREHOUSES).

Cette étape de validation des entrées ne peut être personnalisée qu’en utilisant UpdateWarehouseHandlerBuilder et en créant une nouvelle instance de gestionnaire (handler) personnalisée.

Rappel interne

Le rappel interne est également une étape personnalisable. Par défaut, il appelle la procédure PUBLIC.UPDATE_WAREHOUSE_INTERNAL, dont l’implémentation par défaut renvoie 'response_code': 'OK'. Cette étape peut être utilisée pour fournir une logique personnalisée pour le processus de mise à jour de l’entrepôt, par exemple en modifiant les tâches créées par le développeur de l’application. Il peut être remplacé par le script sql ou en utilisant UpdateWarehouseHandlerBuilder pour fournir une implémentation personnalisée de l’interface UpdateWarehouseCallback.

Rappel de SDK

Le rappel SDK est similaire à la phase de rappel interne. Son objectif est de mettre à jour les composants contrôlés par le SDK, par exemple les tâches créées par Task Reactor.

Cette validation ne peut pas être écrasée par l’utilisation de UpdateWarehouseHandlerBuilder, ni par l’écrasement de la procédure stockée. Il est possible d’implémenter un gestionnaire (handler) personnalisé qui n’aura pas ce type de validation, mais cela est fortement déconseillé.

Mise à jour de la configuration

Une fois que les validations et les rappels ont été effectués avec succès, le nouvel entrepôt sera enregistré dans la table interne APP_CONFIG. Le service responsable enregistrera l’entrepôt fourni sous la clé connector_configuration, remplaçant ainsi la valeur configurée précédemment.

Affichage de la configuration

Les rôles d’application ADMIN et VIEWER disposent d’une vue PUBLIC.CONNECTOR_CONFIGURATION qui renvoie la configuration actuelle de la table interne APP_CONFIG.

Réponse

Réponse aboutie

Si la procédure se termine avec succès, elle renvoie une réponse avec le code de réponse OK :

{
  "response_code": "OK"
}
Copy

Erreur de réponse

En cas d’erreur, la réponse a le format suivant :

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

Les codes d’erreur possibles sont les suivants :

  • INVALID_CONNECTOR_STATUS - Statut du connecteur non valide. Statut attendu : [PAUSED]

  • INTERNAL_ERROR - Quelque chose s’est mal passé en interne, le message doit être descriptif

  • PROCEDURE_NOT_FOUND - La procédure appelée n’existe pas

  • UNKNOWN_SQL_ERROR - Cette erreur se produit lorsque quelque chose d’inattendu se produit lors de l’appel de procédures internes

  • INVALID_RESPONSE - Cette erreur se produit lorsque la réponse reçue de la procédure interne ne contient pas de response_code ou qu’une erreur de réponse ne contient pas de message, mais contient un response_code

  • UNKNOWN_ERROR - Cela signifie que quelque chose d’inattendu s’est mal passé (le message de l’exception levée est transmis)

  • EMPTY_IDENTIFIER - L’identificateur fourni est une valeur NULL ou une chaîne vide

  • INVALID_IDENTIFIER - L’identificateur d’entrepôt fourni n’est pas valide

  • WAREHOUSE_ALREADY_USED - L’entrepôt fourni est déjà utilisé par l’application

  • INACCESSIBLE_WAREHOUSE - L’entrepôt fourni ne peut pas être utilisé en accès par l’instance d’application

  • Codes d’erreur personnalisés reçus de la procédure UPDATE_WAREHOUSE_INTERNAL - définis par le développeur du connecteur

Langage: Français