TP – Application M2M

De plus en plus de bar ferment en France. Mais la consommation de bière n’a pas diminué pour autant. La consommation désormais se fait beaucoup plus par des tireuses à bière. Longtemps réservé pour les bars et les restaurants, des particuliers adopte ce mode de consommation. La plupart du temps, ces tireuses sont louées.

Voyant l’essor du M2M, les fabricants ont mis en places des tireuses à bière connectée. En plus de leur facilité d’utilisation, Elles permettent d’être géré à distance lorsqu’elles sont louées. Ou alors elles permettent aux établissements qui les possède de garder une comptabilité, et de gérer leur stock.

Description

Les tireuses auront plusieurs fonctions.

La première de ces fonctions sera de comptabiliser les volumes de bière consommé, et le nombre de fût utilisé au global. Ces métriques serviront à maintenir un inventaire des fûts consommés, et à anticiper les consommations, et donc le stock de bière. Elles serviront aussi à établir des quotas. Par exemple si le bar de par sa licence de distribution d’alcool est limité, il pourra empêcher la distribution au-dessus d’un certain seuil.

La deuxième fonction est pour les loueurs de ces tireuses. Ils pourront ainsi contrôler l’utilisation des tireuses par rapport au contrat de location.

Cinématiques

Pour tous les messages (question/réponse) décrits par la suite. Chaque message devra contenir certaines données techniques obligatoires. Ces données devront soit être contenu par le message, soit contenu par le protocole.

NameIdDescriptionQRValeur
id1ID du message envoyéXXID numérique
time2Date du message envoyéXXDate et heure au format ISO 8601
origin3Nom de l’équipement à l’origine de la requêteXNom de l’équipement
typeMsg4Type du messageXX
  • kegLoad [1]
  • getBeer [2]
  • happyHour [3]
respCode5Code d’état de la réponseXMême format que les codes retours HTTP
changeState6Indique un changement d’étatC
  • getBeer [2]: La tireuse doit fonctionner en mode unitaire
  • happyHour [3]: La tireuse doit être en mode Happy Hour

Tous les messages échangés devront comporter un ID de message. Cet ID sert à rapprocher la question de la réponse.

Sans cet ID, la communication ne peut être que synchrone. Alors que grâce à cet ID plusieurs questions peuvent être envoyées, et les réponses peuvent être reçus dans le désordre. L’émetteur de la question saura à quelle question correspond la réponse qu’il aura reçue.

La date d’envois du message permet de savoir si le message n’est pas expiré. Si c’est le cas, son traitement est inutile.

Indiquer l’origine de la requête permet d’identifier plus facilement un équipement à des fins de monitoring.

Le type de message permet d’identifier quel message est envoyé. Sans cela, le destinataire ne peut pas savoir de quoi il s’agit, et ne peut donc pas contrôler les champs obligatoires du message.

Le code réponse est important pour savoir si le client doit modifier sa requête (changement d’état) ou essayer de renvoyer le message si le front est temporairement indisponible.

Quand un changement d’état intervient, l’application notifie la tireuse qu’elle doit changer de mode de distribution. Elle renvois un code réponse 302, avec l’indicateur de changement positionné sur le type de message à renvoyer.

Dans notre cas, les tireuses envoient des questions, et les fronts envoient des réponses. Mais dans le cas où les équipements peuvent envoyer des questions et des réponses, un indicateur aurait été nécessaire dans le message

Chargement d’un fût

Cinematic kegLoad

Avant de passer aux choses sérieuses, il faut brancher un fût à la tireuse. Lorsque ce fût sera connecté, la tireuse enverra ses informations. À savoir sa contenance, son type, sa marque, sa dénomination…

Avant d’accepter de distribuer le contenant du fût, la tireuse doit obtenir l’autorisation de l’application. Pour donner son autorisation, l’application contrôlera que:

Si tout est en ordre, l’application renverra l’information que la tireuse peut utiliser le fût. Elle lui donnera également un ID de distribution que la tireuse devra positionner pour chaque message de distribution de bière.

kegLoad

NameIdDescriptionQRValeur
capacity10Capacité du fûtXCapacité du fût en litre
type20Type de bièreXBlonde, Brune…
brand21Marque de la bièreXHonigmann, Maredsous…
country22Pays de production de la bièreFFrance, Belgique…
name23Nom de la bièreXL’or de Beauce, Maredsous blonde de 6…
percentAlcohol24Pourcentage d’alcool dans la bièreXCapacité en %
canDistribute30Indique si la tireuse a le droit d’utiliser le fûtXtrue si la trieuse est autorisée à utiliser le fût, false sinon
idDistribute31ID de distribution que la tireuse doit associer aux messages de distributionsFID alphanumérique

Distribution de bière

Cinematic getBeer

C’est la cinématique la plus utilisée. Elle indique qu’une bière a été distribuée. Cela permet de comptabiliser le verre servi, et son volume.

La tireuse devra nécessairement envoyer l’ID donné lors du chargement du fût. Cela lui permettra à l’application de renvoyer le prix de la bière en fonction du volume distribué, et du type de bière.

Si le client fait partie d’un programme de fidélité, la tireuse pour envoyé son ID client. Cela permettra d’obtenir en retour une éventuelle réduction.

Pour indiquer à la tireuse ce qu’elle peut encore dispenser, l’application renvois aussi le volume de bière restant dans le fût (chargé lors du kegLoad).

getBeer

NameIdDescriptionQRValeur
idDistribute31ID de distribution de la tireuse (associé au fût)XID alphanumérique
capacity10Capacité du verreXCapacité du verre en centilitre
amount11Volume de bière distribuéXVolume en centilitre
clientId12ID du client servi. Présent si le client fait partie du programme de fidélitéFID alphanumérique
leftAmount13Volume de bière restant dans le fûtXVolume en centilitre
price32Prix de la bière distribuéeXPrix en euro (float)
reduction33Réduction (programme de fidélité)FRéduction en euro (float)

Happy Hour

Cinematic happyHour

Quand la cloche retenti, c’est cette cinématique qui est utilisé. Dans ce mode, la distribution va tellement vite que seul le volume de bière est comptabilisé.

La tireuse est mise au courant de cette nouvelle cinématique à utiliser quand elle reçoit la réponse à un getBeer. L’application lui retourne un code retour 302 avec le changeState à 3, indiquant qu’elle doit utiliser cette cinématique.

Lorsque l’Happy Hour est terminé, elle reçoit de nouveau un code retour 302 à un de ses messages avec le changeState à 2 indiquant qu’elle doit revenir à la cinématique getBeer.

Ce message est une notification. L’application ne renverra pas d’information utile. La tireuse tentera de renvoyer la notification si elle n’aboutit pas à l’application (suivant le code retour).

Ici le but est de garder un compte du volume de bière distribué sans avoir un flux trop important au niveau de l’application. Vu le nombre de personne durant cette période, l’objectif est d’en servir un maximum.

happyHour

NameIdDescriptionQRValeur
idDistribute31ID de distribution de la tireuse (associé au fût)XID alphanumérique
amount11Volume des bières distribuéXVolume en centilitre
leftAmount13Volume de bière restant dans le fûtXVolume en centilitre
price32Prix des bières distribuéeXPrix en euro (float)

Architecture

Application architecture

L’application est architecturée de manière simple. Dans le schéma, elle est entièrement redondé. Si on vient perdre un composant, l’application continuera de fonctionner.

Les tireuses à bière se connectent sur des fronts. Ces fronts s’occupent de gérer la communication, sécurité et l’authentification des tireuses. Les fronts envoient les authentifications et les messages applicatifs au backend.

Le backend qui reçoit les demandes d’authentification des tireuses consulte la BDD. Il traite aussi les messages applicatifs. Au besoin, il met à jours les informations des tireuses en BDD.

La Base de données est organisée en cluster pour pouvoir répondre aux requêtes en parallèle.



L’abus d’alcool est dangereux pour la santé. À consommer avec modération
Par Jérémy HERGAULT et Anthony THOMAS, le .