Sessions Windows

Le Robot exécute les automatisations dans une session Windows, en démarrant une console ou une session RDP basée sur le paramètre LoginToConsole dans Orchestrator. Alors que tous les robots peuvent se connecter aux deux types de session, les robots haute densité utilisent uniquement des sessions RDP.

Mode de fonctionnement

Une session Windows est toujours créée sur la machine physique ou virtuelle sur laquelle le Robot est installé. Orchestrator ne crée pas directement de sessions Windows. Au lieu de cela, lorsqu'une tâche démarre dans Orchestrator, la séquence suivante a lieu :

1. Orchestrator envoie un message avec les détails du processus au service Robot sur la machine.

2. Le service de Robot crée une session Windows interactive sur la machine : WinSta0 .

3. Le service Robot démarre l'exécuteur Robot dans la session précédemment créée.

4. L'exécuteur Robot démarre alors l'exécution de l'automatisation dans cette session.

Le service de Robot connecte la commande pour exécuter une automatisation à l'exécution réelle.

Sans tâche en attente, le service de Robot entre dans un état inactif et ne nécessite pas de session Windows active. L'état inactif permet une communication constante avec Orchestrator, garantissant ainsi une exécution immédiate lorsqu'une commande est reçue. La communication se fait via WebSockets (SignalR).

Session de console

Il s’agit de l’environnement d’exécution par défaut.

Dans une session de console, le Robot exécute les tâches tandis qu'un utilisateur est connecté sur la machine hôte. Ce type de session est généralement recommandé pour :

• des automatisations assistées, car elles permettent d'interagir avec n'importe quelle application ouverte, en imitant les actions d'un utilisateur humain.

• des automatisations sans résolution d’écran personnalisée, car les sessions de console utilisent les paramètres graphiques de la machine hôte ou ceux spécifiés par l’hyperviseur VDI.

• l'exécution d'une automatisation à la fois, car une nouvelle exécution démarre une fois que la précédente est terminée et que le robot d'exécution se déconnecte de la session active.

Session RDP

Dans une session Remote Desktop Protocol (RDP), le Robot exécute des tâches lorsqu'un utilisateur se connecte à distance à une machine. Ce type de session est généralement recommandé pour :

• des automatisations non assistées, car elle permet d'exécuter des tâches qui ne nécessitent pas d'interaction de l'utilisateur, ou lorsque la machine est verrouillée ou que l'utilisateur est déconnecté.

• les automatisations qui nécessitent une résolution d'écran personnalisée, en définissant la largeur, la hauteur et la profondeur de la résolution dans l'onglet Paramètres du Robot (Robot Settings) d'Orchestrator.

• Les machines Windows, pour exécuter une automatisation à la fois, car une nouvelle exécution démarre une fois que la précédente est terminée et que le robot d'exécution se déconnecte de la session active.

• Machines Windows Server, pour exécuter plusieurs automatisations simultanément :

  • pour le même utilisateur sur différentes sessions RDP

  • pour plusieurs utilisateurs, chacun dans sa session RDP

L'option LoginToConsole dans Orchestrator

Lorsque vous définissez ou modifiez un compte de robot dans Orchestrator, vous pouvez sélectionner le type de session utilisé par vos robots pour exécuter des automatisations. Pour ce faire, utilisez l'option Connexion à la console ( Login To Console ).

Sur la page Locataire (Tenant) > Gérer l'accès ( Manage Access ) > Comptes Robot ( Robot accounts ) > Paramètres du Robot ( Robot Settings ) dans Orchestrator, l'option Connexion à la console ( Login to Console ) est désactivée par défaut. Cependant, le robot exécute les tâches dans une session de console par défaut.

Pour activer la session de console, activez l'option Connexion à la console ( Login To Console ) et sélectionnez Oui(Yes). Si une tâche démarre à partir d'Orchestrator pendant une session RDP active, la session RDP est automatiquement arrêtée.

Pour activer la session RDP, activez l'option Connexion à la console ( Login To Console ) et sélectionnez Non (No). Si une tâche démarre à partir d'Orchestrator et qu'une session RDP est déjà active, le robot exécute la tâche dans la session RDP active.

Exécution du processus sur RDP

L'image suivante résume l'exécution du processus sur RDP :

1. Le service de Robot reçoit la commande de lancer une exécution depuis Orchestrator, via le protocole HTTPS, appelé WebSockets (SignalR).

2. Le service de Robot crée ensuite une session Windows sur la machine à l'aide de RDP. Cette session RDP est créée pour l'utilisateur affecté au Robot.

3. Une fois la session RDP créée, le service Robot génère un exécuteur Robot dans cette session. Le service de Robot et l'exécuteur Robot communiquent entre eux via des canaux nommés. Cette méthode permet à l'exécuteur de savoir exactement quelles tâches doivent être exécutées.

4. Les tâches sont exécutées dans la session Windows générée.

Remarque :

• Le service du Robot utilise RDP exclusivement pour démarrer une session Windows sur la machine où le Robot est installé. Il n’utilise pas RDP pour connecter Orchestrator à la machine sur laquelle le processus est exécuté, ni pour communiquer avec d’autres composants à l’extérieur de la machine.

• Pour exécuter des automatisations Unattended dans des environnements où les sessions RDP nécessitent une authentification Kerberos, vous devez utiliser le nom d'hôte DNS pour la valeur localhost. Pour ce faire, ajoutez la variable d'environnement suivante à votre machine :

  UIPATH_DNS_MACHINENAME=True

• L'exécution d'automatisations dans des environnements qui appliquent le protocole TCP n'influence pas vos sessions RDP.

Dépannage des sessions Windows

Le service de Robot capture une série de captures d'écran de session lors de la configuration de votre session Windows et les supprime une fois la session créée avec succès. Si la configuration de la session échoue, elle enregistre les captures d'écran dans le répertoire %ProgramData%\UiPath\SessionScreenshots pour un dépannage futur.