Communication élastique et fiable avec Azure Logic Apps et Azure Service Bus

Oguzhan Yigit
Publié par Oguzhan
Catégorie : Azure
10/12/2017

Elasticité d ’Azure Logic app

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 :

  • La montéee mémoire de votre Logic App lorsque cela est nécessaire ;
  • La scalabilité du processus lors des pics de charge

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 :

logic app étape sur un process

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

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 :

  • Le partage de message entre processus
  • La gestion d’un retry automatique
  • L’envoi des messages en dead letter en cas d’echecs multiples
  • Le resoumission de messages…

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

Un exemple simple avec Azure Logic Apps & Azure Service Bus

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 :

processus simple avec azure logic apps

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 :

logic app fiabilisé par service bus

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 :

  • La première Logic App réceptionne le fichier depuis le serveur FTP et le stock dans une file Azure Service Bus
  • La seconde Logic App est notifiée de l’arrivée d’un message. Elle lit le message depuis la file Azure Service Bus, transforme les données vers le format cible et envoi le résultat de la transformation dans une queue ou un topic Azure Service Bus
  • La dernière Logic App réceptionne le message transformé et l’envoi par mail

Les avantages d’Azure Service Bus

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.

Les Queue Azure Service Bus ou les Topics Azure Service Bus ?

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)

Explorer les fonctionnalités des Queues et des Topics

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.

Ajouter un nouveau client à notre queue Azure Service Bus

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.

Service bus topic- nouvel abonné

Gérer Azure Service Bus

Pour gérer Azure Service Bus, vous pouvez

  • Coder. Mais franchement à quoi bon étant données les options suivantes!
  • Utiliser le portail Azure mais il reste assez limité car il n’y a pas d’interface d’administration pour certaines fonctionnalités (elles sont supportés mais ne peuvent pas être configuré)
  • Utiliser le produit de notre partenaire Kovai : https://www.servicebus360.com/. Il s’agit d’un produit full Web avec beaucoup de fonctionnalités qui de plus est gratuit dès lors qu’on se limite à 1 seul namespace
  • Utiliser Service Bus Explorer (un client lourd, gratuit et très complet) : https://blogs.msdn.microsoft.com/paolos/2015/03/02/service-bus-explorer-2-6-now-available/