Le débogage te permet de comprendre ce qui se passe dans un flux de travail, d'identifier l'étape qui pose problème et de vérifier les données transmises entre les différents blocs.
Il existe deux situations principales :
- le débogage pendant la configuration du flux de travail ;
- le débogage d'un flux de travail déjà publié.
¶ 1. Déboguer pendant la configuration du flux de travail
Pendant la création ou la modification d'un flux de travail, il est recommandé de tester les étapes progressivement.
¶ Tester d'abord le déclencheur
Commence par configurer le bloc déclencheur du flux de travail, par exemple :
- un déclenchement manuel ;
- la réception d'un webhook ;
- la soumission d'un formulaire ;
- une exécution planifiée.
Utilise le bouton de test du déclencheur pour récupérer un exemple de données.
Pour certains déclencheurs, tu devras provoquer réellement l'événement attendu. Par exemple, pour tester un webhook, envoie une requête vers l'URL fournie par Robin.
Une fois le test terminé, Robin affiche les données produites par le déclencheur. Ces données pourront être utilisées dans les étapes suivantes du flux de travail.
¶ Tester les blocs étape par étape
Après avoir testé le déclencheur, configure puis teste chaque bloc dans l'ordre du flux de travail.
Pour chaque nouveau bloc :
- configure ses paramètres ;
- sélectionne les données provenant des étapes précédentes ;
- lance son test ;
- vérifie son résultat avant de passer au bloc suivant.
Cette méthode permet d'identifier immédiatement l'étape à l'origine d'un problème.
Un bloc ne peut généralement être testé correctement que si les blocs précédents disposent déjà de données de test.
¶ Inspecter l'entrée et la sortie d'un bloc
Après le test d'un bloc, examine les données affichées dans son résultat.
Vérifie notamment :
- les données reçues par le bloc ;
- les paramètres calculés à partir des étapes précédentes ;
- la sortie produite ;
- les éventuels messages d'erreur ;
- les identifiants, dates, statuts ou valeurs utilisés dans les étapes suivantes.
Les données circulent du haut vers le bas du flux de travail. Chaque bloc peut utiliser les sorties produites par les blocs précédents.
Par exemple, si un bloc de recherche ne retourne aucun élément, les blocs suivants peuvent recevoir une liste vide ou une valeur inexistante.
¶ Vérifier les données utilisées dans les champs dynamiques
Lorsqu'un champ utilise une donnée provenant d'une étape précédente, vérifie que :
- le bon bloc source est sélectionné ;
- le bon champ est utilisé ;
- la valeur existe réellement dans les données de test ;
- le type de donnée est correct ;
- la valeur correspond au format attendu par le bloc.
Exemples de problèmes fréquents :
- utilisation d'un identifiant à la place d'un nom ;
- utilisation d'un texte à la place d'une liste ;
- date fournie dans un format incorrect ;
- champ absent dans certains événements ;
- liste vide ;
- connexion ou autorisation invalide.
¶ Tester les différentes branches
Si ton flux de travail comporte un routeur, une condition ou plusieurs branches, teste chaque cas séparément.
Prépare des données permettant de vérifier :
- le cas où la condition est vraie ;
- le cas où la condition est fausse ;
- chaque valeur possible d'un routeur ;
- le comportement lorsqu'une donnée est absente ;
- le comportement lorsqu'aucun élément n'est trouvé.
Le fait qu'une branche fonctionne ne garantit pas que les autres fonctionneront également.
¶ Attention aux modifications non publiées
Les modifications réalisées dans l'éditeur restent dans une version brouillon tant que tu ne les publies pas.
Le flux de travail exécuté automatiquement continue d'utiliser la dernière version publiée. Pour rendre tes modifications actives, pense à publier la nouvelle version.
¶ 2. Déboguer un flux de travail publié
Une fois le flux de travail publié, le débogage s'effectue à partir de l'historique des exécutions.
¶ Consulter les exécutions
Depuis Robin :
- ouvre le menu Exécutions ;
- recherche l'exécution concernée ;
- regarde son statut.
Tu pourras ainsi vérifier si le flux de travail s'est réellement déclenché, à quel heure et s'il a bien réussi.
¶ Comparer une exécution réussie et une exécution en erreur
Si le flux de travail fonctionnait auparavant, compare une ancienne exécution réussie avec l'exécution en erreur.
Recherche notamment une différence dans :
- les données reçues par le déclencheur ;
- la présence ou l'absence d'un champ ;
- le format d'une valeur ;
- la connexion utilisée ;
- la branche suivie ;
- la réponse d'une application externe.
Cette comparaison permet souvent de déterminer si le problème vient du flux de travail lui-même ou des données traitées.
¶ Corriger puis republier
Après avoir identifié le problème :
- retourne dans l'éditeur du flux de travail ;
- corrige la configuration ;
- teste à nouveau les étapes concernées ;
- publie la nouvelle version ;
- provoque une nouvelle exécution ;
- vérifie son résultat dans l'historique des exécutions.
Les modifications réalisées dans un brouillon ne sont pas prises en compte tant que tu n'as pas publié la nouvelle version.
¶ Bonnes pratiques
Lorsque tu développes un flux de travail :
- teste les blocs dans leur ordre d'exécution ;
- vérifie systématiquement la sortie de chaque bloc ;
- teste les différentes branches et conditions ;
- utilise des données représentatives des cas réels ;
- vérifie les cas où une donnée ou une liste est vide ;
- republie toujours après une correction ;
- contrôle une exécution réelle après la publication.
La règle principale est simple :
Pendant la configuration, teste chaque bloc et inspecte sa sortie. Une fois le flux de travail publié, consulte les exécutions pour voir quelles étapes ont été exécutées et identifier rapidement celle qui rencontre un problème.
Cette page ne te semble pas claire ou tu as besoin d'aide ? N'hésite pas à nous contacter à support@zozio.tech !