Architecture Automation 360 et résilience
- Dernière mise à jour2023/03/01
Architecture Automation 360 et résilience
Automation 360 est une plateforme unique et intégrée qui transcende les silos technologiques du front-office et du back-office pour automatiser les processus métier dans tous les systèmes et applications, y compris les applications SaaS et héritées.
La plateforme Automation 360 est déployée à l'aide d'une architecture distribuée.
La gestion centralisée se fait via un serveur Web, appelé Control Room, pour gérer tout le développement et l'exécution de la force de travail numérique. Le Agent de robot exécute l'automatisation et des systèmes d'exécution sont installés sur les périphériques.
L'image suivante montre l'architecture et la relation entre Control Room et Agent de robot:
- *indique que le Control Room crée un nom d'utilisateur unique et un identifiant de périphérique pour persister dans la clé publique de la base de données.
- **indique que la clé publique du périphérique est validée par la Control Room et un nouveau jeton est créé.
Le tableau suivant décrit le flux et les actions qui se déroulent entre les Control Room, Agent de robot et les services back-end (tels que numérotés dans l'image précédente) :
| Actions | Description |
|---|---|
| 1 | Le navigateur envoie le jeton de périphérique au Agent de robot pour l'enregistrement. |
| 2 | Le Agent de robot enregistre ensuite la demande du périphérique pour créer une clé publique et un jeton. |
| 3 | Les services back-end du Control Room envoient une réponse au Agent de robot indiquant que l'appareil a été enregistré avec un nom d'utilisateur et un identifiant de périphérique uniques. |
| 4 | Le Agent de robot envoie un message au navigateur indiquant que le périphérique a été enregistré avec succès. |
| 5 | Le Agent de robot envoie un message aux services back-end de l'Control Room pour indiquer que le jeton Web JSON a été authentifié avec succès. |
| 6 | Les services back-end de l'Control Room valident ensuite la clé publique du périphérique et établissent une connexion Web Socket avec le nouveau jeton. |
Control Room et résilience Agent de robot
Le tableau suivant vous fournit les différences de comportement et de résilience entre Automation 360 et Enterprise 11.
| Action utilisateur | Agent de robot dans Automation 360 | Client Bot Runner dans Enterprise 11 | Remarques |
|---|---|---|---|
| Services | Les services d'installation sont exécutés sur le périphérique local. | Les services d'installation sont exécutés dans une session utilisateur active. | |
| Inscription | Le périphérique est enregistré auprès du Control Room. | Un utilisateur actif est inscrit au Control Room. | Le service Agent de robot s'exécute sur le système local. |
| Authentification | Control Room stocke la clé publique de l'agent dans la base de données. | Control Room enregistre la clé d'authentification dans la mémoire. | Dans Automation 360, le Control Room enregistre la clé publique dans la base de données. Ainsi, lorsque le Control Room redémarre, la reconnexion est acceptée plus rapidement. Le Agent de robot est résilient dans les redémarrages Control Room. Cependant, dans Enterprise 11, la reconnexion Control Room ne se produit pas après un redémarrage. |
| Déploiement du Robot | La priorité des robots est vérifiée lors du déploiement. Lorsque les robots sont mis en file d'attente pour un utilisateur du Bot Runner, les robots de priorité supérieure sont déployés avant les robots de priorité inférieure. Toutefois, si un robot de priorité inférieure est déjà en cours d'exécution, les robots de priorité supérieure ne sont déployés qu'une fois que l'exécution du robot de priorité inférieure est terminée. |
lorsqu'un robot de faible priorité est en cours d'exécution et qu'un robot de priorité élevée est déployé, le système met en pause le robot de faible priorité et exécute le robot de priorité élevée. Après que le robot de priorité élevée a été exécuté, le robot de faible priorité reprend. |
L'avantage de Automation 360 est que les robots de priorité inférieure ne sont pas mis en pause et terminent leur déploiement avant que les robots de priorité élevée ne soient déployés. |
| Traitement des erreurs | Le package Gestionnaire d\'erreur contient des actions qui vous permettent de gérer facilement les exceptions rencontrées par un robot et transfère le contrôle aux autres actions au sein de ce robot. | La commande Traitement des erreurs aide à déboguer lorsque les Robot de tâches et MetaBotLogique sont exécutées. | |
| Périphériques | Connecté lorsque le périphérique est enregistré auprès de la Control Room. Se reconnecte lorsque le périphérique redémarre. |
Lorsque le Client Bot Runner redémarre ou perd la connectivité avec l'Control Room, vous devez vous reconnecter au Client pour rétablir la connexion. | Agent de robot se reconnecte sans avoir à se connecter individuellement à chaque périphérique. |
| Reconnexion | Agent de robot se reconnecte automatiquement en cas d'interruption. | Le client Bot Runner doit être reconnecté manuellement. | L'enregistrement Robot dans Automation 360 est plus robuste et peut se reconnecter automatiquement à la base de données de l'Control Room. |
| Clé publique et privée | La clé publique et privée est générée au moment de l'enregistrement du périphérique. Cette clé est utilisée pour s'authentifier auprès du Control Room. |
Même comportement que dans Automation 360. | |
| Services | Agent de robot est exécuté en tant que service. Au redémarrage du périphérique, les services sont automatiquement connectés à l'interface du Control Room. Agent de robot continue à vérifier la connexion, même si le Control Room est arrêté, en utilisant la clé publique et privée. |
Demande à un client de se connecter et d'effectuer des tâches. | |
| Connexion à distance | Le protocole RDP (Remote Desktop Protocol) n'est pris en charge que sur les périphériques multi-utilisateurs. Le Control Room ne gère pas le RDP. |
Le RDP est pris en charge sur les périphériques mono- et multi-utilisateurs. Dans Enterprise 11, la connexion au RDP est établie à partir du Control Room et maintenue par le Control Room. |
|
| Mises à jour automatiques | Un administrateur de la Control Room peut choisir de mettre à jour automatiquement l'Agent de robot vers une version ultérieure à l'aide de la fonctionnalité de mise à jour automatique. | L'option de mise à jour automatique n'est pas disponible. | Cette option réduit le temps d'arrêt car chaque utilisateur n'est pas obligé de se connecter à la Control Room pour mettre à jour l'Agent de robot installé sur le périphérique utilisateur. |
| Mises à jour de la configuration | Les mises à jour sont transmises par cloud | Il n'y a pas de mise à jour de la configuration autonome, mais vous pouvez la modifier manuellement. Les améliorations apportées aux configurations sont publiées sous forme de correctifs. |
|
| Cache global | Configurez les paramètres du périphérique pour définir automatiquement le périphérique actuel d'un utilisateur comme périphérique par défaut après que l'utilisateur se soit connecté à la Control Room. | Non disponible | |
| Perte de la connexion de Agent de robot à Control Room | Robots qui sont déjà en cours d'exécution s'exécutent jusqu'au bout pendant la mise à jour. | En général, robots déjà en cours d'exécution peuvent être exécutés sans interruption pendant la mise à jour. Les exceptions sont les suivantes :
|
Résilience de la planification
Les pools de périphériques offrent une haute disponibilité (HA) intégrée pour les périphériques Bot Runner si votre licence sans surveillance permet son utilisation. Vous n'êtes pas lié à un seul périphérique Bot Runner. Ainsi, si votre périphérique est indisponible pour une raison quelconque et que votre licence sans surveillance permet son déploiement, votre automatisation n'est pas affectée. L'automatisation planifiée s'exécutera automatiquement sur le prochain périphérique Bot Runner disponible, assurant ainsi une haute disponibilité.
Reportez-vous à la rubrique À propos des pools de périphériques.