Event Data Flow
En lisant la description de la plateforme de donnée, on peut déduire le chemin arpenté par les évènements générés par les équipements Centiloc
Les équipements, qu’ils s’agissent de plateaux ou the plateaux derrière une gateway, rejoignent a Cluster MQTT IOT.
Ces équipements vont publier des évènements dès qu’ils détectent et géolocalisent des objets. Ces évènements nourissent les Services d’ingestion (Ingest service).
Enfin, ils utilisent le MQTT IOT pour écouter les commandes en provnance des services d’interaction (Interaction Service).
Ce service a de multiples rôles:
- Collecter, décoder, regrouper et filtrer les évènements générés par les plateaux
- Qualifier les évènements: est-ce que l’évènement vaut la peine d’être généré ?
- Déclencher des évènements sous-jacents au besoin
- Sauvegarde la dernière position des objets
- Transférer les évènements qualifiés au client
A chaque fois qu’un service a besoin de communiquer avec un équipement (plateau ou gateway), ce service d’intéraction réalise cette communication au travers du MQTT-IOT. Il supporte toutes les versions de tous les équipements Centiloc.
Il existe 2 moyens complémentaires de collecter les informations de géolocalisation:
- Vous pouvez collecter les évènements de tous les plateaux dès qu’ils sont qualifiés, en consommant le User-MQTT.
- Vous pouvez obtenir le contenu des plateaux ou demander la position d’un objet par l’API gRPC.
Lorsque vous obtenez les informations depuis l’API, vous ne contactez pas directement les plateaux, mais vous collectez la dernière information stockée en cache (ou base de donnée) par les ingest service. Cela permet d’obtenir toujours la dernière information rendue accessible, même si des équipements ne sont plus joignables.
Même si ce User-MQTT est calibré pour maintenir des connections sur le long-terme, il est bon de demander le contenu des plateaux avec des appels API après s’être connecté au MQTT, de sorte à obtenir la dernière image du contenu des plateaux avant de récoler des évènements générant des différences.
Quelque soit la manière dont est exécuté la plateform Geocore, l’API est la même, assurant la meilleure portabilité de votre application.
Une fois qu’un évènement est reçu et qualifié, le Ingest Service suit un certain ordre de distribution:
- ligne pleine: accès synchrone
- ligne pointillée: accès asynchrone
Comme vous pouvez le voir, le cache reçoit des mises à jour avant la base de donnée. Cela assure que le flot de donnée soit le plus rapide, poussant les évènements en quelques millisecondes.
Le cache permet un access rapide et léger. Il est une clef pour garantir les meilleurs performances lors de la génération d’évènements qualifiés.
La database, quant à elle, est nécessaire pour stocker toutes les informations dont nous aurons besoin pour regénérer le contenu du cache.
Ainsi, lorsque vous collectez des évènements depuis les flots d’API ou de MQTT-User, seul le cache is certain d’être à jour.
En utilisant l’API pour récolter des informations de géolocalisation, il peut être important de savoir d’où vient la donnée: est-ce que la zone de stockage a vu, à coup sûr, l’évènement précédent ou pas?
- seul
Board.GetItems()accède au cache - tous les autres points d’entrée de l’API accèdent à la base de donnée
Si jamais la réception d’un évènement devait déclencher un accès synchrone pour controler le contenu d’un plateau, you devez utiliserBoard.GetItems()pour assurer la consistence des donnée avec le flot de donnée que vous avez reçu.