Propriétés « Exécuter après » avec l’éditeur en ligne des Applications Logiques (Logic Apps)

Oguzhan Yigit
Publié par Oguzhan
Catégorie : Azure
28/11/2018

Code Json des Logic Apps

Derrière l’éditeur de Logic Apps du portail Azure, se cache un code source basé sur une définition Json. Tout simplement, le déclencheur de la Logic Apps, ainsi que toutes les actions du processus conçus sont présents dans la définition Json. Si vous avez déjà utilisé l’onglet « Affichage du code » de l’éditeur du portail Azure, vous avez probablement remarqué que cette définition contenait aussi :

code json logic app

 

Vous avez peut être remarqué que la propriété « triggers » est au pluriel. Cela pourrait nous laisser croire que nous pouvons avoir plusieurs déclencheurs pour une Logic App. Et bien effectivement, c’est tout à fait possible. Cependant, ce n’est pas supporté par l’éditeur graphique, mais seulement par l’éditeur de code. Consultez la page https://docs.microsoft.com/fr-fr/azure/logic-apps/logic-apps-workflow-definition-language pour plus d’informations. Cela étant, de mon côté, tant que ce n’est pas supporté par l’éditeur visuel, j’éviterais d’utiliser plusieurs déclencheurs pour une même Logic App.

 

Les effets trompeurs de l’éditeur visuel des Logic Apps

Si vous êtes habitués à utiliser l’éditeur graphique, vous savez probablement à quel point il simplifie la mise en œuvre et l’organisation de flux. Cependant, parce qu’il ne supporte pas toutes les fonctionnalités des Logics Apps, l’éditeur graphique peut parfois en cacher le fonctionnement. Les déclencheurs multiples en sont un exemple. Heureusement, il n’en existe que quelques uns.

 

Définition des Actions des Logic Apps

Avant d’aller plus loin, regardons de plus près à quoi ressemble la définition d’une action au sein d’une Logic App. La plupart des actions sont définies, à minima, par le code Json suivant :

code json action logic app

 

Par exemple, l’action « Scope » (« Etendue » en français) n’a pas de propriétés « inputs », mais possède une propriété « actions » qui contient l’ensemble des actions à l’intérieur du Scope. Aussi, si vous avez implémenté des traces de type Log Analytics ou encore si vous avez défini des délais d’exécutions maximum, vous aurez d’autres propriétés à l’intérieur de cette définition.

 

Propriétés du déclencheur des Logic Apps

Bien évidemment, la première étape d’une Logic Apps est le déclencheur (trigger). A la suite de son exécution, toutes les actions suivantes sont lancées :

  • celles qui ne sont pas dans un scope
  • celles qui ont la propriété « runAfter » vide de tout entrée

Vous pouvez définir plusieurs actions qui s’exécutent juste après le déclencheur. Utilisez simplement l’éditeur graphique et l’option « Ajoutez une branche parallèle » pour obtenir le résultat suivant :

action parallele apres trigger

 

De plus, si vous cliquez sur les trois points en haut à droite du déclencheur, vous remarquerez que l’option « Configurez la propriété Exécuter après » est désactivée.

configurer run after

 

Sur ce point, l’éditeur graphique gère parfaitement les fonctionnalités des Logic Apps.

 

Propriétés des Actions des Logic Apps

Chaque action des Logic Apps est exécutée si et seulement si toutes les actions définies dans la propriété « runAfter » se sont terminées avec le statut attendu. Si vous regardez un peu plus en détail l’exemple donné précédemment, en réalité, je voudrais exécuter mon scope « business » si et seulement si les deux actions précédentes se sont terminées avec succès. C’est assez simple de réaliser cette manipulation avec l’éditeur graphique si vous le faites dès que vous en avez la possibilité. C’est toutefois un peu plus compliqué si vous avez bien avancé dans le développement de votre flux.

nouvelle action sur action parallele

 

Par exemple, sur la capture précédente, le bouton « Nouvelle étape » permettra d’ajouter une action qui va être dépendante des 2 actions de type « variable », donnant le flux suivant :

ajout nouvelle action sur action parallele

 

C’est cependant un peu plus compliqué lorsque nous souhaitons obtenir cette configuration sur un flux un peu plus avancé dans le développement. Dans le cas suivant, le bouton « Nouvelle étape » va lier le scope « error scope » avec l’action « Initialize TempVar2 » et je n’aurai pas mon Scope « Business » lié comme je l’aurais souhaité.

actions parallele cas complexe

 

Pour obtenir le résultat souhaité, vous pouvez ajouter une action temporaire (que vous retirerez ultérieurement), avec le bouton « Nouvelle étape » et ensuite, glisser/déposer les actions souhaitées au bon niveau. Sinon, utilisez simplement l’éditeur de code pour définir manuellement la propriété « runAfter ».

propriete run after action logic app

 

Aussi, depuis l’éditeur graphique, l’option « Configurer la propriété Exécutez après » permet de configurer finement les résultats attendus pour l’exécution de l’action. En pratique, vous pouvez définir qu’une action s’exécutera si l’action précédente est en succès ou en erreur. Et même si votre est action est dépendante de plusieurs autres, l’éditeur graphique permet de le gérer. Sur ce point, je trouve l’éditeur très ergonomique.

configurer detail run after

 

L’action Scope

Sur certains aspects de la propriété « runAfter », l’action « Scope » est similaire au scope principal :

  • les premières actions à s’exécuter sont celles qui n’ont rien de défini dans la propriété « runAfter »
  • l’option « Configurer la propriété Exécuter après » est désactivée depuis l’éditeur graphique

Notez que les dépendances sur la propriété « runAfter » ne peuvent être paramètrées qu’entre des actions de même scope (de même profondeur).

Aussi, si vous souhaitez avoir des actions parallèles en début de scope, vous devrez le configurer manuellement via l’éditeur de code.  L’exemple suivant à été configuré à l’aide de l’onglet « Affichage du code ». Vous pouvez constater dans le scope « business scope » qu’il n’y a pas de lien entre les deux actions. Cela signifie qu’elles s’exécuteront toutes les deux en parallèle.

action parallele dans un scope

 

Si vous avez des actions qui suivent celles-ci, alors l’éditeur ne les affichera pas correctement (du moins, à l’heure ou j’écris ce post). Cela sera supporté, mais l’éditeur ne montre pas la dépendance des deux actions. Mais comme les équipes Microsoft travaillent très activement sur les services Azure, j’imagine que cela sera corrigé dans les prochaines mises à jour. Notez que les actions « conditions », « Pour chaque », « Until (jusqu’à) » se comportent de manière similaire.

 

Organiser vos actions

Avant de terminer cet article, je voudrais partager mon expérience quant à l’usage de la propriété « runAfter ». Parce-que le cycle de vie d’une Logic App est différent d’un bloc de code traditionnel, abuser de la propriété « runAfter » peut rendre vos flux très complexes à comprendre et à maintenir. Il peut être difficile d’avoir une vue globale et surtout de contrôler tous les états possibles de votre flux. Je vais illustrer cela avec un exemple : la gestion d’erreur. Si vous avez une erreur dans l’exécution de votre flux, ce n’est pas pris en charge comme un bloc try\catch d’un code traditionnel (par exemple au sein d’une fonction Azure) : le processus va essayer de trouver une action qui souhaite s’exécuter même si celle-ci est en erreur. Une erreur courante est de gérer les cas d’erreurs avec la propriété runAfter sans arrêter le processus avec une action de type « Terminer ».

gestion erreur avec run after

 

Dans le diagramme ci-dessus :

  • la première action se termine en erreur
  • ensuite, l’action suivante permet d’envoyer un mail un administrateur (ne s’exécute que si l’action précédente est en erreur)
  • l’action suivante ne s’exécute que si l’action d’envoi de mail à l’administrateur est ignorée. Ce qui signifie simplement : s’exécute si la première action n’est pas en erreur (cela s’apparente à une gestion d’erreur). Cependant , il peut être assez complexe de ne pas avoir d’effet indésiré dans la suite du flux. Si vous regardez la suite du diagramme, vous remarquerez que le même modèle est appliqué pour les 3 dernières actions :

gestion erreur avec run after pattern

 

Dans ce scénario, la dernière action s’exécutera parce que l’action qui la précède est ignorée. Tout cela vient de la première action qui est en erreur. On peut constater ici un effet dû à un enchaînement en cascade des conditions d’exécutions. En apparence, cela ne semble pas être le comportement que nous souhaitons.

Mon conseil est le suivant : si vous devez arrêter un processus en cas d’erreur, n’essayez pas de trouver une sortie en configurant la propriété « runAfter » d’une manière ou d’une autre. Utilisez simplement l’action « Terminer » pour terminer brusquement votre flux.

Aussi, parce que je ne voudrais pas moi-même configurer des actions de gestion d’exception pour chacune des actions de mes flux, je vous conseillerais de grouper autant que possible dans des scopes distincts vos actions qui peuvent l’être et ainsi ne gérer les exceptions que sur les scopes. Dans l’exemple suivant, j’ai justement regroupé des actions dans 2 scopes que j’ai nommés « Process File » et « Call Api ».

configurer run after avec des scopes

 

Pour en savoir plus sur la gestion d’erreur, vous pouvez également lire mon post sur la gestion d’erreur avec les Logic Apps : Gestion d’erreurs avec Azure Logic Apps