- Comience ya
- Crear
- El lienzo
- Variables y flujo de datos
- Sintaxis de expresión
- Flujo de control
- Administración de errores
- Salida simulada
- Evaluaciones
- Añadir un agente de IA a un flujo de trabajo
- Llamar a una API externa
- Procesar correos electrónicos entrantes
- Crear un flujo de trabajo de notificación de Slack
- Añadir aprobación humana a un flujo de trabajo
- Crear un flujo de trabajo de agente de chat
- Gestionar errores
- Fundamentos de la depuración
- Intervención humana: escalada o paso humano
- Evaluar tus flujos de trabajo
- Implementar y ejecutar
- Ejemplos
- Referencia
Administración de errores
Cómo se puede enrutar un fallo de nodo a una ruta independiente a través del controlador de errores del nodo y cómo se exponen los detalles del error a través de variables.
La gestión de errores es un mecanismo por nodo que controla lo que sucede cuando un nodo falla durante una ejecución. De forma predeterminada, un nodo fallido detiene todo el flujo de trabajo. Conectar el controlador de errores del nodo enruta el fallo a una ruta independiente, donde el flujo de trabajo puede inspeccionar y responder al error.
Cómo funciona
Cada nodo que admite la gestión de errores tiene una pestaña Gestión de errores en su panel de propiedades. La alternancia Habilitar gestión de errores en esa pestaña añade un controlador de salida de error al nodo, un segundo conector de salida etiquetado como Error, debajo del controlador de salida principal en el lado derecho del nodo, que se activa cuando el nodo falla. La mayoría de los nodos admiten la gestión de errores.
Cuando falla un nodo con un controlador de error conectado, la ejecución sigue la ruta de error en lugar de detener el flujo de trabajo. Los detalles del error están disponibles como una variable que los nodos posteriores pueden leer.
Cuando falla un nodo sin un controlador de error conectado, la ejecución se detiene en ese nodo. En una ejecución de prueba, el error aparece en la pestaña Incidentes debajo del lienzo. En una ejecución implementada, la ejecución se detiene hasta que la reintentas o la cancelas, como se describe en Reintentar y cancelar .
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 error, la ejecución sigue la ruta de error. Si no se conecta ningún controlador de error, el flujo de trabajo falla.
Configurar controladores de error
Activar Habilitar gestión de errores en la pestaña Gestión de errores del panel de propiedades añade el controlador de errores al nodo. Conectar el controlador de error a otro nodo en el lienzo conecta la ruta de error. Un nodo sin un Controlador de error no admite la gestión de errores, por lo que cualquier fallo detiene el flujo de trabajo.
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. El objeto tiene estos campos:
code: un código legible por máquina que identifica el tipo de fallo.message: una descripción legible por humanos de lo que salió mal, adecuada para registrar o mostrar a un usuario.detail: una descripción técnica del fallo, incluidos los seguimientos de pila (la lista de llamadas que condujeron al fallo) o información específica del servicio cuando esté disponible.category: la categoría de error, que agrupa tipos de error relacionados.status: el código de estado HTTP que pertenece al error, por ejemplo404o500. Se rellena para fallos relacionados con HTTP.
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. El nodo de solicitud HTTP está configurado 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 sigue la ruta de error hasta el nodo Script, que recibe el objeto de error completo.
En una ejecución correcta, se ejecuta la ruta de éxito y se omite la ruta de error:
En una ejecución fallida, se ejecuta la ruta de error en su lugar:
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 los fallos que probablemente sean temporales, como los tiempos de espera de la red, los límites de tasa o las interrupciones 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 finaliza el flujo de trabajo, con una variable de salida que contiene un mensaje descriptivo como $vars.step1.error.message.
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 que no se pueden repetir de forma segura: las operaciones con efectos secundarios, como escribir datos o 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 flujo de trabajo en caso de error. Un flujo de trabajo que debe continuar más allá de un error necesita una ruta de error conectada.
Próximos pasos
- Gestionar errores: una tarea paso a paso que crea una ruta de error.
- El lienzo de flujo: el espacio de trabajo, incluido el panel debajo del lienzo.
- Variables y flujo de datos: cómo pasan los datos entre nodos con
$vars. - Fundamentos de la depuración: consejos para inspeccionar errores durante una ejecución de depuración.
- Comunidad: haz preguntas y comparte flujos de trabajo con otros constructores en UiPath Forum.