- Notes de publication
- Démarrage
- Paramétrage et configuration
- Projets d'automatisation
- À propos de la publication de projets d'automatisation
- Conception d'automatisations
- Gérer les package d’activités
- Configuration des paramètres du projet d'activité
- Signature de paquets
- Gouvernance
- Import des entités
- Modern Design Experience
- Lier un projet à une idée dans Automation Hub
- Utilisation du gestionnaire de données
- Dépendances
- Types de workflows
- Comparaison de fichiers
- Meilleures pratiques d'automatisation
- Intégration du contrôle de code source
- Débogage
- 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
- ST-USG-027 - Balises requises
- ST-USG-034 – URL Automation Hub
- Variables
- Arguments
- Noms d'espace importés
- Automatisation Attended basée sur déclencheur
- 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éparation de la prise en charge d'Active Accessibility
- Automatisation des applications exécutées sous un autre utilisateur Windows
- La validation des projets volumineux hérités depuis Windows prend plus de temps que prévu
Organisation du projet
Commencer par une infrastructure générique (et indépendante des processus) permet de gérer n'importe quel processus de manière cohérente et structurée. Une infrastructure permet de commencer par une vue de haut niveau, puis d'explorer les détails spécifiques de chaque processus.
Le modèle Infrastructure d'entreprise robotique (Robotic Enterprise Framework) propose un aperçu détaillé flexible d'un processus répétitif et inclut un ensemble représentatif de pratiques décrites dans ce guide. Il peut être facilement utilisé comme point de départ solide pour le développement de l'automatisation des processus par la robotique (RPA) avec UiPath. Le modèle repose sur une structure Machine d'état (State Machine).
Mode de fonctionnement :
- Le Robot charge les paramètres à partir du fichier de configuration et les actifs Orchestrator, tout en les conservant dans un dictionnaire qui doit être partagé entre les workflows.
- Le Robot récupère les identifiants requis et se connecte à toutes les applications.
- Il effectue d'autres tentatives en cas d'erreurs, puis réussit ou abandonne.
- Le Robot vérifie la file d'attente d'entrée ou d'autres sources d'entrée pour démarrer une nouvelle transaction.
- Si plus aucune donnée d'entrée n'est disponible, configurez le workflow afin d'attendre et de réessayer ou de terminer le processus.
- Les interactions d'IU pour traiter les données de transaction sont exécutées.
- Si les transactions sont correctement traitées, l'état de la transaction est mis à jour et le Robot passe à la transaction suivante.
- En cas d'erreurs de validation, l'état de la transaction est mis à jour et le Robot passe à la transaction suivante.
- Si des exceptions sont générées, le Robot réessaye de traiter la transaction un certain nombre de fois (si configuré), ou marque l'élément comme échec et redémarre.
-
À la fin, un e-mail est envoyé avec l'état du processus, si configuré.
Pour les processus basés sur une transaction (tels que le traitement de toutes les factures à partir d'un fichier Excel) qui ne sont pas exécutés via Orchestrator, des files d'attente locales peuvent être générées (à l'aide des méthodes mettre en file d'attente/supprimer de la file d'attente de .NET).
Ensuite, le flux du processus de haut niveau (gestion des exceptions, nouvelles tentatives, récupération) peut être facilement répliqué. Cela est beaucoup simple que regrouper le processus entier sous une boucle Pour chaque ligne (For Each Row).
Tous les fichiers REFrameWork, ainsi que le documentation sont disponibles sur cette page.
La division des projets en workflows plus petits et l'utilisation des activités Appeler le fichier de flux de travail (Invoke Workflow File) sont primordiales pour une bonne conception de projet. Des flux de travail dédiés permettent des tests indépendants des composants, encouragent la collaboration en équipe et améliorent les performances de conception et d'exécution par rapport aux projets organisés en fichiers moins nombreux et plus volumineux. Nous vous recommandons de limiter la taille des fichiers de flux de travail à moins de 5 Mo. Les fichiers de workflow de plus de 10 Mo ne sont pas pris en charge.
Choisissez judicieusement le type de mise en page (organigrammes et séquences). En général, la logique du processus réside dans les organigrammes, tandis que la navigation et le traitement de données s'effectuent en séquences.
En développant une logique complexe dans une séquence, vous vous retrouverez dans un labyrinthe de conteneurs et de blocs décisionnels dont le suivi et la mise à jour ne sont pas simples.
Par contre, les interactions d'IU dans un organigramme compliquent la création et la gestion.
Les fichiers associés au projet (tels que les modèles d'e-mail) peuvent être organisés dans des dossiers locaux ou des lecteurs partagés.
lib/net45
.
Ces dossiers peuvent être également stockés sur un lecteur partagé de sorte que tous les Robots se connectent à la même source unique. De cette façon, les fichiers associés au processus peuvent être vérifiés et gérés entièrement par les utilisateurs professionnels, sans assistance de l'équipe RPA. En revanche, la décision (dossiers partagés ou locaux) est complexe et doit prendre en compte différents aspects liés au processus et à l'environnement : taille des fichiers, fréquence des modifications, simultanéité de modification du même fichier, stratégies de sécurité, etc.
Afin de gérer facilement la gestion des versions des projets et de partager le travail avec davantage de développeurs, nous vous recommandons d'utiliser un système de contrôle de version. UiPath Studio est directement intégré à GIT, TFSet SVN. Vous pouvez trouver un tutoriel expliquant les étapes de connexion et les fonctionnalités ici.
.config
, (.xlsx
, .xml
ou .json
) ou dans Orchestrator, en tant qu'actifs, s'ils changent souvent.
De manière générale, la solution finale doit être évolutive afin de permettre des variations et des modifications des données d'entrée sans intervention du développeur. Par exemple, les listes avec les clients autorisés à accéder à un certain type de transaction, les e-mails de personnes pour recevoir des notifications, etc. doivent être stockés dans des fichiers externes (tels qu'Excel) où les professionnels ou autres départements peuvent les modifier directement (ajouter/supprimer/mettre à jour).
Pour tout processus répétitif, toutes les invocations de workflows à partir de la boucle principale doivent être marquées avec l'option Isolé (Isolated) pour fournir une protection contre les pannes potentielles du Robot (telles qu'une mémoire insuffisante).
Aucun identifiant ne doit être stocké directement dans le workflow, mais plutôt chargé à partir d'emplacements plus sécurisés tels que le magasin d'informations d'identification Windows local ou les actifs Orchestrator. Vous pouvez les utiliser dans les workflows via l'activité Extraire l'identifiant (GetCredential).
Deux types d'exceptions peuvent être générés lors de l'exécution d'un processus automatisé : assez prévisibles ou totalement inattendus. En fonction de cette distinction, il existe deux manières de résoudre les exceptions, par actions explicites exécutées automatiquement dans le workflow ou en réaffectant le problème à des opérateurs humains.
Dans les cas où des exceptions peuvent être rencontrées, il est utile d'ajouter un Gestionnaire global d'exceptions (Global Exception Handler) au projet d'automatisation. Seulement ce type de workflow peut être ajouté par projet d'automatisation. Le Gestionnaire global d'exceptions n'est pas disponible pour les bibliothèques.
Le workflow peut être défini pour déterminer le comportement du workflow lorsqu'une exception est rencontrée en ignorant l'erreur et en passant à l'activité suivante, en recommençant l'activité qui a généré l'erreur, en abandonnant l'exécution ou en continuant et en générant à nouveau l'erreur.
En outre, les arguments contenus dans le Gestionnaire global d'exceptions peuvent être définis pour consigner le nom de l'activité qui a levé l'exception ou retenter l'activité un certain nombre de fois. Pour plus d'informations sur l'utilisation de ses arguments, consultez la page Gestionnaire global d'exceptions.
Comme solution de rechange au Gestionnaire global d'exceptions, la propagation des exceptions peut être contrôlée en plaçant le code sensible à l'intérieur de blocs Try/Catch où les situations peuvent être gérées de manière appropriée. Au niveau supérieur, le diagramme de processus principal doit définir des mesures correctives générales pour résoudre toutes les exceptions génériques et pour garantir l'intégrité du système.
Les gestionnaires contextuels offrent plus de flexibilité afin que les Robots s'adaptent aux différentes situations. Ils doivent être utilisés pour implémenter d'autres techniques, le nettoyage ou la personnalisation des messages de l'utilisateur/du journal. Bénéficiez du mécanisme de propagation verticale d'exceptions pour éviter des gestionnaires en double dans les sessions de capture en remontant le gestionnaire à des niveaux où il peut couvrir toutes les exceptions à un seul emplacement.
Vous devez fournir suffisamment de détails dans le message d'exception afin que l'humain le comprenne et qu'il prenne les mesures nécessaires. Les messages et les sources d'exceptions sont essentiels. La propriété source de l'objet exception indique le nom de l'activité qui a échoué (dans un workflow invoqué). Une fois de plus, l'affectation de noms est cruciale, car des noms imprécis ne fournissent aucune indication claire sur le composant qui est tombé en panne.
Comme vous le voyez ci-dessous, le choix de ne pas renommer l'activité Invocation (Invoke) rend la source de l'exception insignifiante en cas de panne (par exemple Invoquer le fichier de workflow (Invoke Workflow File) > Invoquer le fichier de workflow (Invoke Workflow File) > ; Invoquer le fichier de workflow (Invoke Workflow File) > ; Saisir dans (Type Into)).
Dans le flux de processus, assurez-vous de fermer les applications cible (navigateurs, applications) après que les Robots interagissent avec elles. Si elles restent ouvertes, elles utilisent les ressources de la machine et peuvent interférer avec les autres étapes de l'automatisation.
Avant de publier le projet, examinez une dernière fois les workflows et effectuez le nettoyage :
- Supprimez les variables non référencées.
- Supprimez les sorties Ligne d'écriture (Write Line) temporaires.
- Supprimez le code désactivé.
- Assurez-vous que l'affectation de noms est significative et unique.
- Supprimez les conteneurs inutiles (Cliquer droit (Right-click) > Supprimer la séquence (Remove Sequence)).
project.json
.
La description du projet est également importante (elle s'affiche dans Orchestrator). Elle permet de différencier plus facilement les processus. Par conséquent, choisissez également une description significative.
Lors du développement, nous devons souvent automatiser les mêmes étapes dans plus d'un workflow/projet. Par conséquent, il est pratique courante de créer des workflows qui contiennent des petits éléments d'automatisation et de les ajouter à la bibliothèque.
Il n'existe aucune recette universelle qui indique comment fractionner des processus donnés.
Cependant, la séparation de la logique métier des composants d'automatisation est un bon principe qui permet de créer un code qui peut être réutilisé efficacement.
Supposons qu'une partie de votre processus requiert la lecture des informations du client. Ensuite, selon ces informations et les règles métier internes, mettez à jour les détails du client.
Extraire les informations du client (Get Customer Info) et Modifier les informations du client (Change Customer Info) doivent être deux composants d'automatisation distincts, complètement indépendants des processus. La logique (mettez à jour le type de client uniquement lorsque le nombre total est supérieur à 100 000 dans les 12 derniers mois) doit être indépendante de l'automatisation. Les deux composants peuvent être utilisés ultérieurement, séparément, dans le même projet ou dans un autre, avec une logique différente; Si nécessaire, des données spécifiques peuvent être envoyées à ces composants via des arguments.
Modifier les informations du client (Change Customer Info) ne doit pas être invoqué depuis Extraire les informations du client (Get Customer Info), car cela complique le test, la gestion et la réutilisation des exceptions.
Lorsque la séparation entre les actions n'est pas évidente, le copier et coller du code existant d'un workflow vers un autre (ou d'un projet vers un autre) est également une bonne indication que vous devez créer un composant (workflow) distinct pour le code et l'invoquer, au besoin.
Glisser et déplacer le code existant de la bibliothèque vers un workflow est plus simple que recréer entièrement le code plusieurs fois. La gestion des données (tri, filtrage) ou du texte (fractionnement, modèles Regex) sont des exemples d'éléments qui peuvent être ajoutés à la bibliothèque type. Veuillez prendre en compte qu'une fois le code ajouté au workflow, il devient statique. Si vous mettez à jour ainsi le workflow dans la bibliothèque, il ne sera pas reflété dans les processus opérationnels existants.
-
Modularité :
- La séparation des problèmes avec des workflows dédiés permet un développement et des tests très précis.
- Extrayez et partagez des composants ou workflows réutilisables entre des projets.
-
Maintenabilité :
- Normes correctes de structure et de développement.
-
Lisibilité :
- Structure de processus standardisée encourageant des pratiques de développement claires ;
- Noms significatifs pour les fichiers de workflow, les activités, les arguments et les variables.
-
Flexibilité :
- Le stockage des paramètres d'environnement dans des fichiers de configuration externes ou des instances d'Orchestrator simplifie l'exécution de l'automatisation dans les environnements de test et de production.
-
Fiabilité :
- Gestion des exceptions et rapports d'erreurs :
- Mise à jour de l'avancement de l'exécution en temps réel.
-
Évolutif :
- Prêt pour l'incorporation de nouveaux cas d'utilisation.