Présentation de la construction de robots

Dans Kofax RPA, créez des robots qui peuvent automatiser les interactions avec un site web, ainsi que les processus de travail impliquant des applications Windows et Java sur vos ordinateurs en réseau. Design Studio dispose d'un langage de workflow et des étapes dédiées à cet effet. Pour les descriptions des types de robot dans Design Studio, voir Robots.

Robots

Le workflow d'un robot est une séquence d'étapes exécutées l'une après l'autre. Les étapes modélisent la manière dont un utilisateur interagit avec l'application qui est automatisée.

Un robot peut être exécuté en mode autonome ou appelé à partir d'un Robot à Moteur Basique .

Robots en mode autonome

Créez et exécutez des robots autonomes à l'aide de l'Éditeur de robot. Voir également Modifier le robot et Barre d'outils.

  • Dans Design Studio, créez et exécutez des robots de type d'entrée simples et complexes.

  • Dans la Management Console, mettez en file d'attente et exécutez des robots de type d'entrée complexe.

    Les robots de type d'entrée simple ne peuvent pas être exécutés en mode autonome sur la Management Console.

  • Si vous avez un robot qui a été précédemment appelé à partir d'un Robot à Moteur Basique et que vous souhaitez l'exécuter de manière autonome, le seul moyen d'obtenir une sortie consiste à insérer des étapes Valeur de sortie.

Robots appelés depuis un Robot à Moteur Basique

Appelez un robot depuis un Robot à Moteur Basique avec une étape d'activité dédiée nommée Appeler le robot.

Un Robot à Moteur Basique peut contenir plusieurs étapes Appeler le robot, chacune ayant son propre workflow. Un robot unique peut être réutilisé par les Robots à Moteur Basique, ce qui permet de gagner beaucoup de temps lorsque vous travaillez sur plusieurs robots en même temps. Le robot avec une étape Appeler le robot peut être exécuté comme tout autre robot Kofax RPA à partir d'une planification, via l'API, via des Kapplets ou manuellement pendant le développement ou les tests.

Workflow

Le workflow est modifié dans Design Studio. Dans Design Studio, vous pouvez voir une vue du robot et les applications en cours d'automatisation, ainsi que les informations sur l'état du robot et une barre d'outils dédiée avec des boutons pour contrôler le robot manuellement. Voir Modifier le robot pour plus d'informations.

Dans le menu, le bouton Aide est disponible et comprend des liens vers la documentation correspondante et les Guides de mise en route qui vous accompagnent tout au long du processus de création d'un robot.

Étapes

Les étapes sont les éléments de base d'un workflow dans un robot. Dans le robot, toutes les étapes ont un point d'entrée et un point de sortie, à l'exception de quelques étapes qui n'ont pas de point de sortie. Certaines étapes sont simples et n'exécutent qu'une seule activité, comme déplacer une souris ou appuyer sur une touche. D'autres étapes, appelées étapes composites, peuvent contenir des étapes supplémentaires. Les étapes composites sont utilisées pour regrouper les étapes qui vont ensemble ou pour gérer le branchement et d'autres moyens de contrôler le déroulement de l'exécution. Pour la liste complète des étapes, consultez Étapes de robot.

Les étapes sont généralement granulaires et traitent de petites tâches. Par exemple, il n'existe pas de traitement des erreurs inhérentes à chaque type d'étape. Au lieu de cela, il existe des étapes spécifiques pour traiter les erreurs pendant l'exécution.

Dispositifs

L'un des objectifs d'un robot est le contrôle automatisé des applications. Les applications s'exécutent sur des dispositifs (ordinateurs, serveurs ou machines virtuelles) qui peuvent être accessibles à distance via un réseau. Un robot exécute une automatisation en se connectant au service Desktop Automation qui s'exécute sur des dispositifs distants, sauf si le dispositif exécute un terminal ou un autre pilote intégré, auquel cas il s'agit d'une connexion directe depuis le robot. Pour plus d'informations sur la gestion des dispositifs et la configuration des agents, voir le Kofax RPAGuide du Desktop Automation Service.

Arborescence d'application

Kofax RPA propose plusieurs façons de remplir l'arborescence d'application. Par défaut, Kofax RPA détecte le type d'application avec lequel le robot travaille (comme une application Windows, un terminal, un navigateur intégré, etc.) et forme automatiquement l'arborescence de l'application. Pour certaines applications Windows, Kofax RPA fournit un support étendu. Par exemple, lorsque vous travaillez avec Microsoft Edge en mode Internet Explorer dans Design Studio, Kofax RPA active le support étendu d'Internet Explorer pour récupérer l'arborescence DOM (Document Object Model), car elle fournit un résultat plus précis dans l'arborescence d'application.

Pour distinguer les attributs que Kofax RPA reçoit directement des applications et les attributs que Kofax RPA ajoute, un ensemble d'« attributs dérivés » est fourni. Cela permet d'éviter les conflits de noms entre les différents attributs. Kofax RPA ajoute la zone de délimitation (x, y, largeur, hauteur) comme attributs dérivés. Les attributs dérivés sont affichés dans l'arborescence avec le préfixe « der_ » et peuvent être utilisés dans les localisateurs et pour l'extraction.

Le tableau suivant répertorie et décrit les attributs dérivés qui peuvent être utilisés dans l'arborescence d'application.

Attribut dérivé Classe Description

der_x

Général

Coordonnée X du coin supérieur gauche de l'élément.

der_y

Général

Coordonnée Y du coin supérieur gauche de l'élément.

der_width

Général

Largeur de la zone de délimitation de l'élément.

der_height

Général

Hauteur de la zone de délimitation de l'élément.

der_tree_mode

Général

Spécifie le mode d'arborescence qui définit la façon de remplir l'arborescence d'application.

Utilisez « ISA » pour les arborescences générées par ISA, « Windows » ou « Aucune »pour les arborescences DAS ou « Auto » pour les autres pilotes.

der_original_node_name

Général

Spécifie le nom du nœud dans l'arborescence, dérivé de l'entité qu'il décrit. Si ce nom n'est pas conforme à XML, il est normalisé et le nom dérivé d'origine est passé comme valeur de cet attribut.

der_index

Vue tableau

Spécifie l'index de colonne.

Nous vous recommandons de ne pas utiliser cet attribut dérivé dans les localisateurs. Les valeurs de cet attribut sont susceptibles de changer entre les versions ou peuvent être générées sur la base de sources dynamiques.

Par exemple, la source possible de ces champs est la sortie des requêtes SQL (et des procédures enregistrées) qui peut être modifiée à tout moment par l'utilisateur ou son administrateur de base de données.

der_rpa_type

Vue tableau

Spécifie le type de données RPA correspondant le mieux au type de données dans la base de données.

Nous vous recommandons de ne pas utiliser cet attribut dérivé dans les localisateurs. Les valeurs de cet attribut sont susceptibles de changer entre les versions ou peuvent être générées sur la base de sources dynamiques.

der_rendered

CEF

Définit la valeur « o » (pour « oui ») lorsque l'élément est affiché sur la page.

der_isOffscreen

CEF

A la valeur « true » lorsque l'élément n'est pas visible sur l'écran. Il est nécessaire de faire défiler la page pour voir l'élément.

der_isa

CEF

Définit la valeur « o » (pour « oui ») lorsque l'élément est généré par ISA.

der_value

CEF

Utilisé pour les éléments d'entrée « email », « text », « number », « range », « tel », « time », « url », « search », « date », « datetime-local », « week », « color », « month » et « textarea ».

der_checked

CEF

Utilisé pour les éléments d'entrée « case d'option » et « case à cocher ». Peut être « vrai » ou « faux », selon que l'élément est sélectionné ou désélectionné.

der_visible

Windows

Utilisé pour les éléments graphiques Windows natifs. Peut être « vrai » ou « faux », selon que l'élément est sélectionné ou désélectionné.

der_subdriver

Windows

Spécifie le sous-pilote Windows qui a généré la sous-arborescence. Les valeurs possibles sont « excel », « ie », « sap » ou « java ».

der_SubWindow

Windows

Indique que la sous-arborescence d'une fenêtre Microsoft Edge en mode Internet Explorer est générée à partir d'un composant externe. Les valeurs possibles sont « Silverlight » et « JavaApplet ».

der_handle

E-mail

Référence interne utilisée pour identifier l'e-mail.

Nous vous recommandons de ne pas utiliser cet attribut dérivé dans les localisateurs. Les valeurs de cet attribut sont générées dynamiquement.

der_is_big_value

Base de données

Définit sur « vrai » si la colonne est du type de base de données BLOB ou équivalent.

Vous pouvez désactiver le support d'application étendu si vous rencontrez des problèmes pour travailler avec une application donnée.

Robots comparés aux Robots à Moteur Basique

Kofax RPA a été conçu à l'origine pour accéder au HTML à une époque où les pages HTML étaient essentiellement statiques. Dans ce cas, l'état de l'application (page web) peut être suivi en interne dans le robot. En revanche, les robots sont conçus pour automatiser les nouveaux sites web dynamiques et les applications distantes où l'état réside dans l'application. Dans ce cas, l'état est extérieur au robot.

L'exécution des étapes dans les robots s'effectue uniquement vers l'avant. Lors de l'automatisation d'un ordinateur distant, l'état de l'exécution se trouve sur le dispositif distant et il n'est pas possible de l'annuler en reculant dans le workflow, sauf pour un groupe d'étapes Extraire la valeur et Convertir une valeur. Par conséquent, lors de la conception de votre workflow, les étapes nouvellement insérées ne sont pas exécutées tant que vous n'avez pas explicitement choisi de le faire dans Modifier le robot.

Le branchement, tel qu'il est conçu dans les Robots à Moteur Basique, n'existe pas dans les robots. Il ne se produit que dans le cadre des étapes composites.

Le branchement ne se produit que dans le cadre des étapes composites, telles que Conditionnel. Les branches sont des branches alternatives, de sorte qu'une seule branche est choisie lorsqu'un workflow est exécuté. Cela diffère des Robots à Moteur Basique où les branches sont exécutées séquentiellement les unes après les autres, et l'état est inversé au début de chaque branche.

Dans les robots, le traitement des erreurs diffère, car il n'est pas spécifié pour chaque étape. Au lieu de cela, une étape Tentative-Récupération capture explicitement les erreurs survenant dans sa portée et définit comment les traiter.

En général, lors de la conception d'un robot, pensez à la manière dont un utilisateur interagit avec l'interface utilisateur de l'application que vous automatisez. Par exemple, si vous devez taper du texte dans le champ de texte, cliquez d'abord sur le champ et insérez ensuite une étape qui tape le texte.

Les robots possèdent des fonctionnalités qui permettent au concepteur de robots de concevoir l'automatisation pour évaluer l'état externe de l'application et réagir de manière appropriée. Par exemple, un clic sur un bouton peut être fait pour attendre que le bouton apparaisse. Une étape peut également permettre de détecter qu'une application est déjà lancée, afin d'éviter de lancer une autre instance. Lorsque vous concevez le workflow d'un robot, des gardes et des localisateurs sont utilisés pour attendre des états spécifiques de l'application, garantissant que le robot trouve les éléments requis et interagit avec eux normalement. Les gardes sont décrits dans les Choix contrôlé et les localisateurs sont décrits dans Localisateurs.

Voir Mise en route pour commencer à automatiser des processus et Étapes de robot pour la liste des étapes d'activité.