Flux en direct et contrôle à distance via RealVNC

Important :

Cela s'applique à la version de Robot 2023.12 ainsi qu'aux versions ultérieures.

Les fonctionnalités de flux en direct et de contrôle à distance sont disponibles pour :

• Robots Windows versions 2023.12 et ultérieures.
• Automation Cloud Robots - Serverless
• Automation Cloud Robots - VM
• Robots Linux

Remarque : cette fonctionnalité ne peut pas être utilisée avec les tâches en arrière-plan Windows.

Prérequis pour les Robots Windows 2023.12 et versions plus récentes.

Activez SignalR. Pour plus de détails, consultez la section relative aux paramètres du locataire SignalR.

Configuration requise pour le réseau

La configuration réseau minimale requise pour qu'une session de diffusion en direct et de contrôle à distance fonctionne sans accroc peut varier considérablement en raison d'un certain nombre de facteurs :

• La résolution d'écran du robot

• Les changements entraînés par votre automatisation - plus les changements d'images et de texte sont dynamiques, plus le volume de trafic est élevé

• La latence entre votre machine et la région Automation Cloud

• La latence entre votre robot et la région Automation Cloud

Compte tenu de ce qui précède, nous recommandons une bande passante réseau de 3 Mo/s pour une résolution d'écran de 1920 x 1080.

Considérations de sécurité

La connexion de diffusion en direct entre le client et la machine cible est acheminée via TLS via le proxy VNC, ce qui signifie que le serveur est sécurisé. De plus, chaque fois qu'une session de diffusion en direct est démarrée, un jeton JWT unique est généré et utilisé pour authentifier la requête. La seule instance de trafic non sécurisé se trouve sur la machine robot pour la connexion localhost.

Côté Robot, un mot de passe unique est généré pour chaque tâche et défini pour le serveur VNC. Le serveur ne s'exécute que pendant la session de diffusion en direct. Lorsque l'utilisateur se déconnecte de la session, le serveur VNC se ferme également.

Flux de réseau

1. Lorsque vous effectuez une demande depuis l’interface d’Orchestrator pour démarrer le flux en direct, Orchestrator envoie une commande au robot pour lancer une nouvelle session de contrôle à distance.
2. Le robot démarre un serveur VNC qui écoute sur le port dynamique. Le serveur VNC démarre en bouclage uniquement, ce qui désactive les connexions à distance. La commande Orchestrator inclut également un mot de passe pour l’authentification VNC, qui est partagé entre le serveur VNC et le client du navigateur.
3. Le robot commence alors ce qui suit :
   1. un autre programme qui se connecte au serveur VNC local sur le port dynamique
   2. un proxy de flux en direct UiPath

   Le programme transmet tout le trafic TCP au proxy de flux en direct en le convertissant en protocole WebSocket Secure (wss).

4. Le client Orchestrator VNC se connecte au même proxy de flux en direct dont le travail consiste à associer les deux WebSockets : l’un à partir du client VNC dans le navigateur et l’autre à partir du robot. Il crée ensuite un tunnel entre les deux WebSockets et transmet le trafic d’un WebSockets à l’autre.

   Le client VNC utilise deux ports : 443 et 5 900.

   Le port 443 doit être ouvert pour se connecter à un service auxiliaire en ligne.

   Le port 5 900 fonctionne localement sur la même machine pour acheminer le trafic entre deux applications.

   Pour que la communication fonctionne, ces ports doivent être ouverts dans les deux sens afin de permettre le trafic entrant et sortant.

   Figure 1. Diagramme de flux réseau