Passer au contenu principal

Créer et réparer des connecteurs de données avec Operator

Demandez à Operator de créer, tester et réparer des connecteurs de données depuis un chat, chaque modification étant revue avant publication.

Note : Operator est inclus dans le module complémentaire Pro. Vous devez avoir le module Pro pour l'utiliser.

Configurer un connecteur de données signifie généralement lire la documentation API et remplir chaque champ manuellement. Avec Operator, vous décrivez ce que Fin doit rechercher ou mettre à jour, et Operator crée un nouveau connecteur ou répare un connecteur défaillant. Utilisez cet article pour apprendre ce que Operator peut configurer, comment revoir et tester ses propositions, et les limites à connaître.

Chaque modification arrive sous forme de proposition. Vous la révisez, approuvez chaque appel de test, puis choisissez de la publier ou de la sauvegarder en brouillon. Operator ne peut pas modifier un connecteur ni appeler une API seul.

Note : Pour discuter avec Operator, vous devez avoir la permission Can access Fin Operator. Pour appliquer une modification de connecteur, vous devez aussi avoir Can manage Automation settings and inbound Workflows et Can manage data connectors and authentication tokens.

Si vous débutez avec les connecteurs de données, commencez par Ajouter des connecteurs de données pour Fin AI Agent.


Comment créer ou réparer un connecteur de données avec Operator

Tout le processus se déroule dans un chat Operator, de la première demande au connecteur publié.

Étape 1 : Demandez à Operator

Dans un chat Operator, décrivez ce dont Fin a besoin. Par exemple :

  • « Créez un connecteur qui recherche une commande Shopify par son numéro. »

  • « Fin dit toujours qu'il ne trouve pas la commande. Pouvez-vous réparer le connecteur Get Order ? »

Étape 2 : Operator enquête

Avant de proposer quoi que ce soit, Operator peut rechercher dans votre espace de travail :

  • Recherchez vos connecteurs et lisez la configuration complète de chacun.

  • Lisez la réponse de test enregistrée d'un connecteur ou une réponse simulée.

  • Voyez quels workflows et procédures utilisent un connecteur.

  • Vérifiez les taux de réussite récents et l'historique d'exécution. Il voit le statut et le timing, pas ce qui a été envoyé ou reçu.

  • Listez les attributs qu'il peut utiliser dans la requête ou comme cibles de mappage.

  • Listez vos jetons d'authentification par nom et type. Il ne voit jamais le secret.

Étape 3 : Révisez la proposition

La proposition apparaît dans le chat sous forme de carte Data connector.

  • L'en-tête affiche le nom du connecteur et un badge New, Live, Draft ou Paused. Un renommage montre l'ancien nom barré.

  • API affiche la méthode, l'URL, les entrées de données, les en-têtes, la charge utile, le test et les jetons d'authentification.

  • Data affiche les champs de réponse, le code Python et les mappages d'objets.

  • Fin affiche l'invite que Fin lit et le public.

  • Security affiche le paramètre d'authentification client.

  • Pour une modification, la carte montre les changements par rapport à la version en direct. Les sections inchangées commencent repliées, et chaque section indique combien de lignes ont été ajoutées et supprimées.

  • Les jetons d'authentification sont affichés uniquement par leur nom.

Étape 4 : Approuvez le test

Avant qu'un test ne soit lancé, Operator affiche une carte intitulée Test « nom du connecteur » avec les valeurs qu'il enverra.

  1. Vérifiez les valeurs. Rien n'est envoyé tant que vous n'avez pas cliqué sur Run test. Cancel l'arrête.

  2. Le test appelle la vraie API. Le résultat s'affiche par exemple « Test réussi (HTTP 200) » ou « Test échoué (HTTP 401) ».

  3. Operator lit la réponse et l'utilise pour configurer les champs de réponse.

Operator peut aussi poser une question test à Fin dans une conversation de prévisualisation, comme le ferait un client. Cela montre si Fin choisit le connecteur et comment il utilise la réponse. En prévisualisation, Fin répond comme si les modifications en attente du connecteur dans le chat étaient déjà appliquées, et il utilise la réponse de test enregistrée ou simulée au lieu d'appeler l'API.

Important : Les tests envoient de vraies requêtes au système connecté. Si un connecteur crée, met à jour ou supprime des données, le tester effectue cette modification. Utilisez des enregistrements de test. Operator demande votre approbation avant chaque test.

Étape 5 : Appliquez la modification

Vous choisissez comment la modification est appliquée :

  • Sur un connecteur en direct, le bouton principal est Publish. Save as draft (ou Update draft, si un brouillon existe) se trouve dans le menu.

  • Sur un connecteur nouveau, brouillon ou en pause, le bouton principal est Save as draft (ou Update draft). Publish est dans le menu.

  • Publish demande d'abord « Prêt à publier ? ». Il reste désactivé tant que le test d'Operator n'a pas réussi, sauf si le connecteur utilise une réponse simulée. Une modification qui ne touche pas la requête (URL, méthode, en-têtes, corps, entrées et jetons d'authentification) conserve le test réussi précédent du connecteur.

  • Une suppression affiche un bouton rouge Delete et un avertissement indiquant que l'action est irréversible.

  • L'icône de la corbeille (Discard change) supprime la proposition.

  • Apply all applique toutes les modifications du chat. Un nouveau connecteur devient un brouillon, et une modification conserve son état en direct ou brouillon actuel.

Si quelqu'un a modifié le connecteur pendant que la proposition était en attente, la carte indique « Cette modification est basée sur une version obsolète » et appliquer demande « Appliquer par-dessus des modifications plus récentes ? ». Les modifications plus récentes sont écrasées uniquement si vous cliquez sur Apply anyway.

Étape 6 : Après application

Un message « Modifications appliquées avec succès » s'affiche, et le chat enregistre « Vous avez appliqué 1 modification » avec le connecteur marqué Published ou Draft. Chaque modification appliquée apparaît aussi dans le journal d'activité des coéquipiers comme « Proposition Operator appliquée ».

Une modification publiée fonctionne comme tout connecteur créé manuellement, et Fin commence à l'utiliser immédiatement dans les conversations. Un brouillon n'a aucun effet sur les conversations tant qu'il n'est pas publié. Les clients ne voient jamais Operator ni ses propositions.


Ce que Operator peut configurer

  • Nom et description — Les coéquipiers voient la description dans les paramètres du connecteur.

  • La requête — URL, méthode, en-têtes et corps. L'URL doit être HTTPS.

  • Entrées de données — Les valeurs que Fin collecte auprès du client, comme un numéro de commande. Chaque entrée a un nom, un type et une description, est marquée obligatoire ou optionnelle, et peut avoir une valeur par défaut.

  • Authentication tokens — Operator peut attacher ou détacher des jetons existants. Chaque jeton est envoyé comme son propre en-tête.

  • Champs de réponse — Construits à partir d'une réponse de test ou d'une réponse simulée. Ils déterminent quels champs Fin voit, leur nom, leur format et comment les valeurs codées sont traduites en mots. Un bloc de code Python peut remodeler la réponse à la place.

  • Une réponse simulée — Un exemple de corps de réponse, utilisé pour construire les champs de réponse avant que l'API puisse être testée.

  • Mappages d'objets — Écrire les valeurs de réponse dans les attributs de conversation, utilisateur ou objet personnalisé.

  • Comment Fin l'utilise — Si Fin peut choisir le connecteur seul, l'invite que Fin lit pour décider quand l'utiliser, si Fin peut écrire via ce connecteur, et un public construit à partir de segments.

  • Vérification client — Si Fin appelle le connecteur uniquement pour les clients ayant passé la vérification d'identité.

Astuce : Operator place les attributs client, comme l'email du client, directement dans la requête plutôt que de les ajouter comme entrées de données. C'est la configuration recommandée. Chaque entrée de données ajoutée par Operator est une valeur que Fin collecte auprès du client.


Limitations connues

  • Crédits Operator — Les chats Operator utilisent des crédits Operator comme tout autre travail Operator.

  • Vous appliquez chaque modification — Operator ne peut pas publier, sauvegarder ou supprimer un connecteur lui-même.

  • Les tests envoient de vraies requêtes — Si un connecteur crée, met à jour ou supprime des données, le tester effectue cette modification dans le système connecté. Utilisez des enregistrements de test.

  • Tokens — Operator ne peut pas voir les valeurs des jetons d'authentification, ni créer, modifier ou supprimer des jetons. Ajoutez un nouveau jeton dans les paramètres d'authentification, puis demandez à Operator de l'attacher. Gardez les clés API dans les jetons, pas dans l'URL ou le corps, où Operator peut les lire.

  • Appliquer remplace les modifications de brouillon non publiées — Operator construit sa modification sur la version en direct. L'appliquer, que ce soit avec Publish ou Save as draft, remplace toutes les modifications de brouillon faites dans l'éditeur depuis. Publiez ou supprimez d'abord vos propres modifications de brouillon.

  • Les connecteurs en direct ne peuvent pas être supprimés — Operator peut supprimer uniquement les connecteurs brouillons ou en pause. Pour supprimer un connecteur en direct, mettez-le d'abord en pause dans ses paramètres. Operator ne peut pas mettre en pause, reprendre, dupliquer ou archiver des connecteurs, ni revenir à une version antérieure.

  • Connecteurs MCP — Operator ne peut pas modifier, tester ou supprimer les connecteurs provenant d'un serveur MCP. Gérez-les dans les paramètres du serveur MCP.

  • Pas de modèles — Operator ne peut pas installer un connecteur à partir d'un modèle.

  • Types d'entrée — Operator ne peut pas ajouter de valeurs d'entrée statiques, ni de types d'entrée liste ou objet.

  • Versions — Les modifications de connecteur d'Operator s'appliquent directement au connecteur. Elles ne peuvent pas être ajoutées à une Fin Release.

  • Prévisualisation Fin — Quand Operator pose une question test à Fin, Fin utilise la réponse de test enregistrée ou simulée plutôt que d'appeler l'API. Les suppressions en attente ne sont pas prévisualisées, et une modification sans réponse de test ou simulée n'a rien à retourner.

  • Lien des paramètres — Dans la liste « Vous avez appliqué » du chat, le nom du connecteur ne renvoie pas à sa page de paramètres. Ouvrez le connecteur depuis vos paramètres de connecteurs de données à la place.


FAQ

Pourquoi le bouton Publier est-il désactivé ?

Il n'y a pas de test réussi sur la dernière version de la modification. Modifier l'URL, la méthode, les en-têtes, le corps, les entrées ou les jetons d'authentification annule un test précédent. Demandez à Operator de lancer un test, ou utilisez une réponse simulée. Save as draft fonctionne toujours.

Pourquoi un test échoue-t-il avec 401 alors que le connecteur fonctionne dans les conversations ?

Les tests ne portent aucune identité d'utilisateur final, donc les connecteurs qui vérifient l'identité du client ne peuvent pas réussir un test. Les jetons de type USER envoient leur valeur de test statique à la place.

Que peut voir Operator dans mon connecteur ?

Operator ne voit jamais les valeurs des jetons d'authentification. Il voit l'URL, le corps et le bloc de code en entier, comme vos paramètres de connecteur vous les montrent, et seulement les quatre premiers caractères des valeurs d'en-tête. Dans les réponses de test, tout jeton ou identifiant que l'API renvoie est masqué.

Avez-vous trouvé la réponse à votre question ?