Skip to main content

Comment Alice’s Garden a introduit Mercure dans son SI ?

Mettre en place un jingle, mais pourquoi faire ?

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.

Choix des technos & réalisation du projet

É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.

Développement & fonctionnement de Jingle

Comment fonctionne Jingle ?

Schéma fonctionnement 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.

 Chemin Integromat - mercure

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.

Propriétés entités Jingle & JingleStep Propriétés entités Jingle & JingleStep - mercure

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€).

Endpoint API

Endpoint api

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.

Le subscriber

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.

NotifySubscriber - mercure

Les steps

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.

Reset de redis

Calcul pour obtenir le nouveau turnover

Schéma calcul steps - mercure

À 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.

Sélection dans l’ordre décroissant

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.

mercure

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.rocks

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.

Publication mercure

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.

Fichier .env. mercure

En réalité, il fallait donc placer notre JWT KEY dans cette dernière.

mercure

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…

HUB mercure

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.

JavaScript & eventSource

À 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.

Netlify & Front

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.

Netlify publication - mercure

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.

mercure

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 !

Alice's Garden

Équipe, stack, locaux…
Découvrez pourquoi les développeurs
aiment Alice's Garden sur leur page entreprise.

Découvrir la page de Alice's Garden
Julien Hennion

Auteur Julien Hennion

Plus d'articles de Julien Hennion

Rejoindre la conversation Un commentaire

Laisser un commentaire