Gestion des erreurs

Comment une défaillance de nœud peut être acheminée vers un chemin distinct via la gestion des erreurs du nœud, et comment les détails de l'erreur sont exposés via des variables.

La gestion des erreurs est un mécanisme par nœud qui contrôle ce qui se passe lorsqu'un nœud échoue lors d'une exécution. Par défaut, un nœud échoué arrête l'ensemble du workflow. La connexion de la gestion des erreurs du nœud achemine l’échec vers un chemin distinct, où le workflow peut inspecter et répondre à l’erreur.

Mode de fonctionnement

Chaque nœud qui prend en charge la gestion des erreurs dispose d'un onglet Gestion des erreurs dans son panneau Propriétés. Le bouton Activer la gestion des erreurs dans cet onglet ajoute une gestion de sortie d'erreur au nœud, un deuxième connecteur de sortie intitulé Erreur, en dessous de la gestion de sortie principale sur le côté droit du nœud, qui s'active lorsque le nœud échoue. La plupart des nœuds prennent en charge la gestion des erreurs.

Lorsqu’un nœud avec une gestion des erreurs connectée échoue, l’exécution suit le chemin de l’erreur au lieu d’arrêter le workflow. Les détails de l’erreur deviennent disponibles sous la forme d’une variable que les nœuds ultérieurs peuvent lire.

Lorsqu'un nœud sans gestion des erreurs connectée échoue, l'exécution s'arrête à ce nœud. Dans une exécution de test, l'erreur apparaît dans l'onglet Incidents , sous la zone de dessin. Dans une exécution déployée, l'exécution est suspendue jusqu'à ce que vous la réessayiez ou l'annuler, comme décrit dans Réessayer et annuler .

Nouvelles tentatives de demande HTTP

Le nœud de requête HTTP prend en charge les nouvelles tentatives configurables. Lorsque les nouvelles tentatives sont configurées, le nœud tente la requête le nombre spécifié de fois avant de déclencher la gestion des erreurs. Si toutes les nouvelles tentatives échouent et qu’une gestion des erreurs est connectée, l’exécution suit le chemin de l’erreur. Si aucune gestion des erreurs n'est connectée, le workflow échoue.

Configuration des gestionnaires d'erreurs

L'activation de l'option Activer la gestion des erreurs dans l'onglet Gestion des erreurs du panneau Propriétés ajoute la gestion des erreurs au nœud. La connexion de la gestion d'erreur à un autre nœud sur le canevas connecte le chemin d'erreur. Un nœud sans gestion des erreurs ne prend pas en charge la gestion des erreurs. Par conséquent, tout échec arrête le workflow.

L'objet d'erreur

Lorsqu'une gestion des erreurs est connectée et que le nœud échoue, les détails de l'erreur sont disponibles sous la forme $vars.<nodeName>.error. L’objet comporte les champs suivants:

• code: un code lisible par machine qui identifie le type d'échec.
• message: une description lisible par un humain de ce qui ne va pas, adaptée à la journalisation ou à l'affichage à un utilisateur.
• detail: une description technique de l'échec, y compris des traces de pile (la liste des appels qui ont conduit à l'échec) ou des informations spécifiques au service lorsqu'elles sont disponibles.
• category: la catégorie d'erreur, qui regroupe les types d'erreur liés.
• status: le code de statut HTTP qui appartient à l'erreur, par exemple 404 ou 500. Il est renseigné pour les échecs liés à HTTP.

L'objet d'erreur est uniquement disponible sur le chemin d'erreur. L'accès à $vars.<nodeName>.error dans la chaîne de réussite renvoie la valeur undefined.

Exemple pratique

Cet exemple utilise un nœud de requête HTTP pour appeler une API externe, avec un nœud Script sur le chemin d'erreur qui consigne l'échec. Le nœud de requête HTTP est configuré avec l’URL cible. Sa gestion des erreurs est connectée à un nœud Script . Le nœud Script lit l'objet d'erreur comme suit:

const error = $vars.httpRequest1.error;
return {
  failed: true,
  reason: error.message,
  httpStatus: error.status,
  detail: error.detail
};

Lorsque la requête HTTP réussit, l'exécution suit le chemin de réussite et le nœud Script est ignoré. Lorsque la demande échoue, après toutes les nouvelles tentatives configurées, l'exécution suit le chemin d'erreur vers le nœud Script, qui reçoit l'objet d'erreur complet.

En cas d'exécution réussie, le chemin de réussite s'exécute et le chemin d'erreur est ignoré:

En cas d'échec de l'exécution, le chemin d'erreur s'exécute à la place:

Modèles

Ce sont des approches courantes de la gestion, de la journalisation, du réessai et de l'escalade des erreurs. Ils s'appuient tous sur la gestion des erreurs par nœud décrite ci-dessus : une gestion des erreurs connectée achemine les échecs vers un chemin distinct, où l'objet d'erreur est disponible sur $vars.<node>.error.

Enregistrer et continuer

Ce modèle correspond aux opérations non critiques dans lesquelles le workflow doit se poursuivre même si une étape échoue. La gestion des erreurs du nœud se connecte à un nœud Script qui consigne l'erreur, puis rejoint le chemin principal pour que l'exécution se poursuit.

// Script node on the error path
console.log('Non-critical step failed:', $vars.step1.error.message);
return null; // downstream nodes handle null gracefully

Nouvelle tentative avec limite

Ce modèle correspond aux défaillances susceptibles d'être temporaires, telles que l'expiration du réseau, les limites de débit ou les interruptions de service. Pour le nœud de requête HTTP , le nombre de nouvelles tentatives intégré tente à nouveau de lancer la requête avant de déclencher la gestion des erreurs, et seul l'échec final est redirigé vers le chemin d'erreur. Les paramètres de nouvelle tentative appartiennent uniquement aux opérations idempotentes.

Alerte et résiliation

Ce modèle correspond aux erreurs irrécupérables qui nécessitent une attention humaine. Sur le chemin d'Error, une notification est envoyée via une requête HTTP ou un nœud d'intégration, puis un nœud Terminer met fin au workflow, avec une variable de sortie qui contient un message descriptif tel que $vars.step1.error.message

Valeur de repli

Ce modèle s'adapte aux opérations qui peuvent échouer, mais qui ont une valeur par défaut sécurisée qui permet au workflow de se poursuivre de manière significative. Sur le chemin d'erreur, un nœud Script définit la sortie attendue sur une valeur par défaut, puis rejoint le chemin principal comme si l'opération avait réussi.

Erreurs courantes

• Autorisation silencieuse des erreurs: les erreurs sur le chemin de l'erreur doivent toujours être journalisées, même lorsque le workflow se poursuit. Les défaillances silencieuses sont difficiles à diagnostiquer ultérieurement.
• Réessayer des opérations qui ne peuvent pas se répéter en toute sécurité: les opérations avec des effets secondaires, telles que l’écriture de données ou l’envoi d’un message, peuvent produire des doublons si elles sont réessayées. Les paramètres de nouvelle tentative appartiennent uniquement aux opérations qui peuvent s’exécuter plusieurs fois sans créer de doublons.
• Laisser les gestions d’erreur non connectées: un nœud dont la gestion d’erreur n’est pas connectée échoue l’ensemble du workflow en cas d’erreur. Un workflow qui doit se poursuivre au-delà d'un échec a besoin d'un chemin d'erreur connecté.

Prochaines étapes

• Gérer les erreurs: une tâche étape par étape qui crée un chemin d'erreur.
• La zone de dessin Flux: l'espace de travail, y compris le panneau sous la zone de dessin.
• Variables et flux de données: comment les données sont transmises entre les nœuds avec $vars.
• Bases du débogage: conseils pour inspecter les erreurs lors d'une exécution de débogage.
• Community (Communauté): posez des questions et partagez des workflows avec d'autres développeurs sur le forum UiPath.