Azure Logic App est l’outillage permettant de modéliser des workflows et de répondre à des besoins d’intégration au travers de Windows Azure. Comme beaucoup de services proposés par Windows Azure, les Logic Apps sont dit « serverless ». Oui cela signifie qu’il n’y a pas d’instance de votre workflow prête à exécuter une tâche. Cependant, la plateforme Windows Azure assure :
Et la fiabilité dans tout cela ?
Si vous regardez le résultat d’exécution d’une instance de votre Logic App depuis le portail Azure, et si vous vous focalisez sur une shape en particulier, vous verrez les entrée et sorties :
Dans la plupart des cas, nous pouvons voir nos processus comme un simple workflow prenant en entrée un message (un trigger) et réalisant des actions comme l’envoi de données vers un système cible. Mais si vous regardez votre processus en profondeur, il pourrait être séparé en plusieurs petits workflow. Et c’est exactement ce que je vous recommande de faire pour avoir une haute fiabilité.
Azure Service Bus est le moyen le plus rapide et le plus simple d’obtenir la fiabilité que devrait avoir vos processus. Je ne vais pas expliquer en détail ce qu’est Azure Service Bus, mais, comme la plupart des outils de queueing il propose les fonctionnalités suivantes :
Pour obtenir plus d’information sur Azure Service Bus, consulter le port https://docs.microsoft.com/en-US/azure/service-bus-messaging/service-bus-fundamentals-hybrid-solutions ou encore https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-queues-topics-subscriptions
Prenons un exemple pour illustrer la manière d’optimiser la fiabilité de notre processus au travers d’Azure Service Bus. Dans le cas suivant, j’ai besoin de lire un fichier XML depuis un serveur FTP, de transformer le contenu de celui-ci en CSV et de l’envoyer par mail à un partenaire.
Il s’agit d’un cas simple pouvant être illustré par le diagramme suivant :
Windows Azure permet d’intégrer de manière très simple ces connecteurs où que soient le répertoire FTP ou le serveur SMTP. Et, la Logic App semble vraiment très simple.
Imaginez, nous pouvons réaliser ce processus avec un simple workflow qui réalise toutes les tâches. Ok c’est vrai, cela ne serait même pas si dramatique. Mais dans un flux beaucoup plus complexe, il vous semblerait logique de séparer les traitements, alors nous allons également le faire dans ce flux.
Nous devons toujours avoir à l’esprit qu’un problème peut arriver. Si une quelconque erreur se produit pendant l’exécution du flux, je devrai probablement rejouer le flux. Les instances de Logic App peuvent être rejouées depuis le portail Windows Azure, mais cela implique qu’il soit rejoué en globalité, depuis le début. Dans des scénarios complexes, il est parfois impossible, voir même interdit de rejouer certaines parties du processus.
Et c’est ici qu’Azure Service Bus est incontournable. Ce que je recommande de faire est montré ci-dessous :
L’idée est ici de découper le processus complet en sous-process atomiques et d’utiliser Service Bus comme couche de persistance et échange inter-processus. Notre flux est ainsi divisé en 3 Logic Apps :
Une fois le fichier récupéré sur le serveur FTP, il est enregistré sur Azure Service Bus qui va le fournir aux abonnés. Azure Service Bus garantie la livraison du message et assure la conservation des messages jusqu’à consommation par un processus. Il est possible de définir des politiques pour rejouer un message en échec. Azure Service Bus rejouera le message jusqu’à ce que la propriété Retry Count (nombre de fois que le message est retenté en cas d’erreur) soit atteint ou alors jusqu’à ce que la consommation du message soit en succès. Et même si le nombre maximum d’essai est attient, le message peut être envoyé à la « dead letter » de la queue (ou du topic). A partir d’ici, vous pouvez consulter, modifier et resoumettre les messages.
Par ailleurs, vous pouvez gérer la durée de verouillage des messages : Service Bus considère que le processus est en erreur si le message n’est pas commité au-delà d’un délai configurable. Toutes ces fonctionnalités nous garantissent qu’un message n’est jamais perdu.
Il n’y a pas de meilleure réponse dans l’absolu. Tout dépend de nos besoins, il faut juste savoir la différence avoir conscience des différences entre les deux :
Les queues enregistrent les messages et les livrent au premier processus demandeur. S’il n’y a pas de demandeur, le message reste dans la queue.
Les topics permettent de partager les messages entre plusieurs abonnés. Un abonné peut specifier un filtre pour n’être notifié que pour une sous-partie des messages reçus. Mais si, pour un message donné, il n’y a pas d’abonné correspondant au moment de la réception, le message n’est pas conservé (il n’est donné à personne mais il peut être conservé dans la dead letter de l’abonnement)
Il est assez simple de comprendre que notre processus fonctionnera avec dans notre cas, l’option la plus adaptée est d’utiliser des Queues Azure Service Bus. Mais si j’avais plusieurs systèmes source ou cible, j’aurais probablement utilisé des Topics.
Supposons par exemple que nous avons 2 systèmes sources à partir desquels nous recevons les données (un par FTP et un par base de données). Avec le pattern précisé précédemment, nous avons juste à mettre en place une logic app qui lit les données en base.
Une fois les données lues, elles sont ajoutées à la queue existante. La suite du processus est identique pour les 2 sources. Bien sûr, dans mon exemple je suppose que le format des messages sont identiques. Mais, s’ils étaient différents, une autre logic app aurait fait la transformation avant de pousser les données dans la queue. Ce nouvel exemple peut intégralement être mis en œuvre avec des queues.
Mais supposons maintenant que nous avons deux systèmes cibles à notifier. Les fonctionnalités des Topics sont essentielles dans ce cas de figure. En ajoutant un nouvel abonné, nous pouvons traiter le message d’une manière différente et l’envoyer vers un nouveau système.
Pour gérer Azure Service Bus, vous pouvez