
Article publié par Maxime Debuysschere, Consultant Lead Dev RPA chez l’Oiseau Rare.
Ce billet permet de revenir sur 3 messages d’exception Invoke Workflow File souvent rencontrés sur UiPath. Depuis 4 ans, les développeurs RPA, du cabinet de conseil l’Oiseau Rare, développent sur UiPath. De ce fait, ils ont eu l’occasion de gérer de nombreux messages d’erreurs et de traiter des incidents techniques.
l’activité Invoke Workflow File, qu’est-ce que c’est ?
Pour commencer, l’activité Invoke Workflow File fait partie des activités utilisées presque systématiquement dans un projet RPA, Robotic Process Automation. De ce fait, son fonctionnement est aussi simple qu’important.
L’activité Invoke Workflow File permet à une page de script d’appeler une autre page afin qu’elle exécute les actions pour lesquelles elle a été programmée.
L’activité permet aux deux pages de script d’échanger des données entre elles.
De ce fait, cette activité est donc la brique fondamentale de la modularité des scripts RPA UiPath. C’est une bonne pratique essentielle, à tout développement informatique..
Comment paramétrer l’activité Invoke Workflow File ?
Le paramétrage de l’activité Invoke Workflow File ne nécessite que deux étapes.
- 1ère étape : Fournir l’emplacement du script « appelé ».
- 2ème étape : L’activité remonte automatiquement les arguments du script « appelé » qu’il ne reste plus qu’à associer aux valeurs, variables ou arguments du script « appelant ».


Concentrons-nous sur chacune de ses trois exceptions.
Tout d’abord, partons des messages d’exception produit par Invoke Workflow File pour les analyser dans leur contexte. Le but est de vous proposer une résolution applicable dans tous les projets RPA, et notamment les projets sur UiPath.
Message d’exception Invoke Workflow File n°1 :
Ce premier message d’exception est rencontré sur un processus métier de gestion RPA.

Caractérisation et résolution du message d’exception Invoke Workflow File n°1 :
Ce premier incident a eu lieu sur la version 2017 de la plateforme UiPath. Nous l’avons de nouveau croisé sur la version 2019 sur UiPath.
Effectivement, avant l’implémentation des bibliothèques, les fonctionnalités réutilisables d’un projet RPA à un autre étaient enregistrées dans des scripts dits « génériques » et gérées manuellement.
Un de ces scripts génériques venait d’être lourdement modifié, avec plusieurs changements d’arguments. Pour déployer cette nouvelle version, il restait à adapter, publier et tester les projets RPA qui utilisaient ce script générique. En fait, cela revenait à la totalité des projets RPA gérés par l’équipe de développeurs RPA.
De plus, du fait de contraintes de l’environnement de travail, les changements des arguments ont dû être intégrés manuellement dans les activités Invoke Workflow File des codes des projets RPA.
Cette manipulation nécessite une attention redoublée sur le paramétrage des arguments, car elle est source de nouvelles exceptions potentielles.
Cela fut le cas dans l’un des projets RPA où un argument nommé « a_stopRobot » a été mal paramétré.
Pour ces raisons, dans ce cas spécifique, il faut corriger le type de l’argument concerné, plus précisément remplacer le type « String » par « Boolean ».
Message d’exception Invoke Workflow File n°2 :
Ce second message d’exception est rencontré sur un processus métier de facturation RPA.

Caractérisation et résolution du message d’exception Invoke Workflow File n°3 :
Cet incident est arrivé dans un contexte complètement différent des deux précédents. En premier lieu parce qu’il a eu lieu sur la version 2018.4 de la plateforme UiPath. Cet incident a été particulier à caractériser pour plusieurs raisons :
Notamment le fait que, le type de l’exception (XamlObjectWriterException) se rencontre rarement et n’est pas très explicite de prime abord.
L’erreur ne pouvant pas venir de l’activité elle-même, la première étape est la localisation de la véritable source de l’exception. Notons que celle-ci se trouve dans le script appelé par l’activité Invoke Workflow File qui contient une activité Click Image. Cette activité présente une propriété « Accuracy » dont la valeur est la valeur décimale par défaut prévue par Studio : 0.8.

h
Toutefois, localiser la source ne répond pas à toutes les questions. En particulier, pourquoi la valeur par défaut d’une propriété provoque une exception ? Le reste de l’explication se trouve dans le fichier principal du projet RPA.
En effet, l’une des premières séquences de l’exécution contient une modification des paramètres culturels de l’environnement d’exécution. Des paramètres par défaut (autrement dit américains) l’environnement passe aux paramètres français ce qui impacte les outils de conversion utilisés par le robot qui n’acceptent plus le texte « 0.8 » comme ayant un format valide pour une conversion en nombre décimal.
La résolution de ce problème nécessite quelques recherches sur les méthodes de conversion.
En effet, le Studio va refuser que la valeur 0.8 soit remplacée directement par 0,8 ; du fait de ses propres paramètres culturels. Il faut donc une expression qui fonctionne dans les deux paramètres culturels (Studio et exécution). Au final, nous avons retenu l’expression Convert.ToDouble (0.8) qui permet de résoudre l’exception.
Vous savez à présent comment résoudre certains messages d’exception produit par l’activité Invoke Workflow File, activité utilisée presque systématiquement dans un projet RPA avec la plateforme UiPath
Pour en savoir plus, consulter le petit billet du Dev RPA n°2 !