- Démarrage
- Meilleures pratiques
- Modélisation de l'organisation dans Orchestrator
- Gestion de grands déploiements
- Meilleures pratiques d'automatisation
- Optimisation de l'infrastructure Unattended à l'aide de modèles de machine
- Organisation des ressources avec des balises
- Réplica Orchestrator en lecture seule
- Exportation des grilles dans l'arrière-plan
- 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
- Authentification par carte à puce
- Audit
- Paramètres - Niveau du locataire
- Service de catalogue de ressources
- Robots Automation Suite
- Contexte des dossiers
- Automatisations
- Processus (Processes)
- À propos des processus
- Gestion des processus
- Gestion des exigences de package
- Enregistrement
- Résolution des problèmes de diffusion en direct et de contrôle à distance
- Tâches (Jobs)
- Déclencheurs (Triggers)
- Journaux (Logs)
- Surveillance
- Files d'attente (Queues)
- Actifs
- Compartiments de stockage
- Test Suite - Orchestrator
- Intégrations
- Robots classiques
- Résolution des problèmes
Résolution des problèmes de diffusion en direct et de contrôle à distance
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.
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 Suite Robots.
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 les Automation Suite Robots.
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é