- Démarrage
- Meilleures pratiques
- Locataire
- À propos du contexte du locataire
- Recherche de ressources dans un locataire
- Gestion des Robots
- Connexion des Robots à Orchestrator
- Enregistrement des identifiants du Robot dans CyberArk
- Stockage des mots de passe d'Unattended Robot dans Azure Key Vault (lecture seule)
- Stockage des informations d'identification de l'Unattended Robot dans HashiCorp Vault (lecture seule)
- Stockage des informations d'identification du robot Unattended dans AWS Secrets Manager (lecture seule)
- Suppression des sessions Unattended déconnectées et qui ne répondent pas
- Authentification du Robot
- Authentification du Robot avec les informations d'identification du client
- Audit
- Paramètres
- Cloud Robots
- Contexte des dossiers
- Automatisations
- Processus (Processes)
- Tâches (Jobs)
- Apps
- Déclencheurs (Triggers)
- Journaux (Logs)
- Surveillance
- Files d'attente (Queues)
- Actifs
- Compartiments de stockage
- Test Suite - Orchestrator
- Service de catalogue de ressources
- Authentification
- Intégrations
- Résolution des problèmes
AperçuFlux en direct et contrôle à distance via RealVNC
Cela s'applique à la version de Robot 2023.12 ainsi qu'aux versions ultérieures.
- Robots Windows versions 2023.12 et ultérieures.
- Automation Cloud Robots - Serverless
- Automation Cloud Robots - VM
- Robots Linux
Activez SignalR. Pour plus de détails, consultez la section relative aux paramètres du locataire SignalR.
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.
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.
- 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.
- 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.
- Le robot commence alors ce qui suit :
- un autre programme qui se connecte au serveur VNC local sur le port dynamique
- 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).
- 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.
