A sample xml export file, together with relevant clarification of the various elements it contains, is kept in the codebase. See the file src/main/resources/CHAOS_envelope_template_test.xml .
DOMS Export Logic
The basic logic is based on that used in the Broadcast Transcoder Application. It uses a database-backed object-store as a persistent queue/log. Each entry in the persistence layer is a tuple:
(doms-pid, doms-timestamp, last-exported-timestamp, status).
status has values
(PENDING, REJECTED, FAILED, COMPLETE). (For objects in status COMPLETE, the two timestamps should be equal.)
The logic has producer and consumer phases.
- Find the most recent doms-timestamp for objects in status COMPLETE. This is the last consumed object.
- Query DOMS for a list of all objects and last-updated timestamps with timestamps after this (in the relevant Collection).
- For each entry retrieved from DOMS, if there is already a store-entry with this doms-pid, update its doms-timestamp and set its status to PENDING.
- Otherwise create a new store-entry for this object, with last-exported-timestamp set to null.
Fetch from the object-store an ordered list of all PENDING exports and put them in a queue, oldest doms-timestamp first.
\* Note that objects in the bta database are only consulted if there is a shard analysis. Therefore we do not usually expect to find objects missing in the bta database.