- 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
- Almacenar credenciales de robots en CyberArk
- Almacenar contraseñas de robots desatendidos en Azure Key Vault (solo lectura)
- Almacenar las credenciales de robots desatendidos en HashiCorp Vault (solo lectura)
- Almacenamiento de credenciales de Unattended Robot en AWS Secrets Manager (solo lectura)
- Eliminar sesiones desconectadas y sin respuesta no atendidas
- Autenticación de Robot
- Autenticación de robots con credenciales de cliente
- Configurar las capacidades de automatización
- Auditoría
- Configuración
- Cloud Robots
- Contexto de carpetas
- Automatizaciones
- Procesos
- Trabajos
- Apps
- Desencadenadores
- Registros
- Supervisión
- Colas
- Activos
- Depósitos de almacenamiento
- Test Suite - Orchestrator
- Servicio de catálogo de recursos
- Integraciones
- Solución de problemas
Escenarios de error
Estas son algunas de las incidencias que puedes experimentar de forma ocasional cuando retransmites en directo y/o tomas el control remoto de una ejecución en curso, junto con nuestras soluciones propuestas.
En todos los escenarios siguientes, el Robot no se conectará al sistema de transmisión en vivo y control remoto, y la sesión no se iniciará. La operación se vuelve a intentar durante la duración máxima, que es de aproximadamente un minuto, y luego se muestra un error. Los detalles sobre el error están disponibles en los registros del robot de la máquina donde falla la conexión (no en los registros de trabajo).
Si TightsVNC no está instalado, la sesión no se podrá iniciar. Asegúrese de descargarlo e instalarlo de antemano.Importante: Registrar el servidor de TightsVNC como opción de servicio del sistema (en la configuración del servicio de TightsVNC) no debe estar seleccionado. Si es así, se ignora cualquier solicitud para iniciar una sesión.
La versión que admitimos actualmente es la 2.8,75.
Cuando TightsVNC se instala como portátil, el Robot no es capaz de detectarlo.
UIPATH_TIGHTVNC_EXE_PATH
con la ruta completa que incluye tvnserver.exe
.
Cuando finaliza una sesión de transmisión en vivo y control remoto, TightsVNC se cierra automáticamente. Si intenta iniciar una sesión y el Robot detecta que TightsVNC se está ejecutando, su solicitud se ignora.
Debe cerrar la instancia de TightsVNC que está abierta.
Las máquinas que ejecutan robots de alta densidad solo admiten una sesión de transmisión en vivo y control remoto a la vez. Si intentas abrir una sesión cuando ya se está ejecutando otra, tu solicitud se ignorará.
En este caso, solo podrá acceder a la transmisión en vivo una vez que finalice el proceso que se está ejecutando actualmente.
Si inicias una sesión de transmisión en vivo y control remoto inmediatamente después de que un trabajo pase al estado En ejecución , es posible que el robot aún no esté listo para iniciarlo.
Después de un tiempo, el robot puede manejar la solicitud e iniciar la transmisión en vivo.
Esto puede deberse a una conexión de red lenta entre su máquina y la del robot, o cuando la resolución de la pantalla de la máquina del robot es grande.
Estas son algunas de las razones por las que es posible que no vea ninguna imagen en la pantalla al iniciar la transmisión en vivo.
Algunos trabajos realizan ciertas acciones antes de solicitar que se abra la interfaz de usuario de automatización. Si esto sucede, la sesión de transmisión en vivo que se abre está en blanco. Esto se traduce en que el escritorio se muestra para los robots de Windows y se muestra una pantalla en negro para los robots desatendidos de Linux y los Automation Cloud Robots, sin servidor.
Intente abrir la sesión de nuevo.
Los robots desatendidos de Linux no tienen la compatibilidad adecuada para la transmisión en vivo y el control remoto, por lo que no recomendamos que los uses para tales operaciones.
Intente usar Automation Cloud Robots, sin servidor.
Las transmisiones en vivo de procesos ejecutados en una máquina física se representan en un monitor físico.
Como tal, debe asegurarse de tener un monitor conectado.
Si te has desconectado del protocolo de escritorio remoto (RDP), las máquinas virtuales a veces dejarán de renderizar la pantalla. Esto sucede porque, una vez desconectado, no hay pantalla virtual en la que representar imágenes.
Para resolver esto, utiliza el robot en modo de servicio.
Los problemas de comunicación de red pueden hacer que se detenga una sesión de transmisión en vivo. Si esto sucede, el cliente vuelve a intentar conectarse automáticamente. Esto debería ser razonablemente rápido, pero es posible que vea la pantalla de carga durante muy poco tiempo.
Si también ha habilitado el control remoto dentro de esa sesión, tendrá que volver a habilitarlo una vez que se establezca la conexión. Esto se debe a que, al volver a conectarse, la sesión se abre en estado de transmisión en vivo.
Después de un tiempo, se abandona la sesión. Sin embargo, si cierra la ventana, puede reiniciar manualmente la sesión desde Orchestrator.
Solo un usuario puede acceder a la transmisión en vivo y tomar el control remoto a la vez. Si un usuario ya está conectado, debe esperar a que se desconecte.
Por ejemplo, si el usuario 2 intenta abrir una transmisión en vivo que ya está abierta por el usuario 1, se le devuelve un error que indica que la transmisión en vivo no se puede iniciar. Una vez que el usuario 1 cierre la transmisión en vivo, el usuario 2 podrá abrirla en breve.
- La ventana de transmisión en vivo muestra Conectando..., pero no se establece la conexión.
- TightsVNC no está instalado
- TightsVNC no tiene la versión correcta
- TightsVNC está instalado como aplicación portátil
- TightsVNC ya está iniciado en la máquina
- Otro usuario de la misma máquina de alta densidad ya tiene una sesión abierta
- La sesión de transmisión en vivo se conecta después de un retraso
- La imagen de transmisión en vivo se está retrasando
- Ve una pantalla en blanco
- La interfaz de usuario de automatización no se inicia
- Está utilizando robots de Linux
- Está utilizando una máquina física sin ningún monitor conectado
- Te has desconectado del RDP
- Una sesión en ejecución se ha desconectado
- Recibe un mensaje de error que indica que otro usuario ya está conectado