- Primeros pasos
- Mejores prácticas
- Tenant
- Acerca del contexto de tenant
- Buscar recursos en un tenant
- Gestionar robots
- Conexión de los robots a Orchestrator
- Ejemplos de configuración
- Almacenar credenciales de robots en CyberArk
- Configuración de los robots atendidos
- Configuración de los robots desatendidos
- Almacenamiento de contraseñas de robot desatendido en Azure Key Vault (solo lectura)
- Almacenar las credenciales de robots desatendidos en HashiCorp Vault (solo lectura)
- Eliminar sesiones desconectadas y sin respuesta no atendidas
- Autenticación de Robot
- Autenticación de robots con credenciales de cliente
- Autenticación por SmartCard
- Auditoría
- Servicio de catálogo de recursos
- Contexto de carpetas
- Automatizaciones
- Procesos
- Trabajos
- Desencadenadores
- Registros
- Supervisión
- Colas
- Activos
- Depósitos de almacenamiento
- Test Suite - Orchestrator
- Integraciones
- Robots clásicos
- Solución de problemas
Excepción comercial vs. Excepción de aplicación
Es importante elegir el tipo de excepción correcto con el que falla una transacción, porque esta elección influye en si Orquestador elige reintentar la transacción del elemento de la cola o no, como se indica a continuación:
-
Una Excepción de la aplicación describe un error originado por un problema técnico, como una aplicación que no responde.
Una situación de este tipo es, por ejemplo, un proyecto que extrae los números de teléfono de una base de datos de empleados, creando elementos de cola para cada uno de ellos. Estos elementos deben ser procesados e insertados en una aplicación financiera. Si, al intentar la transacción, la aplicación financiera se congela, el UiPath Robot no puede encontrar el campo donde debe insertar el número de teléfono, y finalmente muestra un error.
Este tipo de problemas tienen la posibilidad de solucionarse simplemente reintentando la transacción, ya que la aplicación puede volver a funcionar.
-
Una Excepción de empresa describe un error originado por el hecho de que ciertos datos de los que depende el proyecto de automatización están incompletos o faltan.
Una situación de este tipo es, por ejemplo, un proyecto que extrae los números de teléfono de una base de datos de empleados, creando elementos de cola para cada uno de ellos. Estos elementos deben ser procesados e insertados en una aplicación financiera. Si a un determinado número de teléfono le falta un dígito debido a un error humano, el elemento de la cola que lo contiene deja de ser válido. Esto hace que la automatización produzca una excepción, ya que el campo Número de teléfono de la aplicación financiera no acepta un elemento de la cola que contenga un número incompleto.
Reintentar la transacción no ofrece ninguna posibilidad de resolver el problema, y hay otras medidas mejores, como notificar al usuario humano de este error.
La actividad Establecer estado de la transacción puede usarse para dar forma a la lógica de tu proyecto de manera que encapsule esta distinción de varias maneras:
- Si la actividad Establecer estado de la transacción produce un error en la transacción con Excepción de la aplicación, y la opción Reintento automático en la página Crear cola está configurada como Sí cuando se crea la cola, se reintenta el elemento de la cola.
- Por defecto, Orchestrator no reintenta las transacciones que fallan debido a Excepciones de empresa. Esto ocurre porque, al producirse una incoherencia entre el valor de la transacción y los requisitos de la empresa, puede haber errores en los datos iniciales a partir de los cuales se crearon los elementos de la cola. Es posible que se requieran acciones adicionales para solucionar este tipo de problemas, y el registro de este tipo de excepciones puede ser útil.
- Una actividad If o Decisión de flujo puede usarse para tomar diferentes cursos de acción si una transacción falla con cierto tipo de excepción, como usar la actividad Registrar mensaje para registrar un mensaje personalizado o la actividad Bandeja de mensajes para mostrar una ventana con información sobre el evento.
A continuación, puedes ver un ejemplo de un proyecto de este tipo:
La siguiente captura de pantalla muestra la asignación de las propiedades en la actividad Establecer estado de la transacción (a la izquierda) y sus campos correspondientes en la ventana Detalles de la transacción en Orchestrator.
La rama Verdadero de la actividad Decisión de flujo establece el estado de la transacción como Erróneo con una Excepción de empresa, mientras que la rama Falso lo establece como Erróneo con una Excepción de la aplicación.