Azure Logic App : d’un pattern linéaire à un pattern en étoile ?

Camille SCHNEIDER
Publié par Camille SCHNEIDER
Catégorie : Azure / Logic Apps / Microservices
04/08/2020

Si vous êtes un habitué des Logic App, vous connaissez sûrement la fonctionnalité permettant de soumettre à nouveau un run précis. Cette fonctionnalité peut s’avérer vraiment pratique, tant en phase de développement qu’en phase d’exploitation. Elle offre la possibilité de rejouer une occurrence d’un run depuis le début. En résumé, cela permet de relancer un run à partir du point de départ, sans nécessiter la présence des éléments qui ont permis de lancer initialement le processus (le trigger). Cette fonctionnalité est tellement intéressante qu’elle impacte la conception et la mise en oeuvre de nos flux Logic App. Or, Microsoft annonce une nouvelle fonctionnalité Azure Logic App: la possibilité de rejouer un flux depuis une action précise : https://feedback.azure.com/forums/287593-logic-apps/suggestions/19196263-how-can-we-resubmit-only-particular-action-in-logi

Pour ma part, cela m’a fait réfléchir à la stratégie à adopter lorsque l’on doit concevoir des flux avec des Logic Apps.

Lors des phases de conception de flux, il est important de penser aux dépendances que peuvent avoir les Logic Apps entre elles et à la façon dont elles sont imbriquées.

 

Le Pattern linéaire

 

Jusque là, pour tirer pleinement profit de la fonctionnalité « soumettre à nouveau« , il était intéressant de mettre en place un flux impliquant plusieurs Logic Apps de manière linéaire :

 

Pattern_lineaire

 

Le pattern linéaire consiste à séparer les différentes étapes d’un flux en partageant les responsabilités de chacune des étapes. Par exemple, il est parfois intéressant de séparer l’implémentation des protocoles techniques (qui permettent de récupérer ou envoyer des informations depuis ou vers différents systèmes) des traitements purement métier. L’intérêt du pattern ci-dessus est que la resoumission d’un processus est possible au niveau de chacune des étapes. Le principale inconvénient est la ré-utilisabilité car les Logic Apps imbriquées sont fortement couplées. Par exemple, dans le schéma ci-dessus, il est impossible d’utiliser la seconde Logic App sans impliquer la troisième.

 

Le Pattern en étoile

 

Dès lors que la fonctionnalité de resoumission sera possible depuis une action précise, alors je pense qu’il faudra considérer le pattern en étoile :

 

Pattern_etoile

 

Le Pattern en étoile fonctionne avec une Logic App qui joue le rôle de pilote en appelant dans l’ordre souhaité les Logic App imbriquées les unes après les autres. Dès lors qu’il est possible de resoumettre depuis n’importe quelle action, alors ce pattern offre les mêmes perspectives que le pattern linéaire en matière de resoumission. Mais elle ajoute une meilleure réutilisabilité. En effet, contrairement au pattern linéaire, dans ce cas de figure, les Logic Apps peuvent être utilisées indépendamment les unes des autres.

 

Conclusion

 

Pour conclure, en comparaison du pattern linéaire, le pattern en étoile permet une réelle indépendance entre les Logic Apps et ainsi une architecture plus adaptée aux microservices. De mon côté, tant qu’il ne sera pas possible de soumettre à nouveau une action spécifique dans une Logic App, je privilégierai le pattern linéaire. Mais la question sera remise sur le tapis à la sortie de cette nouvelle fonctionnalité.