UiPath Documentation
maestro
latest
false
Guía del usuario de Maestro
Importante :
La localización de contenidos recién publicados puede tardar entre una y dos semanas en estar disponible.

Administración de errores

Controladores de error por nodo en Flujo que enrutan los fallos de nodo a una ruta independiente y exponen los detalles del error a través de variables.

Qué es

La gestión de errores en Flow es un mecanismo por nodo que te permite controlar lo que sucede cuando un nodo falla durante la ejecución. De forma predeterminada, un nodo fallido detiene todo el proceso. Puedes anular esto conectando un controlador de errores para enrutar los fallos a una ruta independiente donde inspeccionas y respondes al error.

Cómo funciona

Cada nodo que admite la gestión de errores tiene un controlador de errores: un conector de salida en la parte inferior derecha del nodo que se activa cuando el nodo falla. No todos los nodos admiten la gestión de errores; solo aquellos con el marcador supportsErrorHandling exponen un identificador de error.

Cuando falla un nodo con un identificador de error conectado, la ejecución enruta a la ruta de error en lugar de detener el proceso. Los detalles del error están disponibles como una variable que puedes leer en los nodos posteriores.

Cuando falla un nodo sin un controlador de errores conectado, todo el proceso falla inmediatamente. El error aparece en el panel de ejecución en la pestaña Incidentes .

Reintentos de solicitud HTTP

El nodo de solicitud HTTP admite reintentos configurables. Cuando se configuran los reintentos, el nodo intenta la solicitud el número de veces especificado antes de desencadenar el controlador de error. Si todos los reintentos fallan y se conecta un controlador de errores, la ejecución enruta a la ruta de error. Si no se conecta ningún controlador de errores, el proceso falla.

Configurar controladores de error

Un controlador de errores se conecta conectando el conector del controlador de errores del nodo (esquina inferior derecha) a otro nodo en el lienzo. Un nodo sin un conector de gestión de errores no admite la gestión de errores, por lo que cualquier fallo detiene el proceso.

El objeto de error

Cuando se conecta un controlador de error y el nodo falla, los detalles del error están disponibles como $vars.<nodeName>.error. Este objeto tiene los siguientes campos:

code

Un código de error legible por máquina que identifica el tipo de fallo.

Mensaje

Una descripción legible por humanos de lo que salió mal. Utilízalo para registrar o mostrar información de error.

Detalles

Una descripción técnica detallada del fallo, incluidos los seguimientos de pila o información específica del servicio cuando esté disponible.

Categoría

La categoría de error, que agrupa los tipos de error relacionados.

estado

El código de estado HTTP asociado con el error. Se rellena para fallos relacionados con HTTP (por ejemplo, 404 o 500).

El objeto de error solo está disponible en la ruta de error. Acceder $vars.<nodeName>.error en la ruta de éxito devuelve indefinido.

Ejemplo práctico

Este ejemplo utiliza un nodo de solicitud HTTP para llamar a una API externa, con un nodo de script en la ruta de error que registra el fallo.

Se coloca un nodo de solicitud HTTP en el lienzo y se configura con la URL de destino. Su manipulador de errores está conectado a un nodo de Script . El nodo Script lee el objeto de error de la siguiente manera:

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

Cuando la solicitud HTTP tiene éxito, la ejecución sigue la ruta de éxito y se omite el nodo Script. Cuando la solicitud falla (después de cualquier reintento configurado), la ejecución se enruta al nodo Script, que recibe el objeto de error completo.

Patrones

Estos son enfoques comunes para gestionar, registrar, reintentar y escalar errores. Todos se basan en el controlador de error por nodo descrito anteriormente: un controlador de error conectado enruta los fallos a una ruta independiente, donde el objeto de error está disponible en $vars.<node>.error.

Iniciar sesión y continuar

Este patrón se adapta a las operaciones no críticas en las que el flujo de trabajo debe continuar incluso si falla un paso. El controlador de errores del nodo se conecta a un nodo de Script que registra el error y luego se vuelve a unir a la ruta principal para que la ejecución continúe.

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

Reintentar con límite

Este patrón se ajusta a fallos transitorios probables, como tiempos de espera de la red, límites de tasa o interrupciones temporales del servicio. Para el nodo de solicitud HTTP , el recuento de reintentos integrado vuelve a intentar la solicitud antes de desencadenar el controlador de error, y solo el fallo final enruta a la ruta de error. La configuración de reintento pertenece solo a operaciones idempotentes.

Alertar y finalizar

Este patrón se ajusta a errores irrecuperables que requieren atención humana. En la ruta de error, se envía una notificación (a través de una solicitud HTTP o un nodo de integración), luego un nodo Terminar con estado Failed y un mensaje descriptivo como $vars.step1.error.message finaliza el flujo de trabajo.

Valor alternativo

Este patrón se ajusta a las operaciones que pueden fallar pero tienen un valor predeterminado seguro que permite que el flujo de trabajo continúe de forma significativa. En la ruta de error, un nodo de Script establece la salida esperada en un valor predeterminado y luego se vuelve a unir a la ruta principal como si la operación se hubiera realizado correctamente.

Errores comunes

  • Tragar errores de forma silenciosa : los errores en la ruta de error siempre deben registrarse, incluso cuando el flujo de trabajo continúa. Los fallos silenciosos son difíciles de diagnosticar más tarde.
  • Reintentar operaciones no idempotentes : las operaciones con efectos secundarios (escribir datos, enviar un mensaje) pueden producir duplicados si se reintentan. La configuración de reintento pertenece solo a operaciones que pueden ejecutarse más de una vez sin crear duplicados.
  • Dejar los controladores de error desconectados : un nodo cuyo controlador de error no está conectado falla todo el proceso en caso de error. Los flujos de trabajo que deben continuar más allá de un error necesitan una ruta de error conectada.

¿Te ha resultado útil esta página?

Conectar

¿Necesita ayuda? Soporte

¿Quiere aprender? UiPath Academy

¿Tiene alguna pregunta? Foro de UiPath

Manténgase actualizado