Triage Dev Guide
Triage Dev Guide
dev-guide.md 3.58 KB
Triage
This service manages firmware updates for VModules and Canvases.
Resources Managed
Apk
This contains Blob metadata for new APKs to be downloaded during their updates. It includes the firmware name, URL, timestamps, and
version. These are not regular Asset-APKs downloaded as required by Schedules: These are APKs produced by Videri to support the basic
functions of the devices as part of the Videri network (rendering Assets, parsing Layouts, generating Schedules based on data pulled from
S3, RSA registration in Kong, etc.).
Bundle
Bundles are sets of Apks and Firmware to be downloaded by devices. They have a have-and-belongs-to-many relation with BundleRule s,
using bundle_maps as their joins-table, to determine which devices should receive which software-bundles. They do not have a formal
Rails-defined belongs_to relation to Firmware, but relevant partsof that relation are manually implemented. They also HABTM APKs, though
the foreign keys are held in an array by the Bundle, not a joins-table.
BundleRule s contain a set of matchers restricting the Players to which they would apply, a Priority number, and a name and description.
They are default-ordered by Priority (ascending) so when a Player picks "the first" Bundle Rule which applies to it, it gets the one with the
lowest priority-number.
Known Pain Points
Non-standard setup for data-relations - APKs and Firmware
Rule-based relation to Players with rules stored inside a JSONb in BundleRule records
Firmware
This contains Blob metadata for new versions of the devices' Operating Systems to be downloaded during their updates. It includes the
firmware name, URL, timestamps, and version.
History
This has a player_id foreign ey and tracks important changes to devices. For example, changes to timezones, Access Control Groups,
and firmware versions are described in the details JSONb field under the changes key.
Stacks
These are to register stacks with Triage, which in turn allows Canvases to work with them.
Tags & Comments
Triage ha a tagging system for Players on a HABTM relation. Users may read or delete these tags. Triage also has a system for leaving
comments related to individual devices which can be fully managed by users (where a given play ha a "Has Many" relation with comments
on it).
Communication
This service receives API calls from both users and devices. Devices hit endponts handled by the LiveController and
LivepreController controllers, which are in turn backed by the Live and Livepre classes defined at app/models/live.rb and
app/models/livepre.rb . Both act as interfaces to update the device's Player record on the Triage database. Livepre does not assume
that the device's profile already exists in the Central database while the Live interface does.
For Live devices, synchronizes its records with those of Central, making API calls to Central to copy content from the appropriate Player
record. The record in question is found by searching using the Device ID and spproprite Tenant, passing the Device ID as a parameter and
forwarding the X-Tenant header received by Triage in its call to Central.
Scheduled Updates
https://git.videri.com/triage/backend/-/blob/master/dev-guide.md 1/2
10/29/22, 9:00 AM dev-guide.md · master · triage / Triage Backend · GitLab
The device hits the LiveController Create action with a POST request at v1/live . The LiveSerializer at
app/serializers/live_serializer.rb includes a field called install . To populate this it calls a remaining_install on the
corresponding Player object. This finds the first (see default scoping in Bundle Rules) Bundle Rule where the Player matches all criteria,
gets the corresponding Bundle, and from there gets that bundle's APKs and Frmware.
https://git.videri.com/triage/backend/-/blob/master/dev-guide.md 2/2