- 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 de l’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
- Configurer les capacités d’automatisation
- Solutions
- Audit
- Paramètres
- Cloud Robots
- Exécution d'automatisations Unattended à l'aide de Cloud Robots - VM
- Téléchargement de votre propre image
- Réutilisation des images de machines personnalisées (pour les pools manuels)
- Réinitialisation des informations d'identification d'une machine (pour les pools manuels)
- Surveillance
- Mises à jour de sécurité
- Demander un essai
- Questions fréquemment posées
- Configuration du VPN pour les robots du cloud
- Diffusion en direct et contrôle à distance
- 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
- Intégrations
- Résolution des problèmes
Scénarios d'erreur
Voici quelques-uns des problèmes que vous pouvez parfois rencontrer lors du flux en direct et/ou lors de la prise de contrôle à distance d’une exécution en cours, ainsi que les solutions que nous proposons.
La fenêtre de diffusion en direct affiche Connexion en cours..., mais aucune connexion n'est établie
Dans tous les scénarios ci-dessous, le Robot ne se connectera pas au système de flux en direct et de contrôle à distance, et la session ne démarrera pas. L'opération est réessayée pendant la durée maximale, qui est d'environ une minute, puis une erreur s'affiche. Les détails de l'échec sont disponibles dans les journaux du Robot sur la machine où la connexion échoue (pas dans les journaux des tâches).
Si TightVNC n'est pas installé, la session ne peut pas être démarrée. Veillez à le télécharger et l'installer au préalable. Important : l'option Enregistrer le serveur TightVNC en tant que service système (Register TightVNC Server as a system service) (sous Configuration du service TightVNC (TightVNC Service configuration)) ne doit pas être sélectionnée. Si c'est le cas, toute demande de démarrage de session est ignorée.
La version que nous prenons actuellement en charge est 2.8.75.
Lorsque TightVNC est installé sous forme portable, le Robot n'est pas en mesure de le détecter.
UIPATH_TIGHTVNC_EXE_PATH
avec le chemin complet qui inclut tvnserver.exe
.
Lorsqu'une session de flux en direct et de contrôle à distance est terminée, TightVNC se ferme automatiquement. Si vous essayez de lancer une session et que le Robot détecte que TightVNC est en cours d'exécution, votre demande est ignorée.
Vous devez fermer votre instance de TightVNC actuellement ouverte.
Les machines exécutant des Robots haute densité ne prennent en charge qu'une seule session de flux en direct et de contrôle à distance à la fois. Si vous essayez d'ouvrir une session alors qu'une autre est déjà en cours d'exécution, votre demande est ignorée.
Dans ce cas, vous ne pourrez accéder au flux en direct qu'une fois le processus en cours terminé.
Si vous commencez une session de flux en direct et de contrôle à distance immédiatement après le passage d'une tâche à l'état En cours d'exécution (Running), il est possible que le Robot ne soit pas encore prêt à la commencer.
Après un certain temps, le Robot peut gérer la demande et démarrer le flux en direct.
Cela peut être dû à une connexion réseau lente entre votre machine et celle du Robot, ou lorsque la résolution de l'écran de la machine robot est élevée.
Voici quelques-unes des raisons pour lesquelles il est possible que vous ne voyiez aucune image sur votre écran lorsque vous démarrez le flux en direct.
Certaines tâches effectuent certaines actions avant d'inviter l'interface utilisateur de l'automatisation à s'ouvrir. Si cela se produit, la session de flux en direct qui s'ouvre est vide. Cela se traduit par l'affichage du bureau pour les Robots Windows et l'affichage d'un écran noir pour les Unattended Robots Linux et les Automation Cloud Robots - Serverless.
Essayez d'ouvrir à nouveau la session.
Les Robots Linux Unattended ne prennent pas correctement en charge les flux en direct et le contrôle à distance. Nous vous déconseillons donc de les utiliser pour de telles opérations.
Essayez plutôt d'utiliser Automation Cloud Robots - Serverless.
Les flux en direct des processus exécutés sur une machine physique sont rendus sur un moniteur physique.
De ce fait, vous devez vous assurer qu'un moniteur est connecté.
Si vous vous êtes déconnecté du protocole RDP (Remote Desktop Protocol), il est possible que les machines virtuelles cessent d’afficher l’écran. Cela se produit car, une fois déconnecté, il n’y a plus d’écran virtuel sur lequel afficher les images.
Pour résoudre ce problème, utilisez le Robot en mode service.
Des problèmes de communication réseau peuvent entraîner l’arrêt d'une session de flux en direct. Si cela se produit, le client tente automatiquement de se connecter à nouveau. Si cela devrait être raisonnablement rapide, il est possible que l'écran de chargement s'affiche pendant très peu de temps.
Si vous aviez également activé le contrôle à distance au cours de cette session, notez que vous devrez le réactiver une fois la connexion rétablie. En effet, lors de la reconnexion, la session est ouverte dans son état de flux en direct.
Après un certain temps, la session est abandonnée. Cependant, si vous fermez la fenêtre, vous pouvez redémarrer manuellement la session à partir d'Orchestrator.
Un seul utilisateur peut accéder au flux en direct et prendre le contrôle à distance en même temps. Si un utilisateur est déjà connecté, vous devez attendre qu'il se déconnecte.
Par exemple, si l'utilisateur 2 essaie d'ouvrir un flux en direct déjà ouvert par l'utilisateur 1, une erreur lui est renvoyée indiquant que le flux en direct ne peut pas commencer. Une fois que l'utilisateur 1 aura fermé le flux en direct, l'utilisateur 2 pourra l'ouvrir sous peu.
- La fenêtre de diffusion en direct affiche Connexion en cours..., mais aucune connexion n'est établie
- TightVNC n'est pas installé
- TightVNC n'a pas la bonne version
- TightVNC est installé en tant qu'application portable
- TightVNC est déjà lancé sur la machine
- Un autre utilisateur sur la même machine haute densité a déjà une session ouverte
- La session de flux en direct se connecte après un délai
- L'image diffusée en direct est décalée
- Un écran vide s'affiche.
- L'interface utilisateur de l'automatisation n'a pas démarré
- Vous utilisez des robots Linux
- Vous utilisez une machine physique sans moniteur connecté
- Vous vous êtes déconnecté du RDP
- Une session en cours d'exécution est déconnectée
- Vous obtenez un message d'erreur indiquant qu'un autre utilisateur est déjà connecté