- Notes de publication
- Démarrage
- Paramétrage et configuration
- Projets d'automatisation
- Dépendances
- Types de workflows
- Comparaison de fichiers
- Meilleures pratiques d'automatisation
- Conception de workflow
- Automatisation de l'interface utilisateur
- Organisation du projet
- Cycle de vie d'automatisation
- Intégration du contrôle de code source
- Débogage
- L'outil de diagnostic (Diagnostic Tool)
- Analyseur de workflow
- À propos de l'analyseur de workflow
- ST-NMG-001 - Convention d'affectation de noms des variables
- ST-NMG-002 - Convention d'affectation de noms des arguments
- ST-NMG-004 - Duplication du nom complet
- ST-NMG-005 - La variable remplace une autre
- ST-NMG-006 - La variable remplace l'argument
- ST-NMG-008 - Longueur de variable dépassée
- ST-NMG-009 - Ajouter un préfixe aux variables DataTable
- ST-NMG-011 - Ajouter un préfixe aux arguments Datatable
- ST-NMG-012 - Valeurs par défaut de l'argument
- ST-NMG-016 : longueur d'argument dépassée
- ST-DBP-002 - Nombre élevé d'arguments
- ST-DBP-003 - Bloc d'interception vide
- ST-DBP-007 - Plusieurs couches de l'organigramme
- ST-DBP-020 - Propriétés de sortie non définies
- ST-DBP-023 : Workflow vide
- ST-DBP-024 - Vérification de l’activité de persistance
- ST-DBP-025 - Condition préalable à la sérialisation des variables
- ST-DBP-026 - Utilisation de l’activité Délai
- ST-DBP-027 - Pratiques exemplaires de persistance
- ST-DBP-028 - Condition préalable à la sérialisation des arguments
- ST-MRD-002 - Valeurs par défaut des noms d'activités
- ST-MRD-004 - Activités inaccessibles
- ST-MRD-005 - Séquences redondantes
- ST-MRD-007 - Clauses If imbriquées
- ST-MRD-008 - Séquence vide
- ST-MRD-009 - Activités profondément imbriquées
- ST-MRD-011 - Utilisation de la ligne d'écriture
- ST-MRD-017 - Incomplet si (Incomplete If)
- ST-USG-005 - Arguments d'activité codée en dur
- ST-USG-009 - Variables inutilisées
- ST-USG-010 - Dépendances inutilisées
- ST-USG-014 - Restrictions sur les paquets (Package Restriction)
- ST-USG-020 - Nombre minimum de messages consignés
- ST-USG-024 - Non utilisé, sauvegardé pour plus tard (Unused Saved for Later)
- ST-USG-025 - Utilisation abusive de la valeur enregistrée (Saved Value Misuse)
- ST-USG-026 - Restrictions d'activité (Activity Restrictions)
- ST-USG-027 - Packages requis
- ST-USG-028 - Restreindre l'invocation des modèles de fichier
- Variables
- Arguments
- Noms d'espace importés
- Enregistrement
- Éléments de l'interface utilisateur
- À propos des éléments d'interface utilisateur
- Propriétés des activités de l'interface utilisateur
- Exemple d'utilisation des méthodes de saisie
- Méthodes de sortie ou de capture de données d'écran
- Exemple d'utilisation de méthodes de sortie ou de capture de données d'écran
- Génération de tables à partir de données non structurées
- Capture relative de données
- Flux de contrôle
- Sélecteurs
- Réf. d’objets
- Capture de données
- Automatisation des images et des textes
- À propos de l'automatisation des images et des textes
- Activités liées à la souris et au clavier
- Exemple d'utilisation de l'automatisation de la souris et du clavier
- Les activités de type texte
- Exemple d'utilisation d'automatisation de texte
- Activités de type OCR
- Activités de type image
- Exemple d'utilisation de l'automatisation d'image et d'OCR
- Automatisation des technologies Citrix
- Automatisation de RDP
- Automatisation de Salesforce
- Automatisation SAP
- Automatisation VMware Horizon
- Journalisation
- Outil ScreenScrapeJavaSupport
- Protocole Webdriver
- Suite de tests - Studio
- Extensions
- Résolution des problèmes
- À propos de la résolution des problèmes
- Prise en charge et limitations de Microsoft App-V
- Résolution des problèmes rencontrés avec Internet Explorer x64
- Problèmes rencontrés avec Microsoft Office
- Identification des éléments d'IU dans PDF avec options d'accessibilité
- Résolution des problèmes rencontrés avec JxBrowser Applications
- Surveillance des événements utilisateur
- Résolution des problèmes Citrix
Cycle de vie d'automatisation
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.
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.
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.
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éveloppement (Dev) et de 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.
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.
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.
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)).
.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é.
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.
.nlog local.
Champs de journaux personnalisés
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.
