Movement: consignment should be referenced as an ID, not embedded

[Traksewt]

Currently in arrivals and departures, the consignment is embedded in each animal. The consignment refers to a set of animals. This means that all animals will have the exact same consignment data embedded. This does not scale well as the number of animals transported increases.

It also adds more complexity in handling, ie what does it mean if 1 animal has slightly different consignment data to the others yet appear to be part of the same group?

We believe consignment should be created once, and referred to (e.g. by ID) for each animal in the arrival/departure.

[cookeac]

At face value, this proposal seems good:

1. Consignment is meant to model a consignment of multiple animals moving together.
2. Where a consignment maps to an official livestock registration and movement service (such as NLIS), its ID should map to the ID under that service, so again it should be unique for that transaction.

The primary reason why the ICAR team were hesitant about this is the additional API complexity this implied. It would imply that an implementer would need to provide separate API(s) to GET the consignment (and possibly a collection of consignments? this is not as clear).

For an application using the API to post data to a server:

• Ideally there would be a "session" type API where data could be posted simultaneously for multiple animals being moved.
• If this was not the case, then a POST API to add a consignment would be necessary first, followed by POSTing the individual animal events that referenced that consignment.
• If the API is implemented by a movement service itself, care would need to be taken about validation and issuing IDs - this is where a "session" or batch type of API would make things much better.

We will definitely need to justify this one to the ICAR ADE working group.