Gérer les erreurs

Acheminer les nœuds échoués vers les gestionnaires d'erreurs, consigner les détails des erreurs, réessayer les échecs temporaires et mettre fin aux erreurs irrécupérables avec soin.

Ce que vous allez créer: un workflow qui achemine un nœud défaillant vers un chemin distinct, enregistre l'échec avec un contexte utile, réessaie les échecs temporaires où cela a un sens et se termine proprement lorsque l'erreur est irrécupérable. Après ce guide, vous disposerez d'un modèle que vous pourrez déposer dans n'importe quel workflow existant.

Éléments requis

• Un compte UiPath Automation Cloud avec accès à Maestro Flow.
• Un workflow Flow existant avec au moins un nœud qui peut échouer et expose une gestion des erreurs, par exemple une requête HTTP ou un nœud d’extraction.

Nœuds utilisés

• Requête HTTP — le nœud sujet aux échecs dans cet exemple
• Script : consigne les détails de l'erreur
• Terminer : termine le workflow avec un statut Failed pour les erreurs irrécupérables

Étapes

1. Connecter la gestion des erreurs du nœud

Par défaut, un nœud échoué arrête l'ensemble du processus. Pour gérer plutôt l'échec:

1. Ouvrez votre workflow sur le canevas et sélectionnez le nœud sujet aux défaillances.
2. Faites glisser de sa gestion des erreurs — le connecteur en bas à droite du nœud — vers un nouveau nœud Script .

Cela crée un chemin d’erreur. Lorsque le nœud échoue, l'exécution est redirigée vers ce chemin au lieu d'arrêter le processus. (Les nœuds qui n'affichent pas une gestion des erreurs ne prennent pas en charge la gestion des erreurs — une défaillance arrête le processus et apparaît sous l'onglet Incidents .)

2. Journaliser l'erreur

Dans le nœud Script sur le chemin d'erreur, lisez l'objet d'erreur au niveau de $vars.<node>.error:

const error = $vars.httpRequest1.error;
console.log('Step failed:', error.message);
console.log('Code:', error.code, '| HTTP status:', error.status);
return { logged: true };

L'objet d'erreur est uniquement renseigné sur le chemin d'erreur. Pour obtenir sa référence complète au champ, consultez Gestion des erreurs.

3. Réessayer les échecs temporaires (facultatif)

Si l'échec est probable - un blip réseau ou une limite de débit - réessayez avant d'abandonner. Le nœud de requête HTTP a intégré les tentatives: configurez le nombre de réessais dans ses propriétés, et il tente à nouveau de saisir la requête plusieurs fois avant de déclencher la gestion des erreurs. Seul l'échec final est redirigé vers le chemin d'erreur.

Avertissement :

Réessayez uniquement les opérations idempotentes. Réessayer un nœud avec des effets secondaires (écrire des données, envoyer un message) peut créer des doublons.

4. Terminer si non-récupérable

Sur le chemin de l'erreur, après le nœud Script, ajoutez un nœud Terminer . Définir:

• Statut → Failed
• Message → une description qui inclut l'erreur, par exemple $vars.httpRequest1.error.message

Il enregistre l'échec dans l'historique des exécutions avec une description utile, visible dans la section Observer les exécutions.

5. Tester et déboguer

Pour déclencher intentionnellement le chemin d'erreur:

1. Définissez temporairement l'URL dans le nœud de la requête HTTP sur une valeur non valide (par exemple, https://this-will-fail.example.com).
2. Exécutez le test et vérifiez le routage de la trace d'exécution le long du chemin d'erreur.
3. Restaurez l’URL correcte.

Vérifiez la sortie de la console du nœud Script dans le traçage pour confirmer que les détails de l’erreur sont consignés.

Résultat

Votre workflow achemine les échecs vers le chemin d'erreur, consigne les détails de l'erreur, réessaie éventuellement les échecs temporaires et se termine proprement avec un statut d'échec descriptif. Vous pouvez confirmer que le chemin d'erreur fonctionne en utilisant une URL non valide dans le nœud de la requête HTTP et en inspectant la sortie de la console du nœud Script dans la Trace d'exécution.

Étendre ce workflow

• Envoyer une alerte en cas d'échec - Sur le chemin d'Error, avant le nœud Terminer, ajoutez une requête HTTP ou un nœud d'intégration pour notifier un canal Slack ou créer un ticket d'incident.
• Continuer au lieu de se terminer - Si l'étape n'est pas critique, le chemin d'erreur doit définir une valeur de secours et rejoindre le chemin principal au lieu de se terminer.
• Appliquer ce modèle partout - Pour plus de modèles (log et continuer, valeurs de secours, escalade), consultez la section Référence de gestion des erreurs .