Dans Kofax RPA, vous pouvez créer 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.

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. Pour utiliser un robot , vous devez l'appeler 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 les robots 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, consultez Configurer le 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 les robots.

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é.