À propos du déploiement

Une instance d'Orchestrator unique peut exécuter simultanément 1 000 Robots Unattended ou jusqu'à 10 000 Robots Attended. Pour connaître le déploiement recommandé pour les 10 000 Robots, vérifiez les informations présentées ici.

Orchestrator prend également en charge le concept d'architecture mutualisée. Cette méthode est appelée « Schéma partagé », impliquant que plusieurs locataires peuvent partager la même base de données et le même schéma de base de données. Toutes les données associées au locataire sont clairement définies dans chaque table par son propre TenantId.

Décomposition logique (Logical Decomposition)

La plateforme du serveur UiPath contient les composants logiques suivants, regroupés en trois couches :

• Couche de présentation (Presentation Layer)

  • Application Web (Web Application)
  • Points de terminaison de l'API REST OData (OData REST API Endpoints)
  • API de notification (Notification API)

• Couche de service Web (Web Service Layer)

  • Implémentation de l'API REST (REST API implementation)

• Couche de persistance (Persistence Layer)

  • SQL Server

  • Elasticsearch

    
    

    

    
    

L'application Web est la couche visuelle de la plateforme du serveur. L'utilisateur interagit avec ses pages Web pour effectuer différentes opérations : création de groupes de Robots, affectation de paquets aux groupes, analyse de journaux par Robot ou par processus, démarrage et arrêt des Robots.

Outre les pages Web, Orchestrator contient également une couche de service qui affiche une API REST principalement composée de points de terminaison OData. L’API REST est utilisée par l’application Web et les agents. L’agent est le superviseur d’un ou de plusieurs Robots sur l’ordinateur client.

Fonctionnalités d'Orchestrator gérées par l'API REST :

• Configuration : les points de terminaison REST permettant de définir et de configurer les utilisateurs, les autorisations, les Robots, les actifs, les mises en production et les environnements de l'application.
• Surveillance et notification (Monitoring and Notification) : points de terminaison REST utilisés pour enregistrer les agents, fournir les paramètres de configuration aux agents et pour envoyer/recevoir les notifications depuis le serveur et l'agent. L'API de notification (Notification API) utilise également une communication WebSocket.
• Journalisation (Logging) : points de terminaison REST utilisés pour consigner différentes informations telles que les erreurs, les messages explicites envoyés par les Robots et autres informations spécifiques à l'environnement.
• Déploiement (Deployment) : points de terminaison REST utilisés par les Robots pour demander la version de paquet qui doit être exécutée si vous utilisez la commande Démarrer la tâche (Start Job) dans Orchestrator.
• Files d'attente (Queues) : points de terminaison REST chargés de la gestion des files d'attente et des éléments de file d'attente, à savoir l'ajout de données à la file d'attente, l'obtention d'une transaction dans la file d'attente, la configuration de l'état d'une transaction etc.

Composants de la couche de persistance (Persistence Layer) :

• SQL Server

  • enregistre la configuration des Robots, groupes de Robots et processus, utilisateurs, rôles, planifications associés. Ces informations sont gérées via le composant Application Web (Web Application).
  • gère les files d'attente et éléments de file d'attente.
  • en option, enregistre les messages consignés par les Robots (à la place ou en plus d'Elasticsearch).

• Serveur d'indexation (Elasticsearch) dont le rôle est d'enregistrer et d'indexer les informations consignées par les Robots. Vous pouvez le désactiver via les paramètres de configuration.

  Remarque : les messages consignés par les robots peuvent être stockés dans SQL Server, dans le serveur d'indexation, dans les deux ou dans aucun d'entre eux.

Le serveur d'indexation utilise le moteur de recherche en texte intégral d'Elasticsearch (projet en open source). Tous les messages consignés par les Robots (utilisant des activités telles que Message du journal des événements (Log Message) ou Écrire une ligne (Write Line) sont envoyés via le point de terminaison REST de consignation au serveur d'indexation où ils sont indexés pour une utilisation ultérieure.

Remarque : Pour une meilleure répartition des ressources, il est recommandé d'installer le serveur d'indexation sur une machine autre que celle sur laquelle SQL Server est installé.

Sur l'ordinateur client, un processus en cours est représenté dans le schéma ci-dessus sous la forme d'un exécuteur. Plusieurs projets métier peuvent être exécutés simultanément, avec un exécuteur correspondant. UiPath Agent (un service Windows) est le point de contact unique pour tous les exécuteurs, par lequel tous les messages sont consignés dans le service Orchestrator, qui les traite ultérieurement (base de données du serveur d'indexation ou de SQL Server ou les deux).

Un Robot représente une association entre un nom de machine et un nom d'utilisateur. Il peut gérer simultanément plusieurs exécuteurs. Sur des systèmes qui prennent en charge plusieurs sessions interactives exécutées simultanément (par ex., Windows Server 2012), plusieurs Robots peuvent s'exécuter simultanément, chacun dans une session Windows distincte à l'aide d'un nom d'utilisateur unique. On appelle cette fonctionnalité “Robots haute densité” (High-Density Robots).

UiPath Agent est également chargé de l'envoi de l'état du Robot (par ex., point de terminaison Soumettre une pulsation (SubmitHeartBeat)) et du téléchargement de la version requise à exécuter.

La communication entre l'agent et Orchestrator est toujours établie par l'agent. Dans le scénario de notification, l'agent ouvre un canal WebSocket qui est utilisé ultérieurement par Orchestrator pour envoyer des commandes au Robot (Démarrer (Start), Arrêter (Stop), etc.).

Recommandations d'équilibrage de charge

Nous avons testé les déploiements haute disponibilité et de récupération d'urgence d'Orchestrator avec plusieurs équilibreurs de charge réseau comme BIG-IP F5, Citrix NetScaler ADC, HAProxy. Étant donné que la configuration approfondie d'un équilibreur de charge réseau diffère considérablement d'un fournisseur à l'autre, nous avons les recommandations suivantes :

Recommandation
	Utilisez un algorithme d'équilibrage de charge tel que Round Robin ou un dérivé Round Robin prédictif ;
	N'utilisez pas de sessions persistantes, également appelées sessions permanentes ;
	Utilisez votre équilibreur de charge réseau préféré en mode Couche 7, car il peut interagir avec le point de terminaison de vérification de l’intégrité de l’API Orchestrator. Ce point de terminaison d’API est disponible sur https://your-orchestrator.com/api/status et renvoie 200 OK si l’application Web Orchestrator est opérationnelle, et renvoie 500 si l’application ne fonctionne pas. Voir Points de terminaison de vérification de l’intégrité dans le guide Orchestrator pour plus de détails. L'équilibreur de charge réseau doit interroger le point de terminaison de vérification de l'intégrité de l'API de chaque serveur Orchestrator toutes les 3 à 5 secondes.