Avec les logic app Azure, la gestion d’erreurs (comme le développement d’ailleurs), est un peu différent de ce que nous utilisons avec les langages traditionnels. Cet article est justement à propos des composants, options et comportements offerts par les logic apps Azure pour gérer les erreurs.
Avant d’aller plus loin, je voudrais, en deux mots, préciser les types d’erreurs que nous rencontrons en général. J’ai toujours fait la différence entre les erreurs « gérées » et les erreurs « non gérées ». Quel que soit le langage de développement (C#, JAVA…), nous utilisons les mêmes concepts : des blocs de type try/catch, des exceptions typées… Avec les logics apps, nous devons oublier ces concepts pour s’en approprier d’autres.
La prise en compte des erreurs est toujours une partie importante des flux que nous concevons. Nous sommes tous dans le souci d’être alertés lorsqu’une exception arrive sur une de nos applications. Aussi ingénieux que vous soyez, il y aura toujours des cas d’erreurs non prévus et par conséquent non gérés . Les applications Windows, ASP.NET, WCF… tous, donnent accès à un gestionnaire permettant de capter ces erreurs de manière centralisée. Mais, les logic apps ne le permettent pas. Rassurez-vous, il y a un moyen de gérer ces erreurs néanmoins.
Rien de mieux que d’illustrer ces concepts par un exemple. Nous allons donc imaginer un flux simple déclenché par un appel http. Lorsque que je conçois un nouveau flux, je commence toujours par ajouter 2 scopes. Le premier permet de piloter le flux, alors que le second est utilisé pour gérer les erreurs.
Le scope d’erreur est dédié à réaliser les traitements permettant de prendre en compte l’erreur. Par exemple on peut envoyer une notification mail aux utilisateurs finaux ou aux administrateurs pour les prévenir. Si vous utilisez Azure service bus pour gérer la messagerie d’applications, vous pouvez par exemple pousser un message extrait vers la dead letter de votre queue Service bus. Jetez un œil sur l’artcile suivant à propos de la fiabilisation des logics app Azure avec Service bus.
Dans notre scénario, n’oubliez pas que le flux est déclenché par une requête http. Il faut donc absolument que notre processus retourne une réponse http. Ajoutez simplement une shape « response » dans le scope de gestion d’erreurs pour retour un code http adapté.
Maintenant, pour que le scope d’erreur ne se déclenche que lorsque une exception arrive, nous devons définir les options d’exécution de la shape. Utilisez les trois points (…) en haut à droite de la shape et cliquez sur le lien « configure run after ».
C’est assez simple d’obtenir l’effet souhaité. Cochez les cases « has failed et has timed out ». Dorénavant, notre gestionnaire d’erreur ne s’exécutera que lorsqu’une exception survient dans le flux.
Dans le cas où vous avez besoin de gérer des erreurs précises avec un traitement précis, vous devez utilisez les mêmes fonctionnalités.
Supposons que notre processus consiste en l’appel d’une fonction Azure suivi d’une insertion dans une base de données. Ci-dessous, le processus nu de toute gestion d’exception :
Je suis d’accord, c’est excessivement simple ! Mais mon objectif est de discuter de la gestion des erreurs. Donc je vous laisse imaginer que la suite du processus nécessite d’autres traitements (d’autres shapes). De mon côté, je me focalise sur la gestion de l’erreur : je dois réaliser un traitement spécifique si jamais l’appel de la fonction Azure ne fonctionne pas, et bien entendu, je ne dois rien enregistrer en base de données.
J’ai juste ajouté 3 connecteurs entre l’appel de la fonction Azure et la commande SQL :
Pour finaliser le paramètrage de notre gestion d’erreur il faut :
Pour réaliser cette dernière étape, nous configurons notre logic app comme suit :
Gardez toujours à l’esprit que, par défaut, un connecteur est exécuté si le connecteur précédent s’est terminé avec succès. Donc, si nous configurons le connecteur « send error mail shape » pour qu’il ne s’exécute que si le connecteur précédent est en erreur alors, les connecteurs « Reply » et « Terminate » vont aussi s’exécuter. Donc ces trois étapes s’exécuteront s’il y a une erreur. Afin d’assurer que l’insertion SQL ne s’exécute que s’il n’y a pas d’erreur sur la fonction Azure, il faut préciser les conditions d’exécutions comme définit dans la capture (si la shape précédente est ignorée). Effectivement, si le connecteur terminate est ignoré, cela signifie qu’il n’y a pas eu d’erreur et qu’il faut insérer les données en base.
Lorsque vous obtenez une erreur, vous voudrez toujours voir le détail de l’erreur. Par habitude, j’utilise le résultat d’exécution de mes logic apps et je recherche l’étape en erreur. Vous pouvez obtenir l’ensemble du résultat d’exécution de votre processus en utilisant la variable « results » qui est un tableau. Utilisez cette ligne de code pour retrouvez ce résultat : « @results(‘Business_scope’) » (Business_scope est l’identifiant de mon scope principal). Si vous voulez avoir des informations uniquement sur la shape en erreur, et bien vous devrez parser ce résultat et retrouver le connecteur dont l’état est en erreur, par exemple à l’aide d’une fonction Azure.
Finalement, vous voudrez peut être afficher des informations sur les éventuelles erreurs sur le portail Azure. Je ne pourrais que vous conseiller de lire le post d’un de mes collègues à ce sujet : Afficher des résultats contextuelles résultant de votre logic app. En utilisant ces concepts, vous pourrez afficher les messages d’erreurs sur le portail Azure et donner à un utilisateur des informations pertinentes de manière simple.
