Automatisation d’UI
Pour que les robots puissent interagir avec les interfaces utilisateurs, plusieurs outils sont mis à disposition.
La méthode de fonctionnement idéale est d’installer le robot sur le poste sur lequel les applications seront utilisées, pour permettre au robot d’interagir directement avec l’API de messages Windows ou l’API de l’application via le plugin UiPath.
Pour les applications utilisant l’interface utilisateur, il est nécessaire que la session Windows soit ouverte.
Dans le cas où l’installation du robot n’est pas possible, l’utilisation de Citrix, VNC ou RDP, UiPath fournit des outils avancés qui permettront d’exploiter un moteur de reconnaissance visuel pour interagir avec les interfaces. Bien que ces outils soient efficaces, il est toujours préférable que le robot interagisse directement avec l’application pour des raisons de fiabilité et de performance.
Les méthodes d’entrées
Il existe 3 méthodes d’entrée pour les applications UiPath, chaque méthode à ses avantages et inconvénients et certaines sont imposées par l’activité.
L’activité à privilégier est Simulate, car c’est celle qui apporte le plus d’avantages, mais en fonction des situations il sera nécessaire d’en choisir une autre. Notamment si l’activité doit fonctionner en background (pendant qu’un utilisateur travaille sur le poste), l’application est utilisée à distance (via Citrix) ou l’activité doit générer des raccourcis clavier (Ctrl+Shift).
Dans l’image ci-dessous on peut voir une partie des paramètres de l’activité « Clic ».
La méthode qui doit être préférée par défaut.
Cette méthode utilise la technologie de l’application pour générer les évènements ce qui garantit une très bonne compatibilité et une grande vitesse d’exécution.
Avantages
- Bonne compatibilité Web
- Background
- Très rapide
- Fonction Auto Empty Field
Inconvénients
- Peut-être incompatible avec certaines applications.
- Pas de support des Hotkeys
Cette méthode utilise l’API bas niveau Windows pour générer les évènements.
Avantages
- Bonne compatibilité
- Background
- Support des HotKeys
Inconvénients
- Vitesse moyenne
- Pas de fonction Auto Empty Field
C’est la méthode active par défaut si aucune des méthodes précédentes n’est sélectionnée.
Cette méthode utilise le driver matériel pour générer les évènements, c’est la méthode à n’utiliser qu’en dernier recours, car elle monopolise le poste de travail en bloquant l’accès à la souris et au clavier. Ça sera la méthode à utiliser pour interagir avec une interface distante de type Citrix.
Avantages
- Excellente compatibilité
- Support des hotkeys
Inconvénient
- Pas de Background
- Vitesse moyenne
- Pas de Auto Empty Fiels
Méthodes de ciblages
Lorsque le robot doit interagir avec un élément d’interface, il existe plusieurs méthodes pour permettre au robot de l’identifier. La méthode la plus fiable pour identifier un élément est le « sélecteur », mais lorsqu’il n’est pas possible d’utiliser ceux-ci, comme lors d’un accès Citrix ou un élément d’interface sans identifiant fixe, il faudra utiliser un autre repère comme les ancres ou une image.
Selectors
Le paramétrage du sélecteur se fait dans le panneau « Properties puis Target-> Selector »
Le sélecteur prend la forme d’une série de balises XML. La première, la racine, identifie l’application et la ou les suivantes, les éléments permettant d’identifier le champ.
Exemple :
<HTML app=’chrome.exe’ title=’Produits – cravatec’ />
<webctrl parentid=’menu-item-53′ tag=’A’ />
Dans cet exemple, la racine « html » identifie qu’on va travailler sur un navigateur, Chrome, comme indiqué dans le paramètre « app », le titre de la fenêtre est spécifié par le paramètre « title ».
Dans l’éventualité où la fenêtre chrome n’est pas ouverte ou le titre de la page est différent, le sélecteur ne trouvera pas le champ.
Le nœud « webctrl » identifie un champ dans une application web, de la même façon, le paramètre « tag » fait référence à une balise dont le parent possède un id = menu-item-53.
Dans cet exemple toutes les informations sont renseignées dans l’activité (application et champ), le sélecteur est dit « complet ». Lorsque plusieurs actions doivent s’enchainer dans la même page ou la même application, il est possible d’utiliser un conteneur qui permettra de définir l’application puis toutes les activités présentes dans ce conteneur hériteront du nœud racine, seuls les nœuds suivants seront précisés. Dans ce cas le sélecteur est dit « partiel ».
Si on ouvre le sélecteur de l’activité « Click » avec l’éditeur de sélecteur, on peut voir que la ligne du nœud HTML est grisée ainsi que les champs « app » et « title », il n’est possible de modifier ces informations que dans l’activité « Attach Browser ».
Il est possible de modifier le sélecteur de 3 manières :
- Directement dans le champ selector, en modifiant la chaine de caractère
- L’Éditeur de sélecteur
- UI Explorer
UI Explorer
Cet outil permet de naviguer dans l’arborescence de l’application pour paramétrer manuellement le sélecteur.
L’outil UI Explorer est disponible depuis l’activité ou depuis l’éditeur de sélecteur.
UI Explorer permet de consulter l’ensemble des paramètres d’un champ et de voir leur valeur à l’instant T. Il est ainsi possible d’inclure dans le sélecteur un parent aux champs sélectionné ou de sélectionner un champ plus précis non accessible à la souris.
Dans la partie en bas à droite il est possible d’utiliser le clic droit dans un champ pour afficher le menu de sélection/Création de variables ou arguments qui permettra de rendre le sélecteur dynamique.
Sélecteurs dynamiques
Il est possible d’utiliser des caractères génériques (ou wildcards) pour permettre au sélecteur de fonctionner même en cas de changement dans l’interface, souvent gérer les problématiques de changement de titre de fenêtre.
- « * » : ignorer tous les caractères
- « ? » : ignorer un caractère.
Comme on peut le voir sur ces captures, les titres de fenêtres sont différents.
Pour permettre à notre sélecteur de fonctionner dans tous les cas sur ce site nous devrons modifier le sélecteur ainsi :
De la même manière, il est possible de remplacer une partie de la recherche par le contenu d’une variable ou d’un argument.
Par exemple nous savons dans ce cas que le « parentid » est fixe
- Bouton « Boutique » parentid = 53
- Bouton « Panier » parentid = 54
Il est alors possible de créer un argument dans le worflow et modifier le sélecteur, pour que le bouton cliqué soit passé en paramètre au workflow.
Méthodes de sorties
Les méthodes de sorties concernent les activités qui extraient du texte d’un élément d’interface utilisateur. Comme les méthodes d’entrées, chaque méthode de sortie à ses avantages et inconvénients qu’il s’agira d’évaluer. Chaque activité à sa propre méthode de sortie.
La méthode qui doit être préférée par défaut via l’activité « Get Full Text ».
Cette méthode est la plus rapide et la plus précise, elle ne permet cependant pas d’extraire la position du texte à l’écran.
Avantages
- Très rapide
- Très précis
- Background
- Extraction des textes cachés
Inconvénients
- Pas de position
- Pas de support Citrix
Cette méthode est compatible avec les applications qui utilisent des interfaces graphiques sous Windows via l’activité via l’activité « Get Visible Text », dans la mesure où elle utilise l’API Windows pour extraire les informations visibles à l’écran elle ne permet pas d’extraire les textes cachés, mais peut retourner la couleur et les coordonnés des éléments de texte.
Avantages
- Rapide
- Très précis
- Extraction de la couleur et position des éléments
Inconvénients
- Pas de background
- Pas d’extraction des textes cachés
- Pas de support Citrix
La méthode OCR permet d’extraire du texte depuis une image, un document scanné ou une application Citrix grâce à l’activité « Get OCR Text », c’est la moins précise et rapide des techniques d’extraction de texte.
Avantages
- Relativement précis
- Extraction de la couleur et position des éléments
- Support Citrix
Inconvénients
- Très lent
- Pas de background
- Pas d’extraction de texte caché