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.

Lorsque les robots assistés ont du sens

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.

Repenser les Robots Attended

Tous les processus nécessitant une intervention humaine ne doivent pas utiliser de robots Attended. Si une décision prise de valeur prise sur un option est impossible, envisagez de diviser le processus en sous-processus plus petits pouvant s'exécuter de manière non assistée.

Par exemple, un sous-processus peut collecter des données et, après validation humaine, un deuxième sous-processus se poursuit automatiquement.

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.

Avantages et considérations pratiques

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, plusieurs facteurs affectent cette décision:

• Les Attended Robots s’exécutent généralement uniquement pendant les heures de travail
• Les Attended Robots occupent les machines et les utilisateurs jusqu’à la fin de l’exécution
• Types d'entrée et volumes de transactions
• Restrictions temporelles et planification
• Nombre de robots disponibles

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 de runtime doit contenir un diagramme de runtime de haut niveau et des détails sur la fonctionnalité du Robot, y compris les sous-processus, les planifications, les paramètres de configuration et la gestion des fichiers.

Incluez des détails sur les prérequis, la gestion des Errors, la reprise du processus, l'utilisation d'Orchestrator, la journalisation, la création de rapports et la gestion des informations d'identification.

Les détails du développement doivent inclure les packages, l'environnement de développement, les niveaux de journalisation, les informations de contrôle de code source et les composants de workflow avec des descriptions.

Incluez également des composants réutilisables, des arborescences d'invocation, des journaux personnalisés, des instantanés Flowchart, des niveaux d'automatisation et d'autres détails du développement.

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 créé, effectuez des tests unitaires. Des tests approfondis des composants garantissent une intégration plus fluide et un débogage plus rapide.

Utilisez le dossier Test_Frameworkde REFramework pour les fichiers de test. Le fichier RunAllTests.xaml permet de tester automatiquement plusieurs fichiers .xaml . Exécutez les tests en dehors des heures de bureau dans des environnements de test afin d'optimiser le temps des développeurs.

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 ressources Orchestrator pour basculer entre les indicateurs spécifiques à l'environnement. Définissez un paramètre booléen de mode de test pour contrôler le comportement lors du débogage.

Lorsqu'il est défini sur True, l'automatisation suit les chemins de test et ne s'exécute pas entièrement. Par exemple, ignorez les notifications et utilisez Annuler au lieu d' Enregistrer. Lorsqu'il est défini sur False, suivez les voies de production normales.

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 :

1. Les développeurs créent le processus, testent et déboguent localement les éléments correspondants (Studio).
2. 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.
3. Le dossier du projet est validé (non empaqueté) dans un dossier Bibliothèque principale (Master Library) (dans VCS (VCS)).
4. 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é.
5. Si des problèmes sont signalés lors des tests, les étapes ci-dessus sont répétées.
6. 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).
7. 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

Utilisez les activités Message du journal pour suivre l'exécution du processus à des fins de supervision, de diagnostic et de débogage. Les messages doivent inclure les identifiants de transaction et les informations sur l’état pour permettre une identification précise.

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 que les données soient facilement disponibles dans Kibana à des fins de rapports, le Robot peut marquer les messages du journal avec des valeurs supplémentaires à l'aide de l'activité Ajouter des champs de journaux (Add Log Fields). Par défaut, toute sortie de journal UiPath possède déjà plusieurs champs, dont message, timestamp, level, processName, fileName, et l'identité Windows du Robot. Les champs de journaux sont persistants. S'il n'est donc pas nécessaire de marquer tous les messages avec une balise, les champs doivent être supprimés immédiatement après la consignation, à l'aide de l'activité Supprimer les champs de journaux (Remove Log Fields). N'utilisez pas un nom de champ qui existe déjà. Il est important de spécifier le type correct d'argument la première fois que vous ajoutez le champ. Il s'agit de la manière dont Elasticsearch l'indexe.