Configurations de connexion¶
La configuration de la connexion est une étape de l’assistant qui vient directement après la configuration du connecteur. Cette étape permet à l’utilisateur de spécifier les propriétés nécessaires à l’établissement d’une connexion avec le système source pour commencer à ingérer des données dans Snowflake. La procédure appelée PUBLIC.SET_CONNECTION_CONFIGURATION(connection_configuration VARIANT)
est le point d’entrée responsable de cette phase de l’assistant. Cette procédure peut être appelée par l’UI ou à partir de la feuille de calcul. En cas de remplacement par une logique personnalisée, cette procédure doit être remplacée pour spécifier le gestionnaire (handler) Java personnalisé.
Pour lancer cette procédure, l’utilisateur doit avoir le rôle d’application ADMIN
.
L’étape de configuration de la connexion 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 :
Validation du statut
Validation des entrées
Mise à jour de la configuration
Rappel interne
Validation de la connexion
Mise à jour du statut
Exigences¶
La configuration de la connexion nécessite au moins l’exécution des fichiers SQL suivants lors de l’installation de l’application native :
core.sql
(Voir : Référence SQL principale)configuration/app_config.sql
(Voir : Référence SQL de la configuration de l’appli)configuration/connection_configuration.sql
(Voir : Référence de la configuration de la connexion)
En outre, il existe une exigence qui dépend de l’utilisateur de SDK :
mise en œuvre personnalisée de la procédure
PUBLIC.TEST_CONNECTION()
Validation du statut¶
Pour effectuer la configuration de la connexion, le statut interne du connecteur doit être CONFIGURING
, avec le statut de configuration : CONFIGURED
ou CONNECTED
. Le premier statut de configuration sera défini directement après l’étape de configuration du connecteur, le second sera présent si, pour une raison quelconque, la configuration de la connexion doit être mise à jour au cours des étapes ultérieures.
Cette validation ne peut pas être écrasée par l’utilisation de ConnectionConfigurationHandlerBuilder
ni par l’écrasement d’une 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 variant
contenant un mappage des propriétés, mais cela peut ne pas fonctionner dans tous les cas. C’est pourquoi le SDK fournit une procédure stockée interne appelée : PUBLIC.SET_CONNECTION_CONFIG_VALIDATE(config VARIANT)
. Par défaut, cette procédure renvoie simplement 'responseCode': 'OK'
, l’écraser peut mettre à jour la configuration fournie lors de la validation. Cette fonction permet de personnaliser la logique. Par exemple, l’élagage de l’entrée ou la conversion en majuscules/minuscules. Pour renvoyer une configuration transformée de quelque manière que ce soit, la réponse doit contenir une propriété supplémentaire "config"
dans la réponse Variant
, cette propriété doit contenir la configuration mise à jour comme Variant
. La procédure peut être personnalisée en l’écrasant par le biais de SQL ou en utilisant ConnectionConfigurationHandlerBuilder
et en fournissant une implémentation personnalisée de l’interface ConnectionConfigurationInputValidator
.
La réponse suivante est une réponse valide de l’implémentation personnalisée avec transformation :
{
"response_code" : "OK",
"config": {
"key1": "value1",
"key2": "value2"
}
}
Mise à jour de la configuration¶
Une fois les validations transmises avec succès, la configuration sera sauvegardée dans la table interne APP_CONFIG
. Le service responsable de cette opération enregistre le Variant
fourni sous la clé connection_configuration
. Cette configuration n’obéit à aucune exigence supplémentaire lors de l’enregistrement, l’ensemble des propriétés fournies est laissé à l’appréciation de l’utilisateur.
Rappel interne¶
Le rappel interne est une autre étape personnalisable. Par défaut, il appelle PUBLIC.SET_CONNECTION_CONFIGURATION_INTERNAL(connection_configuration VARIANT)
, qui renvoie 'response_code': 'OK'
. Par exemple, il peut être utilisé pour modifier d’autres procédures en leur accordant une intégration d’accès externe. Il peut être remplacé par le script SQL ou en utilisant un ConnectionConfigurationHandlerBuilder
pour fournir une implémentation personnalisée de l’interface ConnectionConfigurationCallback
.
Validation de la connexion¶
Cette étape déclenche une procédure PUBLIC.TEST_CONNECTION
. Cette procédure tente d’interroger le système source pour obtenir les données. Cette procédure n’est pas mise en œuvre par défaut et doit être fournie par l’utilisateur de SDK. En outre, l’implémentation de l’interface ConnectionValidator
peut être fournie à ConnectionConfigurationHandlerBuilder
pour personnaliser cette phase ; dans cette casse, il n’est pas nécessaire d’implémenter une procédure stockée. Il est recommandé d’effectuer un contrôle de connectivité minimal dans cette procédure pour s’assurer que les capacités d’accès externe de Snowflake ont été configurées correctement et que le connecteur dispose de tous les privilèges requis pour les utiliser.
Mise à jour du statut¶
Lorsque toutes les phases ci-dessus sont achevées avec succès, le statut interne du connecteur est mis à jour :
{
"status": "CONFIGURING",
"configurationStatus": "CONNECTED"
}
Pour le diagramme complet des transitions d’état, voir Débit du connecteur.
Affichage de la configuration¶
Les utilisateurs de ADMIN
et VIEWER
disposent d’une procédure PUBLIC.GET_CONNECTION_CONFIGURATION()
qui renvoie la configuration actuelle de la connexion à partir de la table interne.
Réponse¶
Réponse aboutie¶
Si la procédure se termine avec succès, elle renvoie une réponse de la procédure TEST_CONNECTION
. Nous vous recommandons d’utiliser le format suivant :
{ "response_code": "OK" }
Erreur de réponse¶
En cas d’erreur, la réponse suivra le format ci-dessous :
{ "response_code": "<ERROR_CODE>", "message": "<error message>" }
Les codes d’erreur possibles sont les suivants :
INVALID_CONNECTOR_STATUS
- Statut du connecteur non valide. Statut attendu :[CONFIGURING]
INVALID_CONNECTOR_CONFIGURATION_STATUS
- Statut de configuration du connecteur non valide. Statut attendu :CONFIGURED
INTERNAL_ERROR
- Quelque chose s’est mal passé en interne, le message doit être descriptifPROCEDURE_NOT_FOUND
- La procédure appelée n’existe pas. Dans le cas présent, il s’agit principalement de la procédureTEST_CONNECTION
UNKNOWN_SQL_ERROR
- Cette erreur se produit lorsque quelque chose d’inattendu se produit lors de l’appel de procédures internesINVALID_RESPONSE
- Cette erreur se produit lorsque la réponse reçue de la procédure interne ne contient pas deresponse_code
ou qu’une erreur de réponse ne contient pas demessage
, mais contient unresponse_code
UNKNOWN_ERROR
- Cela signifie que quelque chose d’inattendu s’est mal passé - le message de l’exception levée est transmisCodes d’erreur personnalisés reçus de la procédure
TEST_CONNECTION()
- définis par le développeur du connecteurCodes d’erreur personnalisés reçus de la procédure
SET_CONNECTION_CONFIGURATION_INTERNAL()
- définis par le développeur du connecteur