Conception de workflow

Schémas de mise en page

UiPath propose quatre diagrammes pour intégrer des activités dans une structure active lors du
développement d'un fichier de workflow :

• Diagramme de flux (Flowchart)
• Séquence (Sequence)
• Machine d'état (State Machine)
• Gestionnaire global d'exceptions

Séquence (Sequence)

Les séquences présentent une représentation linéaire simple descendante et sont mieux adaptées aux scénarios simples lorsque des activités se suivent. Par exemple, elles sont utiles dans UI Automation, lorsque la navigation et la saisie nécessitent un clic/une combinaison de touches à la fois. Étant donné que les séquences sont faciles à assembler et à comprendre, elles représentent la mise en page préférée pour la plupart des workflows.

Diagramme de flux (Flowchart)

Les organigrammes offrent plus de flexibilité pour connecter les activités et ont tendance à présenter un workflow de manière bidimensionnelle. En raison de leur forme libre et de leur attrait visuel, les organigrammes sont mieux adaptés pour présenter les points de décision au sein d'un processus. Les flèches qui peuvent pointer n'importe où ressemblent beaucoup à l'instruction de programmation GoTo non structurée et rendent donc les workflows volumineux sujets à un entrelacement chaotique des activités.

Machine d'état (State Machine)

Machine d'état (State Machine) est une structure plutôt complexe qui peut être considérée comme un organigramme avec des flèches conditionnelles, appelées transitions. Elle permet une représentation plus compacte de la logique et elle s'applique à un diagramme de processus standard de haut niveau de modèles de processus métier transactionnels.

Gestionnaire global d'exceptions

Le Gestionnaire d'exceptions est conçu pour être utilisé dans des projets d'automatisation à petite et grande échelle, pour identifier les erreurs d'exécution et surtout, pour déterminer le comportement du workflow lorsqu'une telle erreur se produit. Si une erreur d'exécution est rencontrée lors du débogage, le Gestionnaire global d'exceptions peut être défini pour intervenir et permettre de vérifier le comportement du workflow conformément aux options auparavant définies dans le Gestionnaire d'exceptions.

Choix

Les décisions doivent être appliquées dans un workflow pour permettre au Robot de réagir différemment dans différentes conditions de traitement de données et d'interaction de l'application. Le choix de la représentation la plus appropriée d'une condition et de ses branches suivantes a un fort impact sur la structure visuelle et la lisibilité d'un workflow.

Activité Si (If)

L'activité If fractionne une séquence verticalement et est idéale pour des branches linéaires courtes et équilibrées. Les défis se présentent lorsque d'autres conditions doivent s'enchaîner de manière Si… Sinon si (If… Else If), surtout lorsque les branches dépassent la taille d'écran disponible en largeur ou en hauteur. En règle générale, les instructions If imbriquées doivent être évitées pour garder le workflow simple/linéaire.

Décision de flux (Flow Decision)

Les mises en page de l'organigramme sont idéales pour présenter une logique métier importante et les conditions connexes, telles que les instructions Si (If) ou les constructions Si...Sinon si (If… Else If) imbriquées. Il existe des cas où l'apparence d'un organigramme peut sembler correcte même à l'intérieur d'une séquence.

Opérateur Si (If)

L'opérateur Si (If) de Visual Basic est très utile pour des conditions locales mineures ou le calcul de données. Il peut parfois réduire tout un bloc à une seule activité.

Activité Basculer (Switch)

L'activité Switch peut être parfois utilisée conjointement avec l'opérateur If afin de simplifier et compacter une cascade Si… Sinon si (If… Else If) avec des conditions et des activités distinctes par branche.

Commutateur de flux (Flow Switch)

L'activité Flow Switch sélectionne le nœud suivant en fonction de la valeur d'une expression. Flow Switch peut être considérée comme l'équivalent de l'activité Switch procédurale dans les organigrammes. Elle peut correspondre à plus de 12 cas en démarrant d'autres connexions à partir du même nœud Switch.

Données

Les données sont proposées sous deux formes lorsqu'il s'agit de la visibilité et du cycle de vie : arguments et variables. Tandis que la fonction des arguments consiste à transmettre des données d'un workflow à un autre, les variables sont liées à un conteneur à l'intérieur d'un fichier de workflow unique. Elles peuvent être uniquement utilisées localement.

Étendue de variable

Contrairement aux arguments, qui sont disponibles partout dans un fichier de workflow, les variables sont uniquement visibles à l'intérieur du conteneur où elles sont définies, appelé étendue.

Les variables doivent être conservées dans l'étendue la plus profonde pour réduire l'encombrement du panneau Variables (Variables) et pour afficher uniquement, en saisie semi-automatique, les éléments pertinents à un point spécifique du workflow.

Remarque : si deux variables avec le même nom existent, bien que nous le déconseillions vivement, celle définie dans l'étendue la plus profonde a priorité.

Arguments

N'oubliez pas que lors de l'invocation de workflows avec l'option Isolé (Isolated) (qui démarre l'exécution du workflow dans un processus système distinct), seuls les types sérialisables peuvent être utilisés comme arguments pour transmettre des données d'un processus à un autre. Par exemple, les objets Chaîne sécurisée (SecureString), Navigateur (Browser) et Connexion de terminal (Terminal Connection) peuvent franchir en toute sécurité la frontière inter-processus.

Valeurs par défaut

Les variables et arguments d'entrée peuvent être initialisés avec des valeurs statiques par défaut. Ceci s'avère très utile lors du test individuel de workflows, sans nécessiter de données d'entrée réelles à partir de l'appel de workflows ou d'autres sources externes.

Conventions d'affectation de noms

Des noms significatifs doivent être attribués aux fichiers de workflow, activités, arguments et variables afin de décrire avec précision leur utilisation tout au long du projet.

Les projets doivent comporter des descriptions significatives, car ils s'affichent également dans l'interface utilisateur d'Orchestrator et peuvent être utiles dans les environnements multiutilisateurs.

Pour améliorer la lisibilité, les noms de variables et d’arguments doivent également s’aligner sur une convention d'affectation de noms :

• Casse Snake : First1_Name2, first_name2,
• Casse mixte (majuscule ou minuscule) : FirstName, lastName,
• Casse Pascal : First1Name2, First1Name,
• Casse Kebab : First-Name, First-Name1.

Les noms d'arguments doivent comporter un préfixe indiquant le type d'argument, tel que in_DefaultTimeout, in_FileName, out_TextResult, io_RetryNumber.

Les noms d'activités doivent refléter de façon précise l'action effectuée, telle que Cliquer sur le bouton Enregistrer (Save). Conservez la partie du titre qui décrit l'action (Cliquer (Click), Saisir dans (Type Into), Élément existe (Element Exists), etc.).

Excepté pour Principal (Main), tous les noms de workflows doivent contenir le verbe décrivant la fonction du workflow, par exemple, Extraire les données de transaction (GetTransactionData), Traiter la transaction (ProcessTransaction), Prendre une capture d'écran (TakeScreenshot).

Commentaires et annotation

L'activité Comment et les Annotations (Annotations) doivent être utilisées pour décrire de manière plus détaillée une technique ou les particularités d'un certain comportement d'interaction ou d'application. N'oubliez pas que d'autres personnes peuvent, à un moment donné, tomber sur un projet robotique. Vous pouvez ainsi les aider à mieux comprendre le processus.