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 :
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.
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.
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 :
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.
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 :
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 :
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.
Sur ce point, l’éditeur graphique gère parfaitement les fonctionnalités 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.
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 :
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é.
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 ».
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.
Sur certains aspects de la propriété « runAfter », l’action « Scope » est similaire au scope principal :
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.
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.
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 ».
Dans le diagramme ci-dessus :
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 ».
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
