Sesiones de Windows

El UiPath^® Robot ejecuta procesos en una sesión interactiva de Windows. El robot puede iniciar dos tipos de sesiones de Windows:

• Sesión de consola
• Sesión RDP

El tipo de sesión que inicie el robot vendrá determinado por la opción LoginToConsole. Por defecto, esta opción está habilitada.

Todos los tipos de robot, independientemente de la licencia o la implementación, pueden conectarse a ambos tipos de sesiones. Ten en cuenta que los robots de alta densidad solo se conectan a una sesión RDP.

Nota: los ajustes de robot configurados en Orchestrator anulan los ajustes que estén configurados en el UiPath.settingsarchivo .

Todas las sesiones de Windows, independientemente del tipo de sesión, se crean siempre en la máquina del robot. En otras palabras, las sesiones se crean desde la máquina de robot a la misma máquina, no desde Orchestrator a la máquina del robot.

Cuando se inicia un proceso desde Orchestrator, se crea una sesión de Windows de la siguiente manera:

1. Orchestrator envía un mensaje con los detalles de proceso al servicio de robot.
2. El servicio de robot crea una sesión de Windows interactiva en la máquina.
3. El servicio de robot inicia el ejecutor de robot en esa sesión.
4. El ejecutor de robot inicia la ejecución del proceso.

El proceso es el mismo tanto para sesiones de consola como RDP.

Si no estás conectado a Orchestrator, la opción Iniciar sesión en consola solo puede configurarse desde el archivo UiPath.settings.

Sesión de consola

Por defecto, el robot se conecta a una sesión de consola. Solo una sesión de consola puede estar activa por máquina. Si previamente se estableció otra configuración, el robot se puede conectar a una sesión de consola habilitando la opción LoginToConsole, mediante uno de los siguientes métodos:

• En el archivo UiPath.settings, establece el parámetro LoginToConsole como true.
• Al crear o actualizar un robot en Orchestrator, establece el valor LoginToConsole como Yes desde la pestaña de Configuración. Por defecto, la opción LoginToConsole está deshabilitada. Esto significa que se utiliza la configuración del archivo UiPath.settings. Para establecer el valor deseado desde Orchestrator, primero debes habilitar la opción LoginToConsole.
  Nota: se recomienda utilizar este tipo de conexión para los procesos que no requieren una resolución personalizada.

Solo puede haber una sesión de consola activa por máquina. Esto significa que solo un robot puede ejecutar procesos en esa máquina cada vez. Cuando finaliza la ejecución se desconecta la sesión, y otro robot puede iniciar una sesión y ejecutar procesos en esa máquina.

Si hay una sesión RDP activa cuando se inicia un trabajo desde Orchestrator, la sesión RDP activa finalizará.

Una sesión de consola usa la resolución especificada por los ajustes predeterminados de la tarjeta gráfica de la máquina. En sesiones de VDI, como Citrix, Hyper-V o VMware, la resolución la suele especificar el hipervisor que administra la VDI. Ten en cuenta que no puedes establecer una resolución personalizada.

Sesión RDP

En una sesión RDP, el robot crea una sesión de escritorio remoto virtual en la máquina en la que se ejecuta. Puedes hacer que el robot se conecte a una sesión RDP deshabilitando la opción LoginToConsole mediante uno de los siguientes métodos:

• En el archivo UiPath.settings, establece el parámetro LoginToConsole como false.
• Al crear o actualizar un robot en Orchestrator, establece el valor LoginToConsole como No desde la pestaña de Configuración. Por defecto, la opción LoginToConsole está deshabilitada. Esto significa que se utiliza la configuración del archivo UiPath.settings. Para establecer el valor deseado desde Orchestrator, primero debes habilitar la opción LoginToConsole.
  Nota: Los robots de alta densidad requieren conexión mediante una sesión RDP.

En una sesión Windows Workstation solo puede haber una sesión RDP activa. Esto significa que solo un robot puede ejecutar procesos en esa máquina cada vez. Cuando finaliza la ejecución se desconecta la sesión, y otro robot puede iniciar una sesión y ejecutar procesos en esa máquina.

En Windows Server, por el contrario, puede haber una sesión RDP activa para cada usuario de la máquina, o incluso múltiples sesiones para el mismo usuario. Esto significa que múltiples robots pueden ejecutar procesos simultáneamente en esa máquina, cada uno para su usuario designado. En esta situación, los robots también pueden ejecutar procesos para un usuario en múltiples sesiones, pero no deben fiarse de eventos de hardware (como actividades de UIAutomation).

Si se inicia un trabajo desde Orchestrator y ya hay una sesión RDP activa, el proceso se ejecuta en dicha sesión.

Te recomendamos que uses este tipo de conexión si tu proceso de automatización requiere una resolución personalizada. Para establecer una resolución personalizada, modifica los parámetros ResolutionWidth, ResolutionHeight y ResolutionDepth en una de las siguientes ubicaciones:

• Desde el archivo UiPath.settings.
• Desde la pestaña Configuración, cuando creas o actualizas un robot en Orchestrator.

Ejecución de procesos por RDP

El medio de comunicación principal entre un comando de ejecución y la ejecución real del proceso es el mantenimiento de robot de UiPath. Si no hace falta ejecutar ningún proceso, el mantenimiento de robot de UiPath permanece inactivo en la máquina Windows y no requiere ninguna sesión de Windows activa. Esto se hace así para garantizar una comunicación abierta constante con Orchestrator y poder iniciar inmediatamente un proceso si se recibe un comando. La comunicación se realiza mediante HTTPS, más concretamente mediante WebSockets (SignalR).

Nota: al ejecutar trabajos desatendidos en entornos que usan políticas que imponen la autenticación Kerberos para RDP, debes establecer la variable de UIPATH_DNS_MACHINENAMEentorno en la máquina, con el valor True. Esto alterna el uso del nombre de host DNS por localhost cuando se crean sesiones RDP.

Ten en cuenta que la sesión de Windows será generada por RDP solo si el valor de propiedad de LoginToConsole es false.

Nota: al usar robots en un entorno que aplica TCP, las sesiones de robot que usan conexiones RDP no se ven afectadas.

Cuando se envía un comando de iniciar proceso al servicio de UiPath Robot, se genera una sesión de Windows en esa máquina mediante RDP para el usuario del robot. Acto seguido, el servicio de robot lanza un ejecutor de robot dentro de la sesión recién creada. El ejecutor y el servicio se comunican a través de canalizaciones con nombre, y el ejecutor sabe exactamente qué ejecutar. Entonces, el proceso se ejecuta dentro de la sesión de Windows.

Nota: el Robot solo utiliza RDP para iniciar una Sesión Windows. No se utiliza para conectarse desde Orchestrator a la máquina donde se ejecuta el proceso, ni tampoco para comunicarse con otros componentes fuera de la máquina.

Información general sobre la arquitectura

Cuando se inicia un trabajo desde Orchestrator, el robot se conecta a la sesión de Windows WinSta0, según tu configuración de conexión de sesiones. Una sesión WinSta0 (sesión interactiva) solo puede tener un escritorio activo.

Un proceso siempre está asociado al escritorio interactivo donde se inició y no puede acceder otros escritorios durante su ejecución. Un escritorio activo garantiza lo siguiente:

• Los procesos pueden recibir datos del usuario mediante eventos de hardware
• Los procesos pueden recibir datos del usuario mediante eventos de software
• La visualización de la máquina se actualiza de manera continua

Una sesión de usuario desconectada no puede tener un escritorio. Si un escritorio no está activo en una sesión interactiva, sucede lo siguiente:

• Los procesos no pueden recibir datos del usuario mediante eventos de hardware
• Los procesos pueden recibir datos del usuario mediante eventos de software
• La visualización de la máquina se detiene

Solución de problemas de las sesiones de Windows

El servicio de robot captura una serie de capturas de pantalla de la sesión mientras configuras tu sesión de Windows y las elimina una vez que la sesión se crea correctamente. Si la configuración de la sesión falla, guarda las capturas de pantalla en el directorio %ProgramData%\UiPath\SessionScreenshots para futuras soluciones de problemas.