Nous avons vu dans un précédent billet la mise en place d’une API HTTP REST dans le cadre d’un projet avec Intervox Legrand. Dans cet article nous faisons un focus sur l’utilisation de Mule ESB.

La mise en place de l’API et son nouveau modèle ont nécessité plusieurs mécanismes de propagation de données que nous avons adaptés au contexte et aux nouveaux besoins :

• consommation directe des web services de l’API par le système en place pour les nouveaux types de données (suivi d’activité)
• intervention d’un tiers pour les données précédemment exploitées pour minimiser l’impact de l’API :
  • L’ETL PDI pour un traitement en lots (journaux)
  • L’ESB Mule pour de l’intégration au fil de l’eau (transmetteurs, transactions, etc.)

Ce billet fournit des informations sur l’utilisation de Mule ESB au sein du projet.

# Mule ESB, la solution ESB de MuleSoft

La plateforme écrite en JAVA est publiée sous licence CPAL (Common Public Attribution License).
La version OpenSource est utilisable en production. La version Enterprise étend les possibilités (connecteurs, console d’administration, etc.) et permet d’accéder au support de MuleSoft.
Son IDE permet de mettre en œuvre des scénarios d’intégration de manière visuelle.

La plateforme est composée de trois outils :

1. AnyPoint Studio qui permet le développement. Cet IDE est basé sur Eclipse
2. Mule Runtime pour l’exécution des traitements
3. Mule Management Console pour la gestion et le monitoring (application web)

• disponible avec la version Entreprise de Mule (avec une licence valide)
• déploiement sous la forme d’une application web (Tomcat, JBoss, etc.)

# Les flux traités par l’ESB

Mule ESB utilisé pour la propagation de données

Un ESB surveille les actions du serveur de réception sur sa base afin de reporter les nouveautés dans la base de l’API WS en consommant les WS de l’API -2-. Le délai de disponibilité des données est dépendant de l’intervalle de vérification défini. Ce dernier peut être court dans la mesure où le traitement reste chargé en mémoire : il n’y a pas le délai induit par un appel régulier via une tâche planifiée.
Dans l’autre sens, l’API WS interroge un WS implémenté au niveau de l’ESB -1-, qui crée la commande dans la base du serveur de réception. La commande est immédiatement disponible dans la base du serveur de réception.
Dans la mesure où le serveur de réception ne stockait pas les données liées à l’actimétrie dans sa version passée, nous avons pu envisager de stocker directement ces informations dans la base de l’API plutôt que de passer par la base du serveur de réception. Le serveur de réception interroge directement le WS adéquat A’.

# Exemple 1 : Création des transmetteurs

Le traitement présenté ici consiste à créer dans la base de l’API les nouveaux transmetteurs qui se sont déclarés auprès du serveur de réception (via l’ouverture d’une socket). Lorsqu’un transmetteur est prêt à être envoyé à l’API, le serveur de réception crée un message « Il existe un nouveau transmetteur ». Régulièrement, le traitement prend en charge un lot de messages (exemple : 200 messages toutes les secondes) :

A chaque itération, on individualise les messages qu’on transmet à une File d’attente en mémoire :

Lorsqu’un message arrive dans la file d’attente, il est immédiatement traité. Le flux est progressivement enrichit avec les données du transmetteur, les identifiants externes (identifiants « API »), les données de ses périphériques, ses séquences, etc. :

A la fin du traitement, le message est transformé en JSON qui permet de créer le transmetteur dans la base de l’API en consommant le web service adéquat. Puis le message est supprimé :

Exemple d’enrichissement du message avec les périphériques du transmetteur :

# Exemple 2 : Web service de suivi

Le traitement présenté ici est de nature différente. Il consiste à exposer un web service de suivi des messages : messages en cours / erreurs :

En réalisant un GET sur l’URL adéquate :

On obtient le résultat sous forme de JSON :

# Exemple 3 : Console de suivi

De la même manière que pour les web services, il est possible d’héberger une page html avec un Handler de ressources statiques :

Les ressources statiques sont ajoutées au projet. Un extrait :

L’administrateur d’Intervox accède à la console de suivi en HTTP à partir de son navigateur. La page réalise des appels Ajax vers le serveur Mule afin de récupérer les données produites et de les présenter. Par exemple, le bloc « Main » de la page exploite le web service présenté précédemment :

Console de suivi vue par l’utilisateur

De plus des tableaux permettent de lister les messages sous formes de pages avec de la navigation , d’afficher le détail d’un message  ou encore de le rejouer .

# Conlusion

Mule ESB a fait ses preuves pour l’intégration des données dans le contexte du projet d’Intervox et pour les flux ciblés. Notamment, il est particulièrement adapté au traitement « au fil de l’eau » des nombreux messages produits dans le cadre de l’IoT.
L’outillage fourni a également permis d’aller un peu plus loin en hébergeant une console de suivi développée pour l’occasion qui permet d’inspecter les messages qui transitent et de les rejouer si nécessaire.