Méthodologie de réutilisation des composants de l'interface utilisateur

Les projets UiPath ont deux couches principales :

• Couche logique : contient l'ensemble de la validation et du traitement des données, ainsi que toutes les autres instructions logiques nécessaires au flux du processus.
• Couche d'interaction GUI (GUI interaction layer) : utilisée pour extraire et saisir des données dans l'application.

Pour éviter les problèmes liés à la maintenabilité et à la réutilisation des composants, vous pouvez séparer la couche d'interaction de l'interface graphique en créant une série de bibliothèques avec des composants réutilisables dédiées exclusivement à l'interaction avec les interfaces utilisateur. De cette façon, vous pouvez créer une bibliothèque polyvalente et très robuste qui est facile à maintenir (elle ne contient que des éléments d'interaction GUI et aucune autre logique dépendante du processus) et extrêmement réutilisable (il est très probable qu'un processus différent qui automatise la même application puisse réutiliser au moins certains des composants).

En outre, le référentiel d’objets introduit dans Studio v2020.10 a apporté une toute nouvelle façon de créer et de gérer les éléments utilisés dans l’automatisation de l’interface utilisateur, ce qui change la donne lorsqu’il s’agit de créer des automatisations de l’interface utilisateur évolutives et hautement réutilisables.

This article defines a methodology in which we can use libraries and the Object Repository to build easily maintainable and reusable code, describes the architectural principles and best practices behind it, and offers a detailed breakdown of the steps needed to create reusable components, together with a number of examples that use the ACME web application.

General principles

Il existe une variété de principes de développement logiciel qui peuvent être appliqués quel que soit le langage de programmation ou la plate-forme utilisée et qui peuvent s'avérer très utiles dans le contexte du développement RPA avec UiPath Studio.

Separation on concerns

C’est le principe le plus important à aborder. La séparation des préoccupations stipule qu'un programme doit être divisé en différentes sections, de sorte que chaque section réponde à une préoccupation distincte. Dans notre cas, nous devons superposer notre solution, ce qui signifie que chaque section doit devenir une couche. Séparer une solution sur des couches permet de tester les couches individuellement. Pour une application logicielle normale, nous avons généralement trois couches distinctes :

• La Couche de présentation (Presentation Layer) fait référence à l'interaction avec l'utilisateur, en affichant les données et en les présentant à l'utilisateur. Cette couche ne doit pas contenir de logique métier. 

  Dans le contexte d'un projet RPA, la couche d'interaction GUI remplace cette couche, car l'objectif principal d'une automatisation est d'interagir avec d'autres applications plutôt qu'avec un utilisateur réel.

• La Couche domaine (Domain layer) concerne la logique du domaine, c'est-à-dire le domaine général des affaires/problèmes que l'application résout.

  Dans le contexte d'un projet RPA, c'est la couche Logic qui concerne la logique de l'application.

• La Couche de persistance (Persistence Layer) est l'endroit où les données requises par l'application sont stockées.

  Il ne s'agit pas d'une couche obligatoire dans un projet RPA, car il existe des cas d'utilisation dans lesquels il n'y a pas de stockage de données permanent. Étant donné la portée de cet article, nous allons omettre cette couche.

Single responsibility

Another principle we need to take into consideration when designing an RPA project is the single responsibility principle. This means that a XAML file should do one thing and one thing only. This principle is associated with the low coupling and high cohesion principle. This means that the code should be modularized, even though it is layered. Therefore, we can have multiple modules for a single layer.

• Un Faible couplage signifie qu'un module doit dépendre le moins possible d'un autre module. Dans un projet UiPath, nous obtenons la modularisation en utilisant des bibliothèques (vous pouvez en savoir plus à ce sujet dans la section Méthode).
• Une Cohésion élevée signifie que les actions associées à la même application doivent être conservées dans le même module.

Exploitation du référentiel d'objets

An RPA process can be simply defined as a combination of data, data manipulation, and application interaction.

• Data - Pre-defined data types selected when defining variables or arguments, or your own types that you can import and use in Studio. In addition, the Data Service feature introduced in v2020.10 offers a centralized location where you can create data types and reuse them across automations.
• Data manipulation - This can de done through activities which are the building blocks of automation and/or data manipulation expressions. Activities are available in packages that you can install in Studio. You can also create your own custom activities when certain functionalities are not covered by the available packages. For more information about how you can build custom UiPath activities, see Creating a Custom Activity.
• Application interaction - This can be done through UI Automation or integrations/APIs. UI Automation can be used for most applications available today. UI interaction components can be reused with the help of libraries or the Object Repository.

Le référentiel d'objets a une structure hiérarchique dans laquelle chaque nœud représente des écrans ou des éléments, tous situés au niveau de l'application. La structure est la suivante :

• Les applications d'interface utilisateur sont des applications ciblées qui peuvent avoir plusieurs versions et chaque version peut avoir plusieurs écrans.
• L’écran est une étendue d’IU qui regroupe plusieurs éléments appartenant au même écran. L'étendue de l'interface utilisateur est soit extraite des activités à l'intérieur du workflow, soit générée au moment de la capture de l'élément.
• Les éléments d'IU contiennent des sélecteurs d'éléments complets ou partiels, des sélecteurs d'ancrage, un contexte de capture d'image d'écran et d'élément ainsi que d'autres métadonnées décrivant l'élément à l'écran.
• Les Descripteurs d'IU sont un sur-ensemble de sélecteurs. Ils contiennent des informations permettant d'identifier de manière unique les éléments à l'écran. Ils sont extraits des activités du workflow et ajoutés au schéma structuré qui les regroupe par application, version de l'application, écrans et éléments d'IU. En dehors de la structure de taxonomie, seuls les écrans et les éléments contiennent des informations de descripteur, tandis que les autres sont utilisés pour le regroupement et leur rôle est d'assurer les mises à niveau entre les versions d'une application.

Par exemple, dans l’image ci-dessous, nous pouvons identifier :

• Application d'IU : ACME version 1.0.0.
• Écrans (Screens) : Tableau de bord, Factures, Connexion.

• Éléments d'IU: E-mail, bouton Connexion.

  
  

  

  
  

Pour chaque élément et écran du référentiel d'objets, fournissez les détails suivants :

• Le nom exact de l'écran, de la page ou de l'élément, tel qu'il apparaît dans l'interface utilisateur (par exemple, bouton Connexion (Login button)).
• Le type, par exemple Bouton (Button) ou Entrée (Input) (uniquement pour les éléments).
• Une description facultative. Nous vous recommandons d’ajouter un aperçu rapide de la façon dont l’élément peut être utilisé (par exemple, Cliquez sur Connexion pour terminer le processus de connexion).

• Descripteur d'IU (UI Descriptor) : informations qui identifient de manière unique l'élément. Intègre des sélecteurs classiques, des sélecteurs de correspondances approximatives et une automatisation basée sur des images. Nous vous recommandons d’utiliser l’automatisation basée sur l’image uniquement si les autres méthodes ne fonctionnent pas.

  
  

  

  
  

See About Object Repository for more information on how to use the Object Repository.

Scaling up by combining workflow libraries and the Object Repository

Le référentiel d'objets peut avoir un impact significatif sur la facilité et l'efficacité de la création d'automatisation de l'interface utilisateur, mais pour tirer pleinement parti de cette fonctionnalité, vous pouvez incorporer les éléments du référentiel d'objets dans un projet de bibliothèque distinct qui comprend également toutes les interactions d'IU qui doivent être construites. Cela vous permet de créer des projets qui ne contiennent aucune interaction d'IU et n'incluent que la logique des automatisations.

Nous vous recommandons de créer une bibliothèque pour chaque application que vous prévoyez d'automatiser et d'y inclure toutes les interactions d'IU et les éléments du référentiel d'objets. L'activité de bibliothèque peut ensuite être appelée à partir d'un fichier de workflow qui fait partie de la couche logique (le projet principal). Cela garantit que :

• Les modifications apportées à l'interaction de l'interface utilisateur n'affecteront pas la logique de l'application. Cela peut être associé à une séparation modèle-vue-contrôleur où, dans notre cas, la couche modèle est principalement concernée par les données transmises du contrôleur à la vue.
• Une fois qu'une bibliothèque est publiée et qu'un package est créé, il peut être référencé dans différents projets sans avoir à être réécrit à chaque fois et sans avoir à copier-coller le code entre plusieurs projets. Si une modification se produit dans l'interaction de l'IU, la bibliothèque peut être mise à jour, une nouvelle version publiée et tous les projets mis à jour pour utiliser la dernière version. De plus, les modifications pouvant survenir dans la couche logique n'affecteront pas l'interaction de l'interface utilisateur.
• Orchestrator pouvant stocker plusieurs versions d'une même bibliothèque, si une version antérieure doit être utilisée à nouveau, elle sera facilement récupérable. De cette façon, différentes versions de la même bibliothèque peuvent être utilisées dans différents projets et un seul projet d'automatisation peut basculer instantanément entre différentes versions de la même bibliothèque.

En utilisant cette méthodologie, le projet d'automatisation principal (le contrôleur) contiendra toute la logique dépendante du processus et il interagira avec l'interface utilisateur en exploitant les workflows à l'intérieur de la bibliothèque (qui peut être considérée comme une pseudo-vue). Enfin, le modèle est représenté par les arguments qui nous aident à passer des données entre ces 2 composants.

Creating a UI library

Suivez ces étapes pour créer une bibliothèque d'IU comme décrit ci-dessus :

1. Analysez votre processus et décomposez-le en étapes qu'il contient

We recommend creating a flow diagram to visualize the process.

2. Attribuez chacune des étapes à une catégorie

En fonction de la couche à laquelle elle appartient, affectez chaque étape à la catégorie de couche GUI ou à la catégorie de couche logique. Par exemple :

• Attribuez des étapes telles que Cliquer (Click), Saisir dans (Type Into), and Obtenir le texte (Get Text) à la couche d'interaction GUI.

  Conseil : n'ajoutez pas d'activités individuelles à la bibliothèque, ajoutez uniquement des actions plus complexes telles que cliquer jusqu'à ce que quelque chose apparaisse dans l'interface utilisateur, parcourir toutes les pages d'une table et extraire toutes les lignes, ou une action plus complexe comme se connecter, qui se compose de plusieurs parties d'interaction GUI plus petites. En règle générale. chaque composant que vous ajoutez à une bibliothèque doit être une action, un élément d'automatisation plus complexe impliquant plusieurs activités, plutôt qu'une seule activité d'automatisation de l'interface utilisateur.

• Attribuez à la couche logique des actions telles que le traitement des fichiers, la validation et le filtrage des données et la gestion des exceptions métier. Gardez à l'esprit que la couche logique doit appeler la couche GUI afin d'effectuer ses étapes.

3. Créez une bibliothèque distincte pour chaque application utilisée dans l'automatisation

4. Remplir et publier les bibliothèques d'IU

Pour chaque bibliothèque que vous créez, procédez comme suit :

1. Créez l'objet d'application et les écrans nécessaires dans le référentiel d'objets.

   
   

   

   
   

2. Pour chaque écran du référentiel d'objets, créez les éléments nécessaires et construisez leurs descripteurs.

   
   

   

   
   
   Remarque : si vous ne pouvez pas utiliser le référentiel d'objets, suivez la même procédure, mais ignorez les deux étapes précédentes (4-1 et 4-2).

3. Développez un fichier XAML pour chaque action nécessaire. Des écrans et des éléments peuvent être ajoutés à mesure que de nouveaux fichiers de workflow sont créés. Cette étape peut donc être effectuée de manière interchangeable avec les deux étapes précédentes.

   Par exemple, voici quelques-uns des composants conçus pour automatiser les processus de test ACME (Acme Test Processes).

   
   

   

   
   
4. Publiez la bibliothèque sur Orchestrator ou sur un flux NuGet local.

5. Installez les bibliothèques dans vos projets d'automatisation

Installez les bibliothèques nécessaires à partir de la fenêtre Gérer les packages (Manage Packages) pour les ajouter en tant que dépendances de projet. Chaque workflow à l'intérieur des bibliothèques est disponible en tant qu'activité dans le panneau Activités (Activities). Vous pouvez les glisser-déposer dans le workflow du projet et les utiliser de la même manière que vous utilisez les activités.

Meilleures pratiques

Arguments

• Nommez les arguments en utilisant la norme PascalCase. Il s'agit de la norme utilisée pour les paramètres des activités dans les bibliothèques UiPath Studio.
• N'incluez pas les préfixes in_, out_, io_` dans les noms d'arguments car ils apparaîtront en tant que propriétés des activités dans la bibliothèque.

  Par exemple, les arguments peuvent ressembler à l'image ci-dessous. Si vous examinez votre composant publié, vous pouvez voir que vos arguments sont déjà séparés en différentes catégories en fonction de leur type. Il serait donc redondant d'ajouter le préfixe.

  
  

  

  
  
• Tous les workflows à l'intérieur d'une bibliothèque GUI qui ouvrent/lancent l'application à automatiser (par exemple, une activité qui s'ouvre et se connecte à l'application) doivent renvoyer la fenêtre d'application résultante en utilisant soit un argument de sortie de type UiPath.Core.UiElement pour l'expérience de conception moderne, ou UiPath.Core.Window ou UiPath.Core.Browser pour l’expérience classique. De plus, pour l'expérience classique et moderne, toutes les autres activités du package doivent avoir un argument in de type UiPath.Core.Window ou UiPath.Core.Browser qui indiquera la fenêtre correcte dans laquelle l'action en cours doit être effectuée. Ceci est extrêmement utile si plusieurs instances d'une application sont ouvertes pendant le runtime des processus. Si vous utilisez l'expérience de conception classique, n'envoyez pas de sélecteurs en tant qu'arguments.

Developing a library of automation components for the ACME website (you can download example library below) requires a component which opens the browser and performs the login operation. This activity should take as arguments the username, password, site URL, and return the Browser element. Optionally, to support a scenario in which the login takes place in an existing window, the browser can be sent as an in/out argument.

L'élément Navigateur (Browser) est de type UiPath.Core.UiElement :

Voici à quoi ressembleraient les arguments :

Lors de la création du workflow qui ouvre le navigateur (par exemple, le workflow Connexion (Login) ), vous devez d'abord vérifier si l'argument Navigateur (Browser) est null et, dans le cas où cela est vrai (true), ouvrir <https://acme-test.uipath.com/> dans un nouveau navigateur dans un workflow distinct :

Une fois la connexion effectuée et l'élément Navigateur (Browser) renvoyé au processus, toutes les autres activités de cette bibliothèque nécessiteront ce paramètre. Par exemple, l'activité qui télécharge toutes les factures à partir du site Web aura les paramètres suivants :

Si un navigateur valide n'est pas transmis à cette activité, l'exécution génère une erreur.

Gestion des erreurs

• À l'intérieur d'une bibliothèque, générez toujours des erreurs lorsqu'elles apparaissent, ne les signalez pas via des arguments de sortie.
• À la fin d'un composant de bibliothèque, nous vous recommandons de valider son résultat. Vérifiez si l’action souhaitée a eu lieu et générez une exception si ce n’est pas le cas.

Exemple

Lors de la création d'un composant qui effectue la connexion à l'application, vous souhaiterez peut-être lever une exception si la connexion ne s'effectue pas correctement. Pour y parvenir, après avoir saisi les informations d'identification et cliqué sur le bouton Connexion, ajoutez une activité Vérifier l'état de l'application (Check App State) (lors de l'utilisation d'Expérience de Conception Moderne (Modern Design Experience)) ou une activité Élément existant (Element Exists) (lors de l'utilisation d'Expérience de Conception Classique (Classic Design Experience)) avec un délai d'attente de 10 secondes qui vérifie si le libellé « Bienvenue... » apparaît. Si cette activité renvoie false, cela signifie que le processus d'authentification n'a pas réussi et qu'une exception est levée :

Structure et affectation de noms

La création d'un composant pour chaque activité signifie que votre bibliothèque deviendra très volumineuse très rapidement. Pour permettre à vos développeurs de les identifier facilement dans le panneau Activités, il est essentiel de définir une norme d'affectation de noms de vos composants. La norme que nous recommandons pour nommer les composants est {Action} {Entity Used by Activity}. Cette norme :

• Permet aux développeurs de rechercher un composant par son nom, l'action effectuée par cette activité ou par l'entité utilisée lors de cette action.
• Permet de comprendre très facilement à quoi sert le composant et avec quelles pages de l’application il interagit.

Dans certains cas, vous pouvez utiliser simplement {Action}. Vous pouvez le faire si l'action n'est pas effectuée sur une entité (par exemple, Connexion (Login)) ou si vous devez donner plus d'informations via le nom en ajoutant plus d'attributs au nom, chacun séparé par un espace.

De plus, nous vous recommandons de créer une structure de dossiers à l'intérieur du projet de bibliothèque et de regrouper les composants similaires dans le même dossier. Une bonne règle de base est d'avoir un dossier pour chaque entité principale avec laquelle vous interagissez à l'intérieur de la couche GUI. S'il existe un grand nombre d'entités avec lesquelles vous pouvez interagir dans une application, une structure de dossiers multicouche peut être utilisée. Cela améliore considérablement la cohésion de votre bibliothèque et permet de voir plus facilement les actions possibles pouvant être exploitées pour chaque entité.

Vous pouvez nommer les dossiers en utilisant le nom de l'entité avec laquelle les composants interagissent {Entity Used by Activity} ou l'activité générale qu'ils effectuent {Action}. Par exemple, si vous souhaitez créer un dossier dans lequel stocker tous les composants qui naviguent dans les pages d'une application Web, vous pouvez l'appeler Navigation).

Une convention d'affectation de noms doit également être appliquée aux entités du référentiel d'objets, telles que les écrans ou les éléments, de préférence la même que dans le cas des workflows et des dossiers, PascalCase.

Exemple

Le site Web de l’ACME (https://acme-test.uipath.com/) contient plusieurs pages qui permettent aux utilisateurs d'interagir avec des entités telles que les Éléments de travail, les Chèques, les Comptes, les Fournisseurs, les Factures, etc.

Lors de la création d'une bibliothèque avec des composants qui interagissent avec les éléments susmentionnés sur le site Web d'ACME, vous pouvez créer une structure de dossiers et nommer les workflows dans la bibliothèque comme dans l'image suivante :

Remarque : nous vous recommandons d'utiliser la norme Titre de cas (Title Case) pour les noms de chaque composant/dossier (Nom de l'application (Application Name), Action, Entité utilisée par l'activité (Entity Used by Activity)).

Approach for larger solutions

Dans les projets d'automatisation plus importants, plusieurs composants d'une bibliothèque peuvent avoir un morceau de code très similaire, voire identique. Dans ce cas, vous devez isoler ce composant dans un workflow distinct et, si vous ne souhaitez pas que ce workflow soit accessible en dehors de la bibliothèque, le marquer comme ignoré de la publication pour le rendre privé.

De plus, il est possible que la même logique doive être implémentée entre plusieurs processus. Dans ce cas, l'élément logique réutilisable doit être isolé dans une bibliothèque distincte.

Le diagramme suivant donne un aperçu de ce que pourrait être une solution de ce type :

Bénéfices

• Créez une seule couche sans interférer avec l'autre.
• Réutilisez le code existant sans avoir à le réécrire à chaque utilisation.
• Modifiez facilement l'interaction d'IU lorsqu'une mise à jour de l'application se produit et transmettez la modification à tous les processus utilisant la bibliothèque sans avoir à les republier.
• Le partage de la couche d'interaction de l'interface utilisateur entre plusieurs processus signifie que le même module est testé de manière plus approfondie et que toutes les corrections peuvent être apportées pour tous les processus à la fois, ce qui permet d'obtenir des automatisations très robustes et fiables.
• Le fait de disposer d'une bibliothèque d'interactions GUI dédiée facilite la création de projets d'automatisation de test dédiés pour tester l'automatisation de l'interface utilisateur pour des applications spécifiques, garantissant ainsi que le code est très facile à tester et que les modifications importantes apportées à l'application sont rapidement détectées.

Example projects

To exemplify the creation and usage of a library using Object Repository, we created a use case with the ACME web application.

Bibliothèque

La bibliothèque contenant toutes les activités d'automatisation ACME s'appelle Acme_ObjectRepository. Vous trouverez la dernière version ci-dessous :

Download library project

Download library package

Même si la bibliothèque est un module axé sur l'interaction avec l'application Web ACME, elle est également modularisée et organisée en plusieurs dossiers, en fonction de leur objectif :

Voici une répartition rapide des composants de la bibliothèque :

• Connexion ACME .xaml (Login Acme.xaml) : se connecte à l'application. Contient les arguments suivants :

  • Quatre arguments d'entrée (URL, Nom d'utilisateur, Mot de passe, Délai d'attente souhaité).

  • L'argument d'Entrée/de Sortie (In/Out) du Navigateur (Browser) de type UiPath.Core.UiElement. Ce composant s'attachera à toutes les fenêtres ACME déjà ouvertes ou ouvrira une nouvelle fenêtre de navigateur si ce n'est déjà fait et effectuera la connexion. Le paramètre du navigateur renverra la fenêtre du navigateur et cette variable sera transmise à tous les autres composants de la bibliothèque.

    
    

    

    
    
• Déconnexion ACME .xaml (Logout Acme.xaml) : invoque le workflow Accédez à la page d'accueil à partir du module de navigation, puis met fin à la session en cours. 

• Module Options de l’utilisateur : contient les options qui peuvent modifier les configurations du compte actuel dans l'application Web ACME. 

  • Réinitialiser les données de test .xaml (Reset test data.xaml) : réinitialise les données de test utilisées dans l'application ACME.

• Module Facture (Invoices) : contient les actions effectuées sur les factures trouvées dans les données de test.

  • Télécharger toutes les factures .xaml (Download all invoices.xaml) : extrait tous les éléments de la table des factures à l'intérieur de l'application et les renvoie sous forme de DataTable.
  • Télécharger les factures par identifiant fiscal du fournisseur .xaml (Download invoices by vendor tax ID.xaml) : parcourt l'ensemble de la table des factures jusqu'à ce qu'il trouve une facture avec un identifiant fiscal spécifique, qu'il renvoie ensuite. 

• Module de navigation : Contient des workflows qui naviguent à travers les différentes pages de l'application Web

  • Les composants de ce module sont principalement utilisés par les autres workflows de bibliothèque et ne doivent généralement pas être invoqués directement à partir de notre processus principal. Cependant, ils sont marqués comme publiables, car ils peuvent être utiles dans les processus assistés (attended) où nous pouvons souhaiter que le robot navigue vers une page spécifique, puis permette à l'utilisateur d'interagir avec l'application.

• Module Éléments de travail (Work items) : contient les actions qui ont lieu sur les éléments de travail trouvés dans l'application.

  • Télécharger tous les éléments de travail .xaml (Download all work items.xaml) : télécharge tous les éléments de travail dans les données de test.

Processus (Process)

Download process

Le projet principal, AcmeProcess_ObjectRepository, se compose de quatre cas d'utilisation différents. Cela nécessite que l'utilisateur crée des informations d'identification Windows de type générique nommées ACMETest, qui enregistrent le nom d'utilisateur et le mot de passe avec lesquels le robot se connectera à l'application Web ACME.

Les composants de cas d'utilisation de ce processus effectuent diverses tâches à l'aide des multiples composants intégrés à la bibliothèque Composants de l'interface utilisateur ACME.

Lorsque le workflow Principal .xaml (Main.xaml) est invoqué, le robot se connecte à l'application ACME, une boîte de dialogue invite l'utilisateur à sélectionner l'un des cas d'utilisation, puis invoque le workflow correspondant au choix de l'utilisateur :

Testing project

Download testing project

Le projet de test, Test_UiPath.AcmeProcess_ObjectRepository, se compose de cinq cas de test différents qui testent différentes fonctionnalités du processus : connexion/déconnexion, télécharger toutes les factures/télécharger les factures par identifiant fiscal du fournisseur, télécharger les éléments de travail.