Skip to content

6.4.2.7 SourceFeed

6.4.2.7.1 Purpose

One farm's data arriving through one channel, for example a farm's data from its management software. Data is synchronised feed by feed, and each feed records custody: who is responsible for the data, and whether values can be changed before they reach us.

6.4.2.7.2 Questions it answers

  • Through which feeds does a farm's data arrive?
  • Who must fix wrong data at the source?
  • Could the farm have changed these values on the way to us?
  • Which sync client reads the feed?

6.4.2.7.3 Fields

Field Type Cardinality Description
id string (uuid) 1..1 Key.
farm Farm 1..1
source_channel SourceChannel 1..1
name string 1..1
validity Period 1..1 When the feed was connected and disconnected.
reliability_class enum 1..1 Values: official_registry, lab, e_prescription, device_direct, management_software, moonitoring_app, file, unknown.
Default only: a feed can carry laboratory, registry and sensor results; assess record origin/method per SourceReliability.
sync_client SyncClient 0..1 The sync client that reads this feed at the farm. Empty for feeds that reach us without our client (our app, uploaded files, a vendor cloud we call directly). Must work for the feed's farm.
The farm's cloud vendor feeds, which have none, are still listed to its sync clients, read-only, so the client shows them as cards; removing one is disconnecting the feed, with a person's fresh sign-in.
owner_organization Organization 1..1 Who is responsible for the data of this feed and for fixing it at the source.
upstream_editable enum 1..1 Values: no, yes, unknown. Default: unknown.
Can the farm change values before they reach us? e.g. no: our client reads the robot itself; yes: a management software where values can be corrected, a file uploaded by the farm, our app. Origin (SourceOrigin) says who produced a value; this says who could have changed it on the way. The same robot reading has a different answer on a direct feed and on a management-software feed.
created_at datetime 1..1
updated_at datetime 1..1

6.4.2.7.4 Relationships

References

Referenced by

Uses types

Period

6.4.2.7.5 Rules & constraints

  • One farm's data arriving through one channel, e.g. "Bondioli via DairyComp" or "Bondioli via SiAlleva".
  • It is the scope of source record keys and of synchronisation (SyncRun).
  • (farm, source_channel, name) is unique.
  • Set up in the farm sync client: a signed-in Person who holds farm.sources.manage on the farm, signed in at most five minutes before, picks the software among those the client has a strategy for (SourceAdapter), fills its set-up form and tests the connection on the computer; the client then connects the feed with its own sync_client. The Organization Dashboard and the Console show feeds, their runs and integration gaps and set up nothing; the Dashboard can pause a feed through its schedule (SyncSchedule.enabled).
  • Credentials: what the client needs to read software on the farm, as a database account, stays on that computer, in the operating system's credential store of the client, and never reaches Moonitoring.
  • A vendor cloud that farm itself pulls, such as the milk recording of AIA, is set up in the client too, with the same catalogue and fresh sign-in: the client creates the feed without a sync_client and sends its credential once to the secret manager, keeping no copy; farm's vendor puller uses it, and it is never returned.
  • The secret is named farm-feed-<id>, after the feed: every secret name starts with the system that owns it.