Le petit billet
du développeur RPA n°2
Le petit billet de l'Oiseau Rare
Ce billet permet de revenir sur les 10 règles essentielles de la gestion d’erreurs RPA, rencontrées sous UiPath. Depuis 4 ans, les développeurs RPA, du Cabinet de Conseil l’Oiseau Rare, développent sur UiPath. Ainsi, dans une recherche d’industrialisation nous avons constitué un ensemble de bonnes pratiques et d’outils pour élaborer nos gestions d’erreurs en RPA.
Article publié par Maxime Debuysschere, Consultant Lead Dev RPA chez l’Oiseau Rare.
10 règles essentielles à la gestion d’erreurs RPA.
Tout d’abord, les facilités de développement des outils RPA comme UiPath permettent à n’importe quel collaborateur motivé d’automatiser une partie de ces tâches. Cette facilité est l’un des grands intérêts de la RPA, (robotic process automation). Elle est à la base de la notion de « Citizen Developer » mise en avant par Uipath.
En effet, le créateur sera capable de faire fonctionner son outil sur son poste sans grande difficulté. Mais, les choses se compliqueront dès qu’il faudra déployer cet outil au bénéfice des autres collaborateurs. Or, il est hautement probable que l’outil RPA devienne instable voire bloque complètement.
C’est dès ces premières tentatives de déploiement que le besoin de l’expertise d’un vrai développeur RPA se fait sentir. Sans cette expertise, les problèmes tendent à se multiplier. Par exemple, ce chef de service qui débarque en demandant pourquoi le traitement n’a pas eu lieu.
La gestion d’erreurs RPA
Finalement, vous l’aurez compris. Nous allons parler de l’un des sujets à la fois sensible et fondamental de la programmation informatique : la gestion d’erreurs RPA.
Dans ce processus, nous avons eu maintes occasions de réfléchir aux fondamentaux sur lesquels construire cette gestion. C’est donc le résultat de cette réflexion que nous vous partageons ici en 10 règles essentielles.
Oui, c’est encore une liste en 10 points ; mais 10 est un chiffre rond et les gens aiment bien les chiffres ronds. Peut-être, un jour, nous présenterons une liste en 42 points, mais seulement si vous nous promettez de la lire en entier.
1. Accepter que ça va planter
Cette première règle est peut-être la plus dure à accepter pour un développeur encore peu aguerri à la gestion d’erreurs. Cependant, comme on dit il n’y a que le premier pas qui coûte.
Respirez un grand coup et répétez après moi : Ça va planter.
Peu importe la qualité du code, un jour quelconque, à une étape quelconque du processus dans une partie quelconque du code pour une quelconque raison, une exception va être lancée. Le robot va être confronté à une erreur ; et si rien n’est prévu, ça va planter.
La règle la plus élémentaire de la gestion d’erreurs est d’accepter que n’importe quel code est susceptible de rencontrer des erreurs. Cette certitude aveugle permet d’être dans le bon état d’esprit pour répondre à la question qui suit naturellement : « que faire ? »
2. Mieux vaut prévenir que guérir
Vous voyez, les exceptions se divisent en deux catégories : celles qui sont attendues et celles qui ne le sont pas. La formule est une lapalissade, mais elle permet d’attirer l’attention sur un point important de la conception d’une gestion d’erreur : l’anticipation.
C’est une étape littéralement non négligeable du travail de développement de chercher à identifier les exceptions les plus susceptibles d’apparaître. Ainsi, il est possible de définir des procédures adéquates pour gérer ces scénarios. En effet, la base de cette stratégie consiste à inspecter chaque section de code en se demandant ce qui pourrait mal se passer. (Petit indice pour répondre à cette question : relisez la règle 1).
Le revers de cette approche est qu’il n’est pas possible d’absolument tout anticiper. Il faut donc préparer un as dans sa manche, une procédure globale de gestion d’erreurs RPA, une procédure pour les capturer toutes. Cette procédure servira pour les exceptions non attendues et garantira un service minimum de la gestion d’erreurs.
3. Try Catch, la pierre angulaire
Aussi élaborée que puisse être une gestion d’erreurs RPA, sa mise en place repose toujours sur une seule activité : Try Catch. UiPath a prévu d’autres outils, comme le Retry Scope ou le Global Exception Handler ; mais le Try Catch est le seul indispensable à n’importe quel processus.
Ce qui ne gâche rien est que le fonctionnement de cette activité est aussi simple qu’efficace
- Une premiere section Try destinée à contenir l’ensemble du code susceptible de rencontrer une exception
- Une deuxieme section Catch destinée à contenir le code à exécuter si une exception apparaît
- Une troisieme section Finally destinée à contenir le code qui sera exécuté quoiqu’il advienne dans les sections précédentes
4. Gérer dans le catch
Avec l’expérience, nous avons pu constater qu’un développeur peut avoir tendance à disperser sa gestion d’erreurs RPA. Autrement dit, une exception est attrapée dans une section Catch, mais les actions associées sont codées dans une séquence qui suit l’activité Try Catch. Et/ou dans les transitions de sortie de l’état contenant l’activité Try Catch. C’est une pratique qui devrait être systématiquement bannie.
Il faut au contraire veiller à concentrer au maximum les éléments de la gestion d’erreur dans les sections Catch. En effet, appliquer cette règle peut compliquer un peu certains développements, mais la lisibilité du code y gagne énormément.
5. Surveiller les angles morts
Aussi bien élaborée que soit une gestion d’erreurs RPA, il est hautement probable qu’elle contienne des angles morts. C’est à dire, des éléments de codes où si une exception apparaît, elle ne pourra pas être gérée. Un exemple simple est le code même de la gestion d’erreurs RPA. Il est complexe de mettre en place une gestion d’erreurs qui se gère elle-même ; et ce n’est pas forcément souhaitable. Tout aussi couramment, la plupart des architectures de machine d’états prévoit des Try Catch seulement à l’intérieur des états, laissant les transitions à découvert.
Il est très important d’identifier les angles morts d’une gestion d’erreur et de prêter une attention particulière au code qu’ils contiennent. Pour reprendre l’exemple des transitions entre états, ces dernières ne devraient jamais contenir d’interactions avec une interface utilisateur, principales sources d’erreurs en RPA.
Si en lisant cette règle vous avez pensé à la règle numéro 1, félicitations ! Vous avez compris le truc de la gestion d’erreurs en RPA et vous gagnez 10 points.
6. Profiter de la propagation verticale
Durant l’exécution d’un robot, une pile d’exécution se crée naturellement via les appels des fichiers de script les uns vers les autres. Dans cette pile, seul l’élément supérieur est réellement en activité, comme les autres attendent que leur appel soit résolu. C’est donc toujours dans cet élément supérieur qu’une exception peut apparaître. Si cette dernière n’est pas attrapée, elle va passer à l’élément inférieur de la pile et continuer à descendre jusqu’à être attrapée. C’est ce qu’on appelle la propagation verticale.
L’une des implications de ce mécanisme est qu’il n’est pas toujours optimal de chercher à gérer une exception le plus localement possible, i.e. au plus haut de la pile. Il arrive qu’un scénario d’exception bien identifié puisse apparaître dans plusieurs endroits du code. Il est alors plus intéressant de cherche une section Catch. Cette section englobe tous ces endroits pour y centraliser la gestion du scénario. Plutôt que de la disperser dans des sections Catch plus localisées. Cette règle est, somme toute, un cas particulier de la factorisation du code.
7. Bien caractériser
L’un des aspects les plus importants de la gestion d’erreurs RPA est l’analyse de l’exception. C’est pourquoi toute procédure de gestion d’erreurs RPA doit commencer par le rassemblement et l’enregistrement d’un maximum de données pertinentes sur l’exception RPA. Faire cela facilite et accélère grandement l’analyse ; et donc l’ensemble du travail de maintenance et de débogage.
Parmi ces données, trois sont primordiales :
- La source de l’exception : l’optimum est le nom de l’activité qui a lancé l’exception.
- Le message de l’exception : véritable point de départ de la compréhension de l’exception.
- Le type de l’exception : Parfois plus parlant que le message lui-même.
A cela s’ajoutent d’autres informations qui dépendent totalement du processus traité et des besoins de l’équipe de maintenance. Un très bon exemple est la capture d’écran, qui permet de voir directement quel était l’état des interfaces au moment où l’exception est apparue. Mais qui peut être contrainte par des impératifs de protection des données.
Dans cette collecte d’information, il peut être tentant de viser l’exhaustivité et de pouvoir dire avec le sourire : « j’ai dépensé sans compter ». Ce serait oublié qu’une bonne information est une information sans superflue ; alors pesez bien l’intérêt des données que vous collectez et pensez bien au RGPD.
8. Apprendre au robot à se relever
L’exception a été attrapée. L’exception a été caractérisée. Que reste-t-il à faire au robot ? Simplement, reprendre le chemin nominal de traitement. Ce point dépend totalement du type d’exception et du processus, mais il est très souvent intéressant de retenter la même étape du même traitement ou de passer à l’étape suivante ou de passer au traitement suivant.
C’est l’une des fonctions principales du script principal et du script de macro-processus de définir l’ensemble des procédures permettant ce retour au chemin nominal.
9. Le cas Terminate Workflow
L’activité Terminate Workflow peut être utilisée pour mettre volontairement fin à l’exécution d’un script dans certains cas. Plus concrètement, l’activité lance une exception d’un type particulier : WorkflowTerminatedException. Son utilisation nécessite donc d’adapter la gestion d’erreur pour attraper et traiter à part ce type particulier d’exception. Ainsi cette activité permet de traiter de situations particulières où on souhaite un traitement différent de la résolution normale du script et de la gestion d’une erreur d’exécution.
10. Les exceptions aux règles métiers
En matière d’exception, UiPath a mis en place un type assez particulier nommé BusinessRuleException dont le lancement doit être prévu dans le code du robot. Cette fonctionnalité est très intéressante. Elle permet de profiter des avantages de la gestion d’erreurs RPA non plus seulement pour des exceptions techniques mais aussi pour des exceptions aux règles métier.
L’utilisation de ce type nécessite de définir des règles de pratique précises. En effet, il peut être tentant de l’utiliser pout toute interruption ou redirection de traitement. Une pratique fortement déconseillée. Au contraire, ce type permet d’inscrire dans le code une distinction claire entre les exceptions du processus (i.e. les cas non passants ou non nominaux) qui ont été intégrés au périmètre d’automatisation. Ainsi que les exceptions au processus qui ne font pas partie du périmètre d’automatisation (ou même qui ne devrait pas être traité par ce proces
Conclusion
Pour conclure, comme dit plus haut, ces 10 règles constituent une sorte b.a.-ba de la gestion d’erreurs RPA. Voyez-les comme les fondations à partir desquelles vous pourrez élaborer des bonnes pratiques et des modèles de gestion d’erreurs adaptés à vos besoins. Un tel travail peut représenter un investissement important. Cependant, le jeu en vaut largement la chandelle. En effet, c’est une étape indispensable pour construire des robots RPA fiables, notamment vis-à-vis des équipes métiers. Pour alléger la charge de maintenance d’une flotte de robots grandissante ; et pour aborder sereinement l’industrialisation et le déploiement à large échelle de vos automatisations.
Cerise sur le gâteau, c’est quand même assez satisfaisant pour un développeur de pouvoir dire que la source de l’erreur n’est pas dans son code lorsqu’on demande pourquoi le traitement n’a pas eu lieu.
Nos expertises en automatisation RPA
L’Oiseau Rare vous propose ses services d’accompagnement pour élaborer une stratégie d’automatisation personnalisée. Nous vous aidons à identifier les processus automatisables, à définir des objectifs clairs, et à évaluer les avantages liés à l’automatisation.
Lead Developper RPA chez SAFRAN
Au sein de la Direction financière de Safran SA, le Département SFS (Safran Financial Services) qui a pour vocation de consolider les résultats de l’ensemble des filiales du Groupe.
Safran SFS a pour objectif d’établir une ‘RPA Factory’ en vue d’automatiser les processus métiers de faible valeur ajoutée. Dans ce cadre, j’ai conçu et mis en place des Assistants Virtuels (AV) pour Safran SFS, tout en assurant la supervision et le soutien du développement de l’outil RPA.
Besoin d'accompagnement ?
Ne laissez pas les obstacles techniques entraver votre progression. Contactez-nous aujourd’hui pour discuter de vos besoins spécifiques et découvrez comment notre expertise en projet RPA peut transformer votre besoin technologique en réalité !