RPA – Le petit billet technique du développeur RPA n°1



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.



Tout d’abord, 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é Invoke Workflow File 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, 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é Invoke Workflow File 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 et 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 a été 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, afin de résoudre l’exception, 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 Invoke Workflow File a été rencontré sur un processus métier de facturation RPA.


Caractérisation et résolution du message d’exception Invoke Workflow File n°2 :

Cet incident est apparu lors d’une autre mise jour d’un script RPA générique.

Dans ce cas, le script du projet RPA a été correctement adapté à la nouvelle version du script générique. Cependant, cette dernière version n’a pas été intégrée au projet RPA avant sa publication. Cette situation a provoqué une nouvelle exception liée aux arguments définis dans l’activité Invoke Workflow File. Ici, ce n’est pas le type de l’argument qui est en cause, mais sa seule existence qui n’est pas attendue par un script générique en retard d’une version.

Du fait que les montées de version UiPath sont toujours des opérations délicates à gérer et cet incident nous rappelle qu’il faut vérifier les versions des scripts génériques et les autres dépendances avant de publier un projet RPA. Dans ce cas précis, le projet a pu être à nouveau publié après intégration de la bonne version du script RPA générique.

Message d’exception Invoke Workflow File n°3 :

Ce troisième message d’exception Invoke Workflow File a été rencontré sur un processus métier de comptabilité.


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é Invoke Workflow File 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.


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