Principes de base du débogage

Déboguer un workflow sur le canevas: démarrer une exécution de débogage, lire les résultats, rechercher les échecs et tester des parties d'un workflow avec des simulations.

Le débogage se produit sur le même canevas où un workflow est créé. Il n'existe pas de vue de débogage distincte: une exécution de débogage démarre à partir du canevas, le panneau inférieur au canevas affiche les résultats et des modifications sont apportées au canevas lorsqu'un problème apparaît.

Démarrage d’une session de Debug

Run Debug (▶) in the bottom toolbar of the canvas starts a debug run, in every tool. If the trigger has inputs, a dialog asks for their values. In Studio Web, Debug at the top left of the toolbar does the same. A panel appears below the canvas, and the execution trace fills in as each node runs.

Arrêter le débogage met fin à l'exécution explicitement, et toute modification apportée au workflow la met également fin. Le canevas Flux décrit entièrement les contrôles de débogage et le panneau situé sous le canevas.

Lire les résultats

L'onglet Exécutions sous le canevas comporte trois parties, chacune répondant à une question différente:

• Exécutions de Debug: la liste des exécutions, avec le nom, la durée et l'âge de chacune.
• Trace d’exécution: chaque nœud qui a été exécuté, dans l’ordre, avec une synchronisation et un indicateur de réussite ou d’échec. La sélection d'un nœud dans le traçage le met en surbrillance sur la zone de dessin, et le survol d'un nœud affiche le début et la fin du processus.
• Détails: pour une exécution, les onglets Variables, Incidents et Métadonnées . Pour un nœud, les entrées qu'il a reçues et les sorties qu'il produit.

L'onglet Incidents répertorie les erreurs d'exécution, regroupées par nœud. Chaque incident nomme le nœud qui a échoué et inclut le message d'erreur. Il est préférable de vérifier un arrêt inattendu en premier.

L'onglet Variables affiche les valeurs des variables de runtime dans trois sections: Entrées (valeurs transmises au workflow), Sorties (valeurs qu'il a produites) et Variables (variables de workflow internes). La sélection d'un nœud dans le traçage affiche l'état à ce point. Un champ Filtrer les variables recherche les valeurs par nom.

Identification des échecs

Après une exécution de Debug, chaque nœud sur la zone de dessin affiche un indicateur de réussite ou d'échec. Le nœud ayant échoué est également indiqué dans le traçage de l'exécution, et l'onglet Incidents affiche le message d'erreur.

L’objet d’erreur comprend un champ message (description lisible par un humain) et un champ detail (provoque technique). Le champ message contient le résumé de l'échec destiné à l'utilisateur, c'est donc l'endroit par où commencer.

Utilisation de nœuds simulés

Une simulation statique teste une partie d'un workflow de manière isolée. Un nœud avec une simulation statique ne s’exécute pas et transmet les données simulées aux nœuds qui le suivent. Cela est utile lorsqu’un nœud antérieur est lent, a besoin d’informations d’identification qui ne sont pas disponibles localement ou dépend de systèmes externes. La vue développée du nœud, qui s’ouvre en double-cliquant sur le nœud, comporte un menu de mode dans la colonne Sortie . La simulation statique remplace la réponse réelle par les données attendues par les nœuds ensuite, et la génération de la réponse est générée par un LLM qui produit la réponse. La simulation de sortie décrit les deux.

La simulation de plusieurs nœuds à la fois permet au débogage de se concentrer sur une section spécifique du workflow.

Astuces

• Tout d’abord, le traçage de l’exécution, puis les incidents: le traçage affiche l’ensemble de l’exécution, et les incidents n’affichent que ce qui a été interrompu.
• Les valeurs des variables révèle les incompatibilités de données: comparez les données reçues par un nœud avec les données attendues du nœud suivant.
• La simulation des dépendances externes permet une itération plus rapide: la simulation d’un nœud qui appelle une API ou déclenche un processus RPA permet de déboguer la logique sans attendre sur des systèmes externes.
• Les petites itérations sont plus rapides: une correction par cycle de débogage est plus efficace qu'essayer de tout corriger en une seule fois.
• Les noms de nœuds descriptifs améliorent la lisibilité du Trace: les noms de nœuds de référence de Trace et d'incidents, et les noms qui décrivent ce qu'un nœud facilite l'analyse des Traces.

Prochaines étapes

• Le canevas Flux: les commandes de débogage et le panneau sous le canevas.
• Gestion des erreurs: configuration des branches d'erreur sur les nœuds.
• Variables et flux de données: fonctionnement des variables entre les nœuds.
• Community (Communauté): posez des questions et partagez des workflows avec d'autres développeurs sur le forum UiPath.