- Démarrage
- Meilleures pratiques
- Modélisation de l'organisation dans Orchestrator
- 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
- Appliquer la gouvernance de la connexion Integration Service au niveau de l'utilisateur
- 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
- 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
- Configurer une connexion ExpressRoute
- 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
- À propos des actifs
- Gestion des actifs dans Orchestrator
- Gestion des actifs dans Studio
- Stockage des ressources dans Azure Key Vault (lecture seule)
- Stockage des ressources dans HashiCorp Vault (lecture seule)
- Stockage des ressources dans AWS Secrets Manager (lecture seule)
- Stocker des ressources dans Google Secret Manager (lecture seule)
- Règles métier
- Compartiments de stockage
- Serveurs MCP
- Index
- Tests d'Orchestrator
- Service de catalogue de ressources
- Intégrations
- Résolution des problèmes

Guide de l'utilisateur d'Orchestrator
Le tableau suivant fournit des informations détaillées sur les régimes de licence qui vous permettent d'utiliser des robots cloud :
|
Fonctionnalités |
Communauté |
Essai de base |
Basique |
Essai standard |
Standard |
Enterprise | Essai standard de test d'application | Norme de test d'application | Entreprise de test d'application |
|---|---|---|---|---|---|---|---|---|---|
|
Robots Automation Cloud™ - Machines virtuelles |
|
|
|
|
|
|
|
|
|
|
Robots Automation Cloud™ - Sans serveur |
|
|
|
|
|
|
|
|
|
|
Elastic Robot Orchestration |
|
|
|
|
|
|
|
|
|
Lorsque vous définissez le modèle de machine automatique, vérifiez que vos machines disposent de suffisamment de Platform Units.
Si vous ne disposez pas d'assez de Platform Units, les restrictions de consommation suivantes s'appliquent :
-
Si vos Platform Units ne correspondent pas au nombre maximal de machines virtuelles défini dans le pool, nous supprimons toutes les machines du pool et cessons d'en créer de nouvelles jusqu'à ce que vous ayez affecté suffisamment de Platform Units pour prendre en charge le nombre maximal de machines.
Remarque : au lieu d'ajouter davantage de Platform Units, nous vous recommandons de réduire le nombre maximal de machines virtuelles du pool. - Si une tâche s'exécute sur une machine qui ne dispose pas de Platform Units suffisantes, l'alerte suivante s'affiche : « No VMs in <Pool_name> due to insufficient platform units » (Aucune machine virtuelle disponible dans {} en raison d'un nombre insuffisant de Platform Units).
- Dès que le nombre de Platform Units disponibles est suffisant, elles sont automatiquement consommées.
- Si plusieurs pools sont en état de surconsommation, nous affectons toutes les Platform Units disponibles aux derniers sous-ensembles de pools créés.
Exemple : vous avez cinq pools, chacun comportant au maximum trois machines, soit 15 machines au total. Votre plateforme peut prendre en charge deux machines, ce qui signifie que les cinq pools sont désormais en état de surconsommation et que vous ne pouvez pas les utiliser.
- Vous ajoutez la plateforme requise pour prendre en charge cinq machines supplémentaires. Vous pouvez désormais utiliser au total sept machines.
- Deux pools deviennent disponibles et consomment des Platform Units de six machines (deux pools de trois machines chacun).
- Trois pools restent en état de surconsommation et les Platform Units disponibles desservent une machine. Par conséquent, les deux pools sont créés en dernier.
Publication et réutilisation des Robot Units
Une fois que les pools automatiques sont créés, les Platform Units affectées sont consommées en fonction de leur distribution mensuelle. Le renouvellement automatique s'applique si des Platform Units sont disponibles.
Lorsqu'une machine virtuelle est supprimée d'un pool manuel ou lorsqu'un pool automatique est supprimé, les Platform Units correspondantes sont libérées dans les 24 heures suivantes.
-
Pendant le reste du mois de contrat en cours, vous pouvez réutiliser les Platform Units libérées dans le même locataire.
-
Pour les mois suivants, les Platform Units restantes peuvent être utilisées entre les différents locataires.
Par exemple, vous avez acquis un ensemble de 10 000 Platform Units dans le cadre d'un contrat d'un an qui commence le 1er janvier et se termine le 31 décembre. Les événements se dérouleront selon la chronologie suivante :
-
1er janvier : vous créez VM1 dans le locataire T1, qui consomme le montant négocié, disons 1 200 Platform Units.
-
15 janvier : vous supprimez la VM1 du locataire T1.
-
16 janvier : les 1 200 Platform Units sont libérées et vous pouvez les réutiliser pour créer VM2 dans le même locataire T1.
-
1er février : vous continuez d'exécuter la même VM2 dans le locataire T1, ce qui consomme 1 200 Platform Units supplémentaires de votre ensemble, selon la distribution mensuelle.Il vous reste 7 600 Platform Units (10 000 Platform Units moins 1 200 pour janvier et 1 200 pour février).
-
15 février : vous conservez la même VM2 dans le locataire T1, mais vous créez deux machines virtuelles supplémentaires dans deux locataires différents, T2 et T3. Cela consomme 2 400 Platform Units sur les 7 600 unités restantes : une pour la VM du locataire T2 et une pour la VM du locataire T3. Il vous reste désormais 5 200 Platform Units.