Event Data Flow
From the Data plaform description, we can deduce the path taken by the events generated by Centiloc devices down to the API or Web application you have access to.
Devices, whether they are Boards or Boards behind Gateways, join an IOT MQTT cluster.
These devices will publish events as soon as they detect and geolocate items. These events feed Ingest service.
They use this IOT MQTT to listen to commands from Interaction Service.
This service has multiple roles:
- Collect, decode, regroup and filter events from Boards
- Qualify event: is the event worse being forwarded
- Trig subsequent events
- Save the latest item position
- Forward the qualified event to the customer
Whenever you or any other service needs to communicate with any device, this service allows communicating with Devices over IOT-MQTT. This supports all the versions of any Centiloc Device.
There are 2 complementary ways to collect information:
- You can collect all the qualified events of all your Boards as soon as they have been qualified, by consuming User-MQTT.
- You can get the content of your Boards or ask for Item location and status by using gRPC API.
When getting the information from the API, you do not contact Board directly, but you collect the latest information cached in Geolocation cache by ingest service. This allows to always get the latest information available, even if devices are not reachable.
Even if User-MQTT is designed to maintain long-term connection, it is a good practice to ask for Board content from API right after connecting to the MQTT, so that you have the last picture of your board content before collecting events.
Whatever the way to run Geocore plateform, the same API is accessible to provide the maximal portability of your application.
Once an event is received and qualified, ingest service follows a certain distribution order:
- plain line: synchronous access
- dashed line: asynchronous access
As you can see, cache is being updated before the database. This ensures the fastest data process and producing events in few milliseconds.
Cache allows a faster and lighter access. This is a key to guarantee the better performance in providing an event qualified.
Database is necessary to store all the information that we need to raise in cache sometimes.
Then, when collecting an event from API stream or MQTT-User, only the cache is certain to be up-to-date.
Using the API to get geolocation information, it can be important to know where the database comes from: as the data storage has, for sure, seen the previous event or not?
- only
Board.GetItems()accesses cache - all the other API entry points access database
In case the collect of an event would trigger a synchronous control of board content, you must useBoard.GetItems()to ensure data consistency along with the data stream you received.