Présentation de l'infrastructure RPA avec Uipath

Le petit billet de 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.

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

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 intéractions 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 intéragissent Studio avec Orchestrator. Nous allons nous attarder sur son architecture. A la différence de Studio et Robot, l’écosystème d’Orchestrator se scinde en deux, avec une partie client et une partir 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 :

Le premier stéréotype que nous allons aborder est que le RPA a un impact sur l’emploi. Le RPA peut avoir un impact sur l’emploi, mais il est important de noter que cet impact n’est pas négatif. En effet, le RPA peut permettre aux employés de se concentrer sur des tâches plus complexes et à plus forte valeur ajoutée. Ainsi, augmenter leur productivité et leur satisfaction au travail.

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 différentes modes de déploiement 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.

image pour accompagner un article

En résumé :

En résumé, découvrez comment déployer et gérer efficacement votre flotte d’assistants virtuels avec UiPath, grâce à ses composants clés : UiPath Studio, Robot, et Orchestrator. Apprenez les interactions entre ces outils et explorez les architectures possibles pour une infrastructure RPA réussie, allant du déploiement sur un seul nœud à des solutions de haute disponibilité et de récupération après sinistre.

Besoin d'accompagnement ?

Ne laissez pas les défis de l’automatisation de processus robotisés (RPA) ralentir votre avancement. Contactez-nous dès maintenant pour explorer vos besoins spécifiques et découvrez comment notre savoir-faire en RPA peut convertir vos exigences technologiques en solutions concrètes !

Contactez-nous !