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.

When Attended Robots Make Sense

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.

Reconsidering Attended Robots

Not all processes requiring human input must use Attended Robots. If a judgmental decision is unavoidable, consider splitting the process into smaller sub-processes that can run unattended.

For example, one sub-process could collect data, and after human validation, a second sub-process continues automatically.

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.

Benefits and Practical Considerations

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.

However, several factors affect this decision:

• Attended Robots typically run only during working hours
• Attended Robots keep machines and users busy until execution completes
• Input types and transaction volumes
• Time restrictions and scheduling
• Number of available Robots

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).

The Runtime Guide should contain a high-level runtime diagram and details about Robot functionality, including sub-processes, schedules, configuration settings, and file management.

Include details on prerequisites, error handling, process resumption, Orchestrator usage, logging, reporting, and credential management.

The Development Details should include packages, development environment, logging levels, source control information, and workflow components with descriptions.

Also include reusable components, invoke trees, custom logs, flowchart snapshots, automation levels, and other development details.

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

After each component is built, conduct unit testing. Thorough component testing ensures smoother integration and faster debugging.

Use the REFramework’s Test_Framework folder for test files. The RunAllTests.xaml file enables automated testing of multiple .xaml files. Run tests outside office hours in testing environments to optimize developer time.

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.

Use the UiPath.config file or Orchestrator assets to switch environment-specific flags. Define a test mode Boolean parameter to control behavior during debugging.

When True, the automation follows test routes and doesn't execute fully. For example, skip notifications and use Cancel instead of Save. When False, follow normal production routes.

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

Use Log Message activities to trace process execution for supervision, diagnosis, and debugging. Messages should include transaction IDs and state information for accurate identification.

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.