Cycle de vie d'automatisation

Compréhension du processus

Le choix entre une automatisation des robots assistés ou non assistés est la première décision importante qui impacte la manière dont les développeurs créent le code, car l'infrastructure d'exécution générale (déclenchement du Robot, interaction, gestion des erreurs) est différente. Le basculement ultérieur vers l'autre type de Robot peut s'avérer fastidieux.

Pour des processus critiques et opérationnels déclenchés par l'humain, tels que dans un centre d'appels, la collaboration d'un Robot assisté avec un humain peut s'avérer la seule réponse possible.

Mais, les processus qui requièrent l'intervention humaine ne sont pas tous censés s'exécuter avec des Robots assistés. Si une décision purement subjective (non basée sur les règles) lors du processus ne peut pas être évitée, évaluez si un changement de flux est possible, tel que le fractionnement du plus grand processus en deux sous-processus plus petits, lorsque la sortie des deux premiers sous-processus devient l'entrée du second. Bien que l'intervention humaine ait lieu entre temps, telle que la validation/modification de la sortie du premier sous-processus, les deux sous-processus peuvent être déclenchés automatiquement et s'exécuter sans assistance.

Citons un cas typique : un processus requiert une étape manuelle en cours de processus, par exemple la vérification de la section des commentaires non structurés d'un ticket, et en fonction de cela, attribue le ticket à certaines catégories.

De façon générale, l'implémentation d'un Robot non assisté garantit une utilisation plus efficace de la charge du Robot et un ROI plus élevé, une gestion et un suivi améliorés des capacités robotiques.

Cependant, ces calculs doivent prendre en considération divers aspects, tels que le fait qu'un Robot assisté peut généralement s'exécuter uniquement durant les heures de travail normales d'une personne. Ou, il occupe la machine et l'utilisateur jusqu'à la fin de l'exécution. Les types d'entrée, les volumes de transactions, les limites de temps, le nombre de Robots disponibles et autres facteurs peuvent également jouer un rôle dans cette décision.

Documentation du processus - DSD

La documentation du processus guide le travail du développeur et propose une aide dans le suivi des requêtes et la gestion de l'application. Évidemment, beaucoup d'autres documents techniques peuvent être disponibles. Cependant, celui-là est essentiel à un bon déroulement, à savoir DSD (Development Specification Document).

Le document Development Specification Document doit contenir les détails du processus automatisé et cibler deux catégories principales : Guide d'exécution (Runtime Guide) et Détails du développement (Development Details).

Le Guide d'exécution (Runtime Guide) doit contenir un diagramme d'exécution de haut niveau, ainsi que des détails sur la fonctionnalité du Robot, tels que les sous-processus, les plannings, les paramètres de configuration, les fichiers d'entrée, les fichiers de sortie, les fichiers temporaires et les actions effectuées. D'autres détails sur le processus principal doivent être spécifiés, tels que les conditions préalables, la gestion automatique et manuelle des erreurs, la reprise du processus en cas d'échec, l'utilisation d'Orchestrator, la journalisation et la création de rapports, la gestion des identifiants et toute autre information pertinente liée à la sécurité ou à la fonction.

Les Détails du développement (Development Details) doivent contenir des informations sur les paquets utilisés, l'environnement de développement, le niveau de journalisation, le référentiel de codes source et la gestion de versions, une liste de composants de workflow avec leur description et une liste d'arguments, une liste de composants réutilisables, l'arborescence d'invocations des workflows, les journaux et les champs de journaux personnalisés définis, les instantanés pertinents de l'organigramme de processus, le niveau de l'automatisation en arrière-plan et au premier-plan, et tous les autres éléments de développement pertinents ou essentiels.

Développement et révision du code

L'architecte de solutions RPA est chargé de l'encadrement continu des développeurs concernant les meilleures pratiques. Par conséquent, des révisions de code fréquentes et complètes sont obligatoires pour appliquer une qualité très élevée de workflows développés. De cette façon, les développeurs sont motivés pour créer des workflows robustes et pour suivre le guide des meilleures pratiques.

Test

Une fois chaque composant construit, des tests unitaires doivent être effectués. Si chaque composant est testé de manière approfondie, l'intégration se déroule plus facilement et le débogage dure moins longtemps. Le REFramework contient un dossier Test_Framework dans lequel tous les fichiers de test doivent être placés. À l'aide du fichier RunAllTests.xaml, un développeur peut tester automatiquement une séquence contenant un grand nombre de fichiers .xaml, ce qui lui permet d'essayer de petites intégrations entre les composants et d'exécuter des tests de résistance. Un rapport est généré à la fin de chaque test. En règle générale, ces types de tests doivent être exécutés en dehors des heures de bureau, dans des environnements de test, afin d'optimiser le temps du développeur.

L'architecture UiPath recommandée inclut des environnements de Dév (Dev) et de Test (Test) qui permettent de tester les processus en dehors des systèmes de production opérationnels.

Parfois, l'apparence ou le comportement des applications est différent entre les environnements de Dév (Dev), de Test (Test) ou de Production (Production). Des mesures supplémentaires doivent être prises, telles que le nettoyage des sélecteurs voire l'exécution conditionnelle de certaines activités.

Utilisez le fichier UiPath.config ou les actifs Orchestrator pour basculer les indicateurs ou les paramètres de l'environnement actuel. Un paramètre de mode test (Booléen) peut être coché avant d'interagir avec les applications opérationnelles. Il peut être reçu comme une entrée d'actif (d'argument). Lorsqu'il est défini sur Vrai (True), lors du débogage et des tests d'intégration, il suit l'itinéraire du test et n'exécute pas le cas entièrement. Par exemple, le correctif de test peut ignorer l'envoi de notifications, ignore le bouton OK (OK) ou Enregistrer (Save), appuie sur le bouton Annuler (Cancel) ou Fermer (Close) à la place. Lorsqu'il est défini sur Faux (False), l'itinéraire du mode Production (Production) est suivi.

Ceci permet d'effectuer les modifications et de les tester dans les processus qui fonctionnent directement dans les systèmes opérationnels.

Mise en production

Il existe différentes manières de concevoir le flux d'architecture et de mise en production, en prenant en compte la configuration de l'infrastructure, les problèmes sur la séparation des rôles, etc.

Dans ce modèle proposé, les développeurs d'UiPath peuvent créer leurs projets et les tester dans les environnements de Développement (Development) d'Orchestrator. Ils sont autorisés à archiver le projet sur un lecteur géré par un système de contrôle de versions (VCS), tel que GIT, SVN ou TFS.

La publication du paquet et sa mise à disposition pour les environnements de Test (Test) et de Production (Production) est la tâche d'une équipe différente, telle que TI.

Les chemins de déploiement dans Orchestrator sont passés de leur valeur par défaut aux dossiers gérés par le VCS, en modifiant la valeur Storage.Location dans le fichier UiPath.Orchestrator.dll.config de la section Déploiement (Deployment).

Le modèle contient également un référentiel de composants réutilisables.

Voici le flux de publication du projet, étape par étape :

Les développeurs créent le processus, testent et déboguent localement les éléments correspondants (Studio).
Une fois le développement de l'automatisation terminé, le processus est publié dans l'application Orchestrator de développement (Development) et testé à nouveau de bout en bout.
Le dossier du projet est validé (non empaqueté) dans un dossier Bibliothèque principale (Master Library) (dans VCS (VCS)).
L'équipe des opérations informatiques/RPA crée le paquet du projet pour l'AQ. Cette étape est conçue comme mesure de sécurité supplémentaire : le code source d'automatisation est inspecté (par une entité différente) avant d'être empaqueté et exécuté par des robots. Par exemple, le processus empaqueté est stocké dans le dossier Paquets de processus (AQ) (Process Pckgs (QA)) dans VCS (VCS), à partir duquel il est déployé dans les robots AQ et exécuté.
Si des problèmes sont signalés lors des tests, les étapes ci-dessus sont répétées.
Une fois tous les tests AQ réussis, le paquet est transmis dans un environnement de production (Production) - Paquets de processus (Prod) Process Pckgs (Prod).
Lorsque le processus est opérationnel, le paquet de processus est déployé dans les Robots de production et exécuté.

Le Contenu réutilisable (Reusable Content) est créé et déployé séparément, en tant que code UiPath (Bibliothèque de codes réutilisables (Reusable Code Library)) et Invocations (Invokes) (Référentiel d'invocations (Invokes Repository)).

Les workflows avec code source sont les fichiers .xaml contenant des activités pour automatiser les processus communs, tels que Connexion à SAP (Log in to SAP) :

Les Invocations (Invokes) représentent les workflows composés uniquement d'une activité Invocation (Invoke) des workflows de code susmentionnés.

Le panneau Extrait (Snippet) d'un développeur Studio doit désigner ce référentiel d'invocations (Invoke) afin de simplifier l'accès (glisser et déposer) au Contenu réutilisable (Reusable Content).

L'autorité de conception locale responsable de la gestion du Contenu réutilisable (Reusable Content) met à jour (en raison d'un changement de processus, par exemple) les workflows avec le code. Les Invocations (Invokes) restent inchangées.

L'avantage de cette méthode (par opposition à l'utilisation directe de la bibliothèque du code source) est que lors de la modification d'un contenu réutilisable, tous les projets en cours reflètent également cette modification, car ils ne contiennent qu'une Invocation (Invoke) du workflow modifié.

Surveillance

L'utilisation des activités du Message du journal des événements (Log Message) pour suivre l'évolution d'un processus en cours est essentielle à la supervision, au diagnostic et au débogage d'un processus. Les messages doivent fournir toutes les informations pertinentes pour identifier de façon précise une situation, y compris l'ID et l'état de la transaction.

La journalisation doit être utilisée :

au début et à la fin de tous les workflows ;
lorsque les données proviennent de sources externes ;
Chaque fois qu'une exception est générée au niveau supérieur.

Les messages sont envoyés avec la priorité spécifiée (par exemple Informations, Traçage, Avertissement (Info, Trace, Warning)) à Orchestrator et sont également enregistrés dans le fichier .nlog local.

Champs de journaux personnalisés

Pour rendre les données facilement disponibles dans Kibana à des fins de génération de rapports, le Robot peut baliser les messages de journal avec des valeurs supplémentaires à l'aide de l'activité Ajouter des champs de journal (Add Log Fields) . Par défaut, toute sortie de journal UiPath comporte déjà plusieurs champs, notamment message, timestamp, level, processName, fileName et l'identité Windows du Robot. Les champs de journal sont persistants. Par conséquent, si nous n'avons pas besoin de marquer tous les messages avec une balise, les champs doivent être supprimés immédiatement après la journalisation, à l'aide de l'activité Supprimer les champs de journal (Remove Log Fields) . N'utilisez pas un nom de champ qui existe déjà. Il est important de spécifier le type d'argument approprié la première fois lorsque vous ajoutez le champ. C’est ainsi qu’Elasticsearch l’indexe.