Intégration Databricks n8nAutomatiser Databricks avec n8n.

Exécute du SQL sur un warehouse et attend le résultat, pour que le nœud suivant reçoive des lignes et non une référence de job.

• Warehouse : le warehouse SQL qui exécute l'instruction, choisi dans la liste ou désigné par son identifiant.
• Query : l'instruction elle-même, du genre SELECT * FROM my_table LIMIT 10.
• Query Parameters : des valeurs nommées, appelées dans le SQL sous la forme :name, pour écrire WHERE ID = :user_id plutôt que de coller une valeur dans la chaîne.

Crée un dossier à l'intérieur d'un volume. C'est l'étape que fait un workflow avant d'écrire des fichiers dans un chemin qui n'existe pas encore.

• Volume Path : le volume visé, au format catalog.schema.volume.
• Directory Path : l'emplacement du dossier dans ce volume, imbriqué comme folder1/subfolder, sans barre oblique initiale.

Supprime un dossier du volume. C'est la moitié ménage d'une routine d'export qui, sans elle, empile les répertoires indéfiniment.

• Volume Path : le volume qui contient le dossier, écrit catalog.schema.volume.
• Directory Path : le dossier à retirer, relatif à la racine du volume et sans barre oblique initiale.

Efface un fichier précis d'un volume. Il se désigne par son chemin et non par un identifiant : le workflow doit savoir où il l'a déposé.

• Volume Path : le volume concerné, au format catalog.schema.volume.
• File Path : le fichier dans ce volume, par exemple folder/file.txt, toujours sans barre oblique initiale.

Récupère le contenu d'un fichier stocké dans un volume et le remet au workflow en données binaires, prêtes à être transmises, jointes ou analysées.

• Volume Path : le volume à lire, au format catalog.schema.volume.
• File Path : le fichier à sortir, par exemple folder/file.txt, sans barre oblique initiale.

Lit les métadonnées que Databricks tient sur un fichier, sans déplacer son contenu. Un contrôle reste léger quand le workflow veut seulement savoir si le fichier est arrivé.

• Volume Path : le volume à inspecter, écrit catalog.schema.volume.
• File Path : le fichier à interroger, du type folder/file.txt, sans barre oblique initiale.

Renvoie le contenu d'un chemin de volume, un item par fichier, ce qui permet à un workflow de boucler sur un lot qu'il n'a pas produit lui-même.

• Volume Path : le volume à parcourir, au format catalog.schema.volume.
• Directory Path : facultatif ; laissé vide, la racine du volume est listée.
• Page Size et Page Token : le nombre de fichiers par page, et le jeton qui va chercher la suivante.

Écrit dans un volume les données binaires portées par l'item entrant, pour des fichiers allant jusqu'à 5 GiB.

• Volume Path : le volume de destination, au format catalog.schema.volume.
• File Path : l'emplacement du fichier à l'intérieur, par exemple folder/file.txt.
• Input Data Field Name : le nom du champ de l'item entrant qui porte les données binaires.
• Overwrite : indique si un fichier déjà présent à ce chemin doit être remplacé.

Envoie une question de relance dans une conversation Genie déjà ouverte, pour que l'échange garde son contexte au lieu de repartir de zéro.

• Space ID : l'espace Genie auquel appartient la conversation.
• Conversation ID : le fil à poursuivre, en général repris d'un nœud précédent par une expression du type {{ $json.field }}.
• Message : la question, formulée comme un collègue la poserait.

Quand Genie répond avec une pièce jointe SQL, cette opération exécute l'instruction attachée sur le warehouse de l'espace.

• Space ID et Conversation ID : l'espace et le fil d'où vient la réponse.
• Message ID : la réponse qui porte la pièce jointe.
• Attachment ID : la pièce jointe précise à exécuter, un même message pouvant en porter plusieurs.

Relit un message précis d'une conversation. C'est par là qu'un workflow vérifie si Genie a terminé de composer sa réponse.

• Space ID : l'espace Genie concerné.
• Conversation ID : le fil auquel le message appartient.
• Message ID : le message à relire, référencé depuis un nœud précédent par une expression comme {{ $json.field }}.

Décrit un espace Genie, ce qui permet à un workflow de confirmer qu'il vise le bon avant de commencer à l'interroger.

• Space ID : la seule information demandée ici, et la même valeur que réclament toutes les autres opérations Genie.

Rassemble les lignes produites par l'exécution SQL d'une pièce jointe, l'étape qui transforme enfin une réponse Genie en données exploitables.

• Space ID et Conversation ID : l'espace et le fil consultés.
• Message ID : la réponse dont la requête a été lancée.
• Attachment ID : la pièce jointe dont tu veux récupérer les résultats.

Ouvre un nouveau fil dans un espace Genie avec une première question en langage courant. Tout le reste de la ressource Genie s'accroche à la conversation ainsi créée.

• Space ID : l'espace qui va répondre.
• Initial Message : la question d'ouverture, que tu peux construire depuis un nœud précédent avec une expression du type {{ $json.field }}.

Transmet une charge utile à un endpoint de model serving et rend la réponse du modèle. Le nœud va chercher le schéma OpenAPI de l'endpoint pour déterminer l'URL d'invocation et le format d'entrée attendu.

• Endpoint : l'endpoint de serving à interroger, choisi dans la liste ou désigné par son nom.
• Request Body : la charge utile JSON, validée à l'exécution contre le schéma de l'endpoint, donc un corps mal formé échoue tout de suite.

Dans Unity Catalog, le catalogue est le contenant le plus haut : il abrite les schémas, qui abritent les tables. L'opération en enregistre un nouveau dans le workspace Databricks.

• Catalog : le catalogue à utiliser, choisi dans la liste du workspace ou saisi directement.
• Comment : une description facultative, avec Catalog description comme exemple affiché dans le champ. Utile dès que plusieurs équipes partagent le même workspace.

Enregistrer une fonction SQL met une expression réutilisable à disposition de tout ce qui interroge le schéma.

• Catalog et Schema : l'endroit où la fonction est posée, tous deux pris dans les listes du workspace.
• Function Name : son nom, sur le modèle my_function.
• Input Parameters : un tableau JSON où chaque paramètre porte name, type_name et type_text.
• Return Type : le type renvoyé, par exemple STRING, INT ou DOUBLE.
• Routine Body : le langage du corps de la fonction. Routine Definition : le corps lui-même, une expression SQL du genre RETURN x + 1.

Ici, créer une table revient à déclarer un emplacement de stockage. L'API Create Table ne prend en charge que les tables Delta externes, donc la donnée existe déjà quand l'étape s'exécute.

• Catalog, Schema : le couple qui situe la nouvelle table.
• Table Name : le nom enregistré, sur le modèle my_table.
• Storage Location : l'URL racine du stockage externe, par exemple s3://my-bucket/path/to/table.
• Columns, dans Additional Fields : un tableau JSON de définitions de colonnes, chacune avec un nom et un type_name parmi STRING, LONG, DOUBLE, BOOLEAN, DATE ou TIMESTAMP.

Un volume, c'est l'endroit d'Unity Catalog prévu pour des fichiers et non pour des lignes. Le déclarer donne une destination gouvernée aux étapes qui manipulent des fichiers.

• Catalog, Schema : les deux niveaux parents du volume.
• Volume Name : le nom du volume, du type my_volume.
• Volume Type : avec MANAGED, Databricks gère le stockage du volume ; avec EXTERNAL, le volume pointe vers un stockage externe.
• Storage Location, dans Additional Fields : l'emplacement de stockage externe, requis pour les volumes EXTERNAL.

Supprimer un catalogue retire le contenant le plus large d'Unity Catalog, celui qui porte les schémas. C'est la suppression devant laquelle une étape de validation manuelle a du sens.

• Catalog : le catalogue à utiliser, sélectionné dans la liste ou passé par une expression comme {{ $json.field }} quand le nom vient d'un nœud précédent.

Une fonction SQL remplacée par une version plus récente n'a plus de raison de rester. L'opération retire l'ancienne définition de son schéma.

• Catalog, Schema : l'endroit où la fonction avait été enregistrée.
• Function : la fonction visée, sélectionnée dans le resource locator et pas tapée comme un simple libellé.

La suppression retire l'enregistrement de la table dans Unity Catalog. La table s'identifie par sa place dans la hiérarchie, jamais par son nom seul, d'où les trois champs à remplir ensemble.

• Catalog et Schema : les deux niveaux au-dessus de la table.
• Table : la table visée, choisie parmi celles du schéma.

Un volume devenu inutile se retire ici. Le nœud attend le nom du volume, pas le chemin de stockage qui se trouve derrière.

• Catalog, Schema : le contenant dans lequel se trouve le volume.
• Volume Name : le nom du volume, par exemple my_volume.

Les informations d'un catalogue reviennent sous forme d'un item unique, sur lequel le workflow peut se brancher avant d'écrire quoi que ce soit dedans.

• Catalog : le catalogue à utiliser. Enchaîne avec un nœud IF pour orienter la suite selon ce que la lecture renvoie.

Avant qu'un workflow s'appuie sur une fonction SQL, relire sa définition enregistrée montre ce qu'elle attend en entrée et ce qu'elle renvoie.

• Catalog, Schema : où chercher.
• Function : la fonction visée, résolue par le resource locator.

Les informations d'une table, ce sont ses caractéristiques déclarées, pas les lignes qu'elle contient. C'est ce que lit une étape qui a besoin de savoir à quoi elle a affaire.

• Catalog et Schema : le chemin jusqu'à la table.
• Table : la table visée, prise dans le resource locator.

Vérifier un volume avant d'y déposer des fichiers évite une exécution qui échoue à mi-parcours. L'opération renvoie les informations du volume.

• Catalog, Schema : les deux noms qui cadrent la recherche.
• Volume Name : le volume lui-même, du type my_volume.

Tous les catalogues visibles par le credential, c'est-à-dire par l'identité que porte la connexion Databricks, reviennent en un appel, sans le moindre champ à remplir. C'est le point de départ logique quand le workflow travaille à l'échelle du workspace et pas sur un catalogue connu d'avance.

Les fonctions s'accumulent sans qu'on y prenne garde. L'opération liste ce qui est enregistré, et comme les deux filtres sont facultatifs, un appel sans filtre ratisse plus large qu'un seul schéma.

• Catalog : filtre par catalogue, facultatif.
• Schema : filtre par schéma, facultatif, et il réclame qu'un catalogue soit renseigné à côté.

Les tables enregistrées dans un schéma arrivent sous forme d'items, un par table, prêts à être parcourus. Laisser les deux filtres vides élargit l'appel au lieu de le restreindre.

• Catalog : filtre facultatif sur le catalogue.
• Schema : filtre facultatif sur le schéma, qui ne s'applique qu'une fois le catalogue choisi.

Toute revue de stockage commence par savoir ce qui existe. L'opération renvoie les volumes déclarés dans un schéma, ce qui permet de boucler dessus plutôt que d'écrire les noms en dur.

• Catalog : facultatif, restreint la liste à un catalogue.
• Schema : facultatif, et il a besoin d'un catalogue renseigné à ses côtés.

Les métadonnées d'un catalogue vieillissent vite quand les équipes bougent. La mise à jour touche les informations du catalogue et laisse son contenu intact.

• Catalog : le catalogue à utiliser, ici celui qu'on met à jour.
• Comment : la description facultative, avec Catalog description affiché en exemple. C'est la partie que les équipes tiennent réellement à jour.

Tout montage de recherche vectorielle commence par l'index : c'est lui que les requêtes interrogeront ensuite, et il appartient à un endpoint.

• Index Name et Endpoint Name : l'index créé et l'endpoint de recherche vectorielle qui l'héberge.
• Primary Key : la colonne clé primaire de l'index, avec ID comme exemple affiché.
• Index Type : DELTA_SYNC se synchronise automatiquement avec une table Delta source, DIRECT_ACCESS permet la lecture et l'écriture directes des vecteurs et de leurs métadonnées.
• Delta Sync Index Spec et Direct Access Index Spec : la spécification JSON propre à chacun de ces deux types.

Le détail d'un index répond à la question que se pose un workflow juste avant de chercher : est-ce que cet index est bien là ? Un seul champ suffit.

• Index Name : le nom de l'index de recherche vectorielle, saisi ou transmis par un nœud précédent avec une expression comme {{ $json.field }}.

Un même endpoint peut porter plusieurs index. L'opération les renvoie tous, cadrés sur l'endpoint indiqué, ce qui garde un résultat lisible même dans un workspace chargé.

• Endpoint Name : l'endpoint de recherche vectorielle dont tu veux la liste des index.

La recherche sémantique sur un index part de cette opération, soit depuis du texte brut, soit depuis des vecteurs calculés en amont.

• Query Type : avec text, Databricks convertit ton Query Text en vecteurs ; avec vector, c'est le Query Vector fourni qui part en recherche.
• Index Name : l'index interrogé.
• Columns to Return : la liste des colonnes à ramener, séparées par des virgules, du type content, url.
• Search Mode : HYBRID combine recherche sémantique et recherche par mots-clés, ANN reste sur la similarité vectorielle pure.
• Score Threshold, dans Options : le score de pertinence minimum, entre 0 et 1.