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.
| Name | Id | Description | Q | R | Valeur |
|---|---|---|---|---|---|
| id | 1 | ID du message envoyé | X | X | ID numérique |
| time | 2 | Date du message envoyé | X | X | Date et heure au format ISO 8601 |
| origin | 3 | Nom de l’équipement à l’origine de la requête | X | Nom de l’équipement | |
| typeMsg | 4 | Type du message | X | X | kegLoad [1], getBeer [2], happyHour [3] |
| respCode | 5 | Code d’état de la réponse | X | Même format que les codes retours HTTP | |
| changeState | 6 | Indique un changement d’état | C | 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
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:
- Le fût est compatible avec la tireuse
- Le bar n’a pas dépassé son quota de distribution d’alcool
- Le locataire n’a pas dépassé son quota défini dans son contrat de location
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
| Name | Id | Description | Q | R | Valeur |
|---|---|---|---|---|---|
| capacity | 10 | Capacité du fût | X | Capacité du fût en litre | |
| type | 20 | Type de bière | X | Blonde, Brune… | |
| brand | 21 | Marque de la bière | X | Honigmann, Maredsous… | |
| country | 22 | Pays de production de la bière | F | France, Belgique… | |
| name | 23 | Nom de la bière | X | L’or de Beauce, Maredsous blonde de 6… | |
| percentAlcohol | 24 | Pourcentage d’alcool dans la bière | X | Capacité en % | |
| canDistribute | 30 | Indique si la tireuse a le droit d’utiliser le fût | X | true si la trieuse est autorisée à utiliser le fût, false sinon | |
| idDistribute | 31 | ID de distribution que la tireuse doit associer aux messages de distributions | F | ID alphanumérique |
Distribution de bière
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
| Name | Id | Description | Q | R | Valeur |
|---|---|---|---|---|---|
| idDistribute | 31 | ID de distribution de la tireuse (associé au fût) | X | ID alphanumérique | |
| capacity | 10 | Capacité du verre | X | Capacité du verre en centilitre | |
| amount | 11 | Volume de bière distribué | X | Volume en centilitre | |
| clientId | 12 | ID du client servi. Présent si le client fait partie du programme de fidélité | F | ID alphanumérique | |
| leftAmount | 13 | Volume de bière restant dans le fût | X | Volume en centilitre | |
| price | 32 | Prix de la bière distribuée | X | Prix en euro (float) | |
| reduction | 33 | Réduction (programme de fidélité) | F | Réduction en euro (float) |
Happy Hour
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
| Name | Id | Description | Q | R | Valeur |
|---|---|---|---|---|---|
| idDistribute | 31 | ID de distribution de la tireuse (associé au fût) | X | ID alphanumérique | |
| amount | 11 | Volume des bières distribué | X | Volume en centilitre | |
| leftAmount | 13 | Volume de bière restant dans le fût | X | Volume en centilitre | |
| price | 32 | Prix des bières distribuée | X | Prix en euro (float) |
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.