- 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
- Accéder à la configuration de l'Unattended Robot
- Concepts utiles de l'automatisation Unattended
- Comment s'effectue l'automatisation Unattended
- 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
- Configurer les capacités d’automatisation
- Audit
- Paramètres - Niveau du locataire
- Service de catalogue de ressources
- Contexte des dossiers
- Automatisations
- Processus (Processes)
- Tâches (Jobs)
- Déclencheurs (Triggers)
- Journaux (Logs)
- Surveillance
- Files d'attente (Queues)
- Actifs
- Compartiments de stockage
- Test Suite - Orchestrator
- Autres configurations
- Intégrations
- Administration de l'hôte
- À propos du niveau de l’hôte
- Gestion des administrateurs système
- Gestion des locataires
- Configuration des notifications par e-mail du système
- Journaux d'audit pour le portail hôte
- Mode de Maintenance
- Administration de l'organisation
- Résolution des problèmes
Guide de l'utilisateur d'Orchestrator
Concepts utiles de l'automatisation Unattended
Les automatisations Unattended reposent sur divers composants qu'il est utile de comprendre. Les rubriques ci-dessous définissent brièvement ces composants, mais d'autres détails sont disponibles à chaque étape où les concepts sont utilisés.
Les comptes robot sont utiles lorsque vous devez exécuter des processus back-office unattended qui ne devraient pas dépendre de la responsabilité d'un utilisateur en particulier. Il s'agit de notre équivalent RPA spécifique aux comptes de service. Ils sont similaires aux comptes que les services Windows exécutent comme identités d'application dans le modèle OAuth. Ils constituent une identité non-utilisateur à utiliser pour exécuter des processus unattended. Ils sont donc idéaux pour les opérations hautement privilégiées qui nécessitent des informations d'identification.
Découvrez comment ajouter un compte Robot.
Lorsque vous attribuez un compte Robot à un dossier parent dans une hiérarchie de dossiers, le compte Robot a automatiquement accès (avec les rôles attribués au niveau du dossier parent) à tous les sous-dossiers créés dans le dossier spécifique. De nouvelles autorisations peuvent être ajoutées dans le sous-dossier en plus de celles attribuées au niveau du dossier parent, mais les rôles hérités ne peuvent pas être supprimés. Il est possible qu'un compte Robot ait un niveau d'accès supérieur au sous-dossier qu'au niveau du dossier parent, mais la réciproque n'est pas vraie.
Il est possible d'accorder à un compte Robot l'accès uniquement à un sous-dossier en l'attribuant directement au niveau du sous-dossier. De cette façon, le compte Robot n'aura aucune visibilité au niveau parent, mais pourra accéder à toutes les ressources du sous-dossier et dessous, selon la définition de rôle attribuée. L'attribution d'un compte Robot au niveau du sous-dossier ne lui donne pas accès aux dossiers frères, à savoir aux autres dossiers du même niveau, à moins qu'il ne soit explicitement attribué aux autres dossiers de même niveau également, ou s'il est attribué au niveau parent (qui lui accorderait l'accès à tous les dossiers situés en dessous, comme mentionné précédemment).
Si des ressources d'autres dossiers sont nécessaires à l'exécution des processus dans le dossier actuel, vous devez vous assurer que tous les comptes Robot sous lesquels les processus spécifiques s'exécuteront sont également attribués en tant que comptes Robot des dossiers où se trouve le reste des ressources. disposant d'autorisations suffisantes pour pouvoir accéder/créer/modifier/supprimer les ressources de ces dossiers, tel que requis par les processus.
Vous pouvez gérer plusieurs comptes Robot en les ajoutant à un groupe. Les groupes sont d'un ensemble de comptes qui doivent avoir un accès, une configuration de robot et des besoins de licence similaires, et que vous souhaitez gérer ensemble. Il est donc recommandé de regrouper uniquement les comptes Robot qui partagent les mêmes paramètres et cas d'utilisation. Par exemple, si vous avez cinq comptes Robot qui gèrent les automatisations de premier plan sur des machines Windows et 10 comptes Robot qui gèrent les automatisations en arrière-plan sur des machines Linux, vous ajouterez chaque catégorie à son propre groupe, mais vous ne les combinerez jamais.
Les groupes peuvent être très utiles pour tirer parti de l'évolutivité dans le contexte du déploiement des robots et du contrôle des autorisations, éliminant ainsi la nécessité d'une configuration individuelle des comptes des robots.
Découvrez comment ajouter des groupes à On-Premises Orchestrator.
Découvrez comment ajouter des groupes à Cloud Orchestrator.
Le Robot est l’entité d’exécution de UiPath®. Il peut fonctionner en mode service ou en mode utilisateur, selon le type d’automatisation.
Le Robot en mode de service est le mieux adapté aux scénarios d'automatisation Unattended et aux déploiements de plates-formes à grande échelle. Lorsqu'un processus est exécuté, l'exécuteur Robot s'exécute avec les mêmes droits que l'utilisateur sous lequel il est enregistré.
Le service de Robot UiPath est le cerveau derrière toutes les opérations effectuées pendant l'exécution, et dans le cas d'une exécution Unattended, il est lancé sur le système local. Il peut ouvrir des sessions Windows interactives et dispose de tous les droits d'un administrateur de machine. En tant que tel, il permet la gestion automatique des sessions (comme la connexion et la déconnexion) dans le cadre des tâches Unattended.
L'installation du Robot à l'aide de UiPathStudio.msi déploie le Robot en mode de service par défaut. Vous pouvez également l'installer à partir de l'invite de commande.
L'automatisation Unattended fonctionne mieux avec les Robots en mode de service installés sur le système local. Les Unattended Robots peuvent également s'exécuter sur l'utilisateur local (Robots en mode utilisateur), mais ce n'est pas l'approche recommandée car le Robot ne peut pas s'exécuter à moins que cet utilisateur particulier ne soit connecté manuellement à cette machine.
Le Robot en mode de service est installé pour tous les utilisateurs sur une machine. Lorsque le Robot en mode de service est installé sur des machines Windows Server, vous pouvez exécuter des tâches simultanées Unattended avec la gestion automatique des sessions. Cela représente un scénario d'automatisation Unattended transparente. Vous pouvez avoir des tâches simultanées avec le Robot en mode utilisateur sur un serveur Windows, mais sans gestion automatique des sessions.
Le Robot en mode utilisateur est le mieux adapté aux scénarios d'automatisation assistés. Il s'exécute sous l'utilisateur qui l'a installé et a les droits exacts en tant qu'utilisateur particulier.
Choix de l'option d'installation rapide dans le programme d'installation .msi déploie le robot en mode utilisateur par défaut.
UiPath Assistant est l'interface de votre Robot, vous permettant d'interagir avec des projets créés dans Studio.
Dans les scénarios Unattended, cependant, l'Assistant est utilisé uniquement à des fins de débogage, lorsqu'un utilisateur se connecte à la machine Unattended pour rechercher et résoudre les problèmes potentiels.
Les modèles de machine sont le type de machine recommandé pour les automatisations Unattended. Les modèles de machine facilitent le déploiement de plusieurs machines hôtes en définissant la configuration une seule fois, puis en permettant à plusieurs robots de se connecter à Orchestrator. Ils vous permettent de connecter des Robots UiPath déployés sur plusieurs machines hôtes à Orchestrator, quels que soient les noms des machines hôtes ou les utilisateurs qui s'y connectent.
Les modèles de machines, comme leur nom l'indique, fonctionnent comme des modèles dont les paramètres s'appliquent à des groupes de machines hôtes avec la même configuration physique. Plusieurs machines hôtes peuvent facilement être connectées au même modèle via une clé ou un ensemble d'informations d'identification client. La clé ou les informations d'identification du robot sont utilisées par les robots pour se connecter sur les machines hôtes et accéder aux ressources Orchestrator.
Lorsque vous regroupez des machines hôtes sous le même modèle de machine, nous vous recommandons d'appliquer ces pratiques :
-
les machines hôtes ont été déployées sur la base d'un modèle partagé, ou au moins configurées comme si elles l'étaient.
-
les mêmes applications doivent être installées sur les machines, et surtout, les applications doivent être installées aux mêmes chemins d'accès sur chacune des machines, et elles doivent toutes partager la même version des applications.
-
les utilisateurs se connectant aux applications sur ces machines doivent tous avoir les mêmes droits d'accès aux applications qu'elles contiennent.
Il est important de garder à l'esprit que l'algorithme de démarrage des automatisations Unattended peut lancer une tâche sous n'importe quel utilisateur attribué à un dossier (sauf si un utilisateur spécifique est sélectionné manuellement), et bien sûr sur n'importe quelle machine hôte attribuée à la machine modèle. Il est donc important que tous les comptes pouvant être sélectionnés pour exécution aient un compte correspondant sur toutes les machines attribuées à ce dossier. Sinon, des erreurs se produiront très probablement. Afin d'éviter cela, il est important de vous assurer que les utilisateurs que vous souhaitez associer à un modèle de machine spécifique ont été créés sur toutes les machines du modèle, ou d'avoir des modèles distincts, chacun avec moins de machines et les utilisateurs associés, tels que que seules des combinaisons valides sont définies pour chaque dossier.
Vous avez les entités suivantes :
-
Dossier F1 contenant
-
des comptes de robot R1, R2, R3
-
un modèle de machine T1
-
-
Modèle de machine T1 connecté aux machines hôtes M1 et M2
Dans ce scénario, vous devez vous assurer que M1 et M2 ont des comptes définis avec les mêmes informations d'identification que les comptes Robot R1, R2 et R3. De cette façon, l'automatisation peut fonctionner avec n'importe quelle combinaison robot-machine.
AllUsers
, ContactCenter
et ContactCenter_ITIssues
, cet utilisateur partagera la même configuration que le reste des utilisateurs de ContactCenter_ITIssues
et devrait également partager la même machine Orchestrator template comme le reste des utilisateurs susmentionnés. Il est également conseillé de créer des modèles de machine, si possible, conformément à la structure Active Directory existante.
Pour effectuer des automatisations Unattended à l'aide d'Unattended Robots, vous avez besoin d'une licence de service dédiée. C'est ce qu'on appelle un runtime ; il est attribué à un objet machine utilisé pour exécuter des processus Unattended. Pour ce faire :
-
Au niveau du locataire, rendez-vous sur Machines.
-
Sélectionnez la machine souhaitée et cliquez sur Autres actions (More Actions).
-
Dans la section Détails du runtime (Runtime details), insérez un nombre ou utilisez la flèche vers le haut pour saisir un nombre de runtimes dans le champ Production (Unattended).
Le nombre de runtimes attribués à un objet machine représente la capacité d'exécution des automatisations sur chaque machine hôte qui est liée à cet objet machine. En ce qui concerne l'automatisation Unattended, l'objet de machine préféré est le modèle de machine.
Les runtimes sont alloués au niveau du locataire et, en tant que tels, constituent le pool de runtimes du locataire. Lorsqu'une machine hôte se connecte à UiPath Orchestrator, le nombre de runtimes attribués à son objet machine associé est extrait à partir du pool du locataire. Le runtime est utilisé lors de l'exécution d'un processus sur la machine. Lorsque la machine hôte se déconnecte, les runtimes retournent au pool du locataire.
Exemple 1
Vous disposez d'un modèle de machine auquel vous attribuez trois runtimes Unattended :
-
Si vous connectez une machine hôte à ce modèle de machine, vous pouvez exécuter trois automatisations sur la machine hôte.
-
Si vous connectez trois machines hôtes à ce modèle de machine, vous pouvez exécuter trois automatisations sur chacune des trois machines hôtes, soit un total de neuf automatisations.
Lorsque vous attribuez des runtimes à un modèle de machine, assurez-vous d'en attribuer suffisamment pour couvrir toutes les exécutions unattended/testing/nonproduction qui peuvent se produire simultanément dans tous les dossiers dans lesquels le modèle de machine est défini. Cela nécessite également d'avoir suffisamment de machines connectées pour couvrir toutes les exécutions simultanées.
Exemple 2
Vous avez :
-
10 tâches Unattended planifiées pour démarrer simultanément dans le dossier A
-
5 tâches Unattended planifiées pour s'exécuter simultanément dans le dossier B (chevauchement avec les 10 définies dans le dossier A)
-
un modèle de machine, TemplateAB, attribué à la fois au dossier A et au dossier B
Vous devrez ensuite attribuer 15 runtimes Unattended à TemplateAB et disposer de 15 machines identiques disponibles et connectées à la clé machine de TemplateAB afin de vous assurer que l'exécution est possible pour toutes les planifications définies.
La seule exception à la règle ci-dessus concerne les processus d'arrière-plan, pour lesquels vous avez besoin d'un nombre suffisant de runtimes attribués à votre modèle pour toutes vos exécutions de processus simultanées, mais pas d'autant de machines hôtes connectées au modèle, car vous pouvez exécuter pratiquement autant de processus d'arrière-plan que vous le souhaitez sur la même machine, mais avec un seul processus de premier plan (processus qui nécessite une IU) à la fois.
Exemple 3
Pour 10 processus d'arrière-plan simultanés et 1 processus de premier plan, une seule machine hôte connectée à un modèle suffit, mais ce modèle spécifique doit avoir 11 runtimes attribués. Si, toutefois, un deuxième processus de premier plan est ajouté et qu'il doit s'exécuter en même temps que le premier processus de premier plan défini, ou si le premier processus de premier plan doit être exécuté deux fois simultanément, une deuxième machine est connectée au modèle de machine seront nécessaires à l'exécution des deux instances du processus de premier plan.
La section Niveaux de robot (Robot Tiers) de UiPath Licensing Portal affiche la liste complète des runtimes disponibles.
Les processus sont basés sur les packages d'automatisation Studio. Il s'agit d'une ressource par dossier et ne peuvent s'exécuter que dans les dossiers dans lesquels ils sont déployés. Ils peuvent cependant être démarrés par des processus situés dans d'autres dossiers, à condition que les utilisateurs de ces dossiers spécifiques disposent des autorisations nécessaires dans le dossier où le processus souhaité est déployé.
Vous pouvez travailler avec deux types de processus :
-
Les processus d'arrière-plan ne nécessitent pas d'interactions de l'interface utilisateur ou d'intervention humaine.
-
Les processus de premier plan doivent être démarrés et/ou gérés à partir de l'interface utilisateur et ne peuvent être exécutés qu'un seul à la fois.
Remarques :
-
Chaque exécution d'un tel processus utilise un runtime Unattended/NonProduction.
-
Vous pouvez exécuter plusieurs processus d'arrière-plan et un processus de premier plan simultanément.
Lors de la création d'un projet dans Studio, les développeurs doivent configurer un attribut de compatibilité qui impacte le framework cible sous-jacent du projet d'automatisation et le système d'exploitation compatible. Ceci est défini dans Studio, dans le champ Compatibilité (Compatibility).
Le tableau suivant indique la version UiPath Robot requise pour exécuter les processus en fonction de leurs frameworks cibles et des considérations de compatibilité du système d'exploitation :
Infrastructure cible |
Système d'exploitation |
minimale 2021.8 |
.NET Framework 4.6.1 |
Windows - Héritage |
Tout |
.NET 5.0+ |
Windows |
2021.10+ |
.NET 5.0+ |
Multiplateforme |
2021.10+ |