PRESENTATION DE L’INFRASTRUCTURE RPA AVEC UIPATH.


Infrastructure RPA avec UiPath

Article publié par Lucas Courtois, Consultant RPA chez l’Oiseau Rare.


Découvrez comment déployer et gérer votre propre flotte d’assistants virtuels avec la solution UiPath dans une infrastructure de production.

Nous ferons tout d’abord un tour d’horizon des composants de la suite UiPath avant de vous présenter les différentes possibilités de déploiement d’une infrastructure RPA.



LES TROIS COMPOSANTS DE LA SUITE UIPATH


Tout d’abord, la suite UiPath s’articule avec trois principaux composants :


Composant n°1 : Uipath Studio

UiPath Studio est l’outil principal. Il permet la conception des automatisations, leurs tests et leurs exécutions de manière contrôlée. Il se décompose actuellement en 3 couches :

  1. Une première couche regroupant l’ensemble des outils de conception du RPA : l’interface du Studio, le gestionnaire de packages pour le téléchargement des packages d’activités, les librairies et les templates de travail.
  2. UiPath Assistant, accessible via le Centre de notifications sur la barre de tâche Windows. Il permet à l’utilisateur d’interagir avec des robots attended (expliqué plus bas) en local.
  3. L’add-on Robot.js (disponible dans le gestionnaire de tâches Windows) qui permet directement d’intégrer les robots attended dans les applications.

Composant n°2 : UiPath Robot

Le composant Robot, est l’agent chargé d’exécuter les processus depuis le Studio et de les charger dans Orchestrator.


Composant n°3 : UiPath Orchestrator

Orchestrator est la plateforme de pilotage de vos robots. Elle vous permet une gestion centralisée de vos assistants. Elle est accessible par application Web et mobile.

La plateforme permet :

  1. Le stockage et la gestion des assistants
  2. Le contrôle et la distribution des licences
  3. La mise à disposition des robots aux utilisateurs


LES INTERACTIONS ENTRE LE STUDIO ET L’ORCHESTRATOR


  1. Pour déployer un assistant virtuel sur Orchestrator, son projet doit être en amont créé et publié depuis le Studio. À la publication du projet, on créé un package. Le projet devient alors un nugget package, un dossier compressé avec l’extension .nupkg, dans lequel nous regroupons les scripts et les propriétés du projet (versioning, dépendances, description…)
  2. Une fois le nouveau package publié dans Orchestrator,nous l’associons à un dossier.
  3. Lorsque ce package est associé au dossier correspondant, il devient un processus. Ce processus est dès lors exécutable par tout robot ayant accès au dossier de votre processus. Plusieurs paramétrages sont alors applicables à ce processus (créneaux de lancement, niveau de remontée d’information des messages d’exécution…). Votre processus est dès lors visible depuis l’outil UiPath Assistant sur les machines qui ont été associées à son dossier.




À partir de là, il est possible de faire le distinguo entre les robots dits Attended et les robots Unattended.

Les robots Attended sont les robots lancés manuellement par des utilisateurs depuis l’outil UiPath Assistant. Ils permettent d’exécuter les processus directement sur les machines des utilisateurs.

Ainsi, on les distingue des robots Unattended, se déclenchant de manière automatique et sans intervention d’utilisateur. Les robots Unattended sont prévus pour fonctionner en continu et sont lançables uniquement depuis Orchestrator. Au lancement d’un robot Unattended, le .nupkg chargé auparavant dans Orchestrator est téléchargé en local sur la machine.  Le composant Robot se charge donc de son exécution.





L’ARCHITECTURE DE L’ORCHESTRATOR


Maintenant que vous savez un peu plus comment interagissent Studio et Robot avec Orchestrator. Nous allons nous attarder sur son architecture.


À la différence de Studio et Robot, l’écosystème d’Orchestrator se scinde en deux, avec une partie client et une partie serveur.

Les composants côté client :

La partie client comprend les composants localisés dans les machines locales : robots attended, robots unattended et le Studio.

Les composants côté Server :

La partie Server regroupe les composants gérant les opérations back-end de l’architecture. UiPath les décompose en trois couches.

1ère couche : Présentation Layer

Cette couche de présentation permet l’affichage visuel de l’application Orchestrator dans le navigateur Web. Elle permet ainsi à l’utilisateur d’interagir avec l’écosystème Orchestrator : connexion à l’application, gestion des robots, l’accès aux dossiers, l’affectation des packages aux dossiers, le démarrage et l’arrêt des robots.

2ème couche : Web Service Layer

Différentes fonctionnalités sont supportées dans cette couche d’Orchestrator grâce aux points d’accès API, à savoir :

  • La configuration
  • Les notifications, les logging
  • Le monitoring
  • La gestion des files d’attentes (queues)


LES OUTILS DES COUCHES DE L’ARCHITECTURE


Kibana :

Principal composant d’ElasticSearch utilisé pour de la datavisualisation. Il permet de regrouper les opérations de gestion et de rendre les données stockées lisibles pour les utilisateurs. Il offre donc la possibilité de filtrer de manière affinée les rapports d’exécution des robots.


Orchestrator HAA (The Orchestrator High Availability Add-On) :

Add-on permet d’offrir de la redondance et de la stabilité pour un déploiement Orchestrator à multi-nœuds. Lorsqu’un des nœuds échouent les autres prennent le relais.

3ème couche : Persistence Layer

La couche Persistence, collecte et stocke les données d’exécution : les logs, les messages avec un système de gestion de base de données et éventuellement un serveur. En ce qui concerne UiPath, on retrouve les outils suivants :

SQL Server (obligatoire) 

SGBD incontournable pour les déploiements d’infrastructure RPA avec UiPath. SQL Server vient stocker la plupart des données utilisées : les logs, les messages d’Orchestrator, Studio et Robot. Le serveur SQL Server conserve également la configuration des robots. Les groupes des robots et les autres informations accessibles depuis l’application Web d’Orchestrator.


LES DIFFERENTS MODES DE DEPLOIEMENT D’UNE INFRASTRUCTURE RPA AVEC UIPATH


ElasticSearch (optionnel)

Il s’agit d’un serveur permettant d’indexer les logs et les messages générés par les robots. Il comporte également une base de données, optionnelle pour les déploiements. Si elle est absente, SQL Server stocke par défaut tous les logs et les messages.

Pour déterminer le niveau de réussite d’un déploiement, UiPath définit les critères suivants comme facteurs clés de succès :

  1. L’efficience des coûts
  2. L’extensibilité
  3. La fiabilité
  4. La sécurité
  5. La conformité

C’est pourquoi UiPath propose cinq modes de déploiement. Ils sont chacun adapté aux critères de réussite présentés auparavant. Selon vos facteurs clés de succès, il vous faudra trancher selon les avantages et inconvénients que chacun d’entre eux impliquent.



1. Single-node deployment (efficience des coûts)


Il s‘agit du mode de déploiement le plus simple, approprié lorsque l’extensibilité et la disponibilité ne sont pas critiques. Dans cette configuration, plusieurs Robots et Studios se connectent à 1 Orchestrator. Ainsi, l’Orchestrator doit être connecté à SQL Server ou ElasticSearch Server.





2. Multi-Node deployment (extensibilité) :


Ce mode de déploiement reprend la logique du single-node Deployment avec cette fois-ci plusieurs Orchestrator. Il est adapté si le critère de l’extensibilité est recherché. Ainsi, si un des Orchestrator échoue les autres prennent le relais (cette option est appelée le muti-node installation).





3. High-availability (fiabilité)


Ce mode de déploiement reprend la même structure que le Multi-Node Deployment. Mais cette fois-ci plusieurs High Availability add-on pour les Orchestrator et un add-on Always On Availabilty Group pour SQL Server.

En outre, on prévoit un cluster de bases de données pour limiter le risque de perte de données. La première base de données est en mode lecture-écriture, tandis que les répliques « de secours » restent en mode lecture.





4. Disaster-recovery : Active/Passive (sécurité)


Pensé pour des scénarios de catastrophe. Il permet d’assurer un fonctionnement continu même en cas d’incident majeur.

Deux Datacenters sont prévus. Un premier datacenter actif et un deuxième en veille avec un nombre de machines restreint.

Au-delà du Robot et de l’Orchestrator, un appareil de stockage partagé est mobilisé pour réaliser la sauvegarde des packages. Ainsi, une base de données et un Availability Group Feature devront également être embarqués dans le datacenter d’urgence.





5. Disaster-recovery : Active/Active (conformité)


Enfin, dans cette dernière configuration, on retrouve cette fois-ci deux sites actifs. Ils répliquent de manière quasi constante et instantanée les données. L’essentiel prérequis de ce déploiement est la connectivité de réseau entre les datacenters. Dès que l’un des deux sites ne répond plus, l’autre prend instantanément le relais. Pour cette configuration, le deuxième site devra disposer d’un Add-on High Availability et la réplication de bases de données.