Comment Alice’s Garden a introduit Mercure dans son SI ?
Jingle est une application permettant de jouer de la musique lorsque des objectifs de chiffre d’affaires sont réalisés. Notre but lors de la création et du développement de Jingle était d’offrir la possibilité de célébrer l’augmentation du chiffre d’affaires de l’entreprise, l’idée étant ainsi de diffuser de la musique à travers l’open space.
Pour cela, nous avons opté pour le système de “paliers”. Ainsi , lorsque nous passons, par exemple, le cap du million d’euros, une musique se déclenche.
La grande différence entre les steps et les paliers se situe dans le fait qu’un palier ne sonnera qu’une seule fois par an. Une step, quant à elle, pourra retentir tous les 5.000€ ou 10.000€ par exemple.
Avec les principales idées de réaliser le projet, il ne nous restait qu’à choisir la manière dont nous le ferions et donc le choix des différentes technologies.
Ce que nous voulions à tout prix éviter était de devoir calculer un chiffre d’affaires. En effet, nous possédons déjà un outil de Business Intelligence et son travail est de faire ce genre de calcul. Nous voulions donc faire descendre ce chiffre jusqu’à notre environnement technique afin de pouvoir le manipuler.
Étant sur un environnement Symfony, nous voulions rester dans nos domaines de compétences. De plus, cela fait un petit moment que nous nous intéressons au protocole Mercure (c’est un protocole ouvert de communication en temps réel conçu pour être rapide, fiable et économe en énergie) et quoi de mieux qu’un projet interne pour éprouver une nouvelle technologie.
L’idée serait donc de faire transiter le chiffre d’affaire vers notre API, que cette dernière choisisse s’il y a un jingle à jouer ou non et publier l’information dans Mercure. (valeur du chiffre d’affaire / jingle à jouer s’il y en a un et la raison du déclenchement du Jingle)
Pour la partie écoute, nous partirons sur un nouveau projet très simple constitué d’une page HTML avec du javascript qui écoute le Mercure. Cette page HTML présentera les données publiées dans le topic Mercure et jouera ou non un jingle.
Tout d’abord, notre processus commence avec Qlik où nous récupérons le chiffre d’affaires (CA) afin de l’envoyer directement par mail (Un système d’alerting est possible afin de nous notifier par mail de la valeur d’une KPI.)
Ensuite, nous utilisons Integromat, une plateforme d’automatisation (no code), qui permet de créer des flux, il est possible de se connecter à différents services tels que gmail, outlook, amazon.. ainsi que certaines applications. Le plus gros avantage c’est que tout se fait sans avoir besoin de coder.
Toutes les cinq minutes environ, integromat s’occupera donc de regarder si un mail contenant notre CA est arrivé ou non. Si c’est le cas, on enverra un appel HTTP vers notre API sinon rien ne se passe.
Comme vous pouvez le constater une fois que nous avons notre mail, le chiffre contenu est parsé et converti en structure JSON. Après une authentification sur notre API et la récupération du token JWT, nous pouvons poster notre valeur de CA afin de déclencher ou non un jingle.
Nous avons donc récupéré notre CA qui s’appellera dorénavant “turnover” au sein de notre code.
Au sein de notre dossier Entity, nous allons retrouver nos entités ainsi que nos différentes variables.
Il y a donc nos différentes colonnes pour réaliser le système de paliers. On y retrouve donc nos rangeMin et rangeMax, nos dates startDate et endDate,la musique et si celle-ci à déjà été jouée ou non.
Il y a également une autre entité doctrine faisant référence à la deuxième table servant cette-fois ci pour nos “steps”, le principe étant le même mais sans limitations d’écoute et de restriction de date. (Une step se déclenche par exemple tous les 5.000€ ou 10.000€).
Le endpoint de notification d’évolution de notre chiffre d’affaires par Integromat ne fait référence à aucune entité, la rédaction d’un DTO a donc dû être nécessaire afin de pouvoir créer notre nouvelle route.
Pour effectuer les traitements nécessaires à la publication d’un message dans Mercure ou non, nous avons rédigé un subscriber qui écoute l’événement de Kernel.view de Symfony et qui ne supporte uniquement que notre route de notification.
Tout d’abord, pour gérer et déclencher les bonnes steps, il nous fallait récupérer le turnover actuel ainsi que le turnover stocké dans redis (en effet, à l’initialisation du premier jingle, nous stockons la valeur dans redis afin d’avoir un point de comparaison avec les futurs valeurs de CA qui arriveront) afin d’obtenir la différence entre le précédent et le nouveau et ainsi pouvoir calculer l’augmentation du turnover.
À chaque notification, nous comparons chaque steps dans l’ordre décroissant et nous nous arrêtons dès que la différence est égale à une step non jouée.
Lorsque l’entièreté de la table aura été jouée au moins une fois, celle-ci sera remise à zéro grâce à notre fonction resetJingleSteps. Cependant, Redis qui stock le dernier turnover reçu ne sera quant à lui pas reset à 0, il gardera simplement le dernier en date afin de pouvoir continuer de faire le calcul.
Pour résumer:
Nous avons des étapes en base de données avec une musique associée et une valeur à laquelle elle a sonné la dernière fois. Si mon étape n’a jamais sonné, je compare la valeur de ma notification à la valeur qu’il y a dans redis sinon je compare la valeur de ma notification avec la valeur de la dernière fois où ça a sonné en base. Lorsque ma dernière étape sonne, nous remettons tout à 0.
Mercure permet d’envoyer des notifications en temps réel mais le plus intéressant pour notre projet se trouve dans le fait qu’il est ainsi possible de jouer notre musique, notre notification de manière synchronisée sur tous les appareils que nous souhaitons.
Les topics Mercure servent d’identifiant pour la notification que nous souhaitons envoyer. Dans la documentation, il y est indiqué que la bonne pratique est que ce topic est la forme d’une route. Nous avons donc choisi d’utiliser le Router Symfony afin de générer correctement ces derniers.
Cependant lors de l’installation de mercure nous avons rencontré différents problèmes notamment avec la sécurité et JWT.
Premièrement nous avons fait face à l’erreur suivante : “failed to send an update”, après plusieurs heures de recherches, il s’est avéré que cela était lié à la variable d’environnement pour Mercure et JWT , nous étions un peu confus vis-à-vis car la variable se nomme MERCURE_JWT_SECRET donc naïvement, nous avons mis la valeur de notre secret JWT.
En réalité, il fallait donc placer notre JWT KEY dans cette dernière.
Dans un second temps, dans la version SaaS de Mercure, nous avons également bloqué sur le “Subscriber JWT Key” où ici on parle également de KEY mais il est écrit en petit en dessous qu’il faut un secret. Nous pensions que c’était la même “erreur” que pour la partie Symfony et avons mis notre clef, mais il s’avère qu’il faut bien mettre un secret ici…
L’utilisation de mercure dans ce projet nous a permis d’apprendre à s’en servir et également d’imaginer d’autres possibilités comme par exemple un système de notifications lié au site principal d’Alice’s Garden.
À l’origine, nous voulions utiliser l’EventSource classique étant donné que mercure fonctionne grâce à celui-ci. Cependant, étant donné que l’applicatif qui publie est sur un domaine différent que celui qui écoute, il était impossible d’utiliser l’eventSource classique pour gérer la sécurité avec JWT (car impossible de customiser un header d’authorization sur le EventSource classique) nous avons donc choisis l’EventSourcePolyfill qui convient donc à notre situation.
Cependant, le local lui fonctionnait correctement étant donné que nous étions uniquement sur du local et donc pas de changement d’adresse.
Pour finir, la dernière partie sur laquelle nous avons travaillé est celle du front et de Netlify. Netlify est un site proposant “d’héberger » vos sites. En effet, au niveau de l’utilisation cela est très pratique pour nous. Il suffit simplement de compresser notre dossier contenant nos musiques, l’HTML/CSS et le JavaScript en .zip et le tour est joué. Il ne reste plus qu’à le placer dans Netlify et grâce à l’url nous avons accès de n’importe où à notre front.
Au niveau du front nous avons voulu faire quelque chose de très simple. Notre unique but était d’afficher le CA et les notifications de passage de paliers/steps avec une animation.
Au niveau hardware le tout fonctionne sur un raspberry avec des enceintes que l’on peut déployer à l’infini.
Vous pouvez en savoir plus sur Alice’s Garden grâce au dernier article sur notre outils de BI, à l’article sur notre nouveau projet, à la vidéo Happy Developers de Fabien ou au live avec Damien !
Les maladies inflammatoires chroniques de l’intestin ou "MICI" sont invisibles, mais leurs impacts sur la…
Depuis l'été, j'ai un Pixel qui intègre à la fois un TPU (Tensor Processing Unit)…
On se retrouve dans un nouvel article avec toutes les infos sur cette nouvelle saison…
Pourquoi l’inclusion numérique est essentielle : le point avec Mathieu Froidure. Dans un monde de…
Elles sont passées où les femmes dans la tech ? Entre le manque de représentation…
View Comments
Article très bien écrit, comme diraient les gamers: GG!
Bien joué!