XVault Operational Behaviour

Data Requests

XVault works by requesting data from schools, driving the collection of data.  It is possible for schools to transmit change events to XVault in some configurations however since these are saved in the same way as responses to data requests the discussion of events is outside the scope of this document.

 

Collection Templates

XVault supports definition of multiple Collection Templates and allows a school to be assigned to a single Collection Template at any one time.  A Collection Template defines a set of SIF objects to request, any filtering criteria on those objects and the request frequency for each object.

 

New schools

When using Groupcall Data Broker Services with XVault any new school registering with Data Broker Services will be, by default, shown as a new school in XVault within around 60 minutes.  A default Collection Template is typically applied to such schools that requests only SchoolInfo, which is an object providing school summary details such as school name, statutory reporting identifiers and school contact details.  This Collection Template is used to confirm the school is working but not to risk data exposure, by virtue of only requesting public domain information.  A new school should be switched over to a more suitable Collection Template once confirmation of school consent has been double checked.

 

Data import and retention

XVault operates a data deletion policy that effects after the completion of response processing, it operates at a SIF Object level per school.  When a response is received for a SIF object for a school XVault calculates a checksum of the data and compares it to the checksum in the XVault database, if the value matches then the lastReceived column is updated accordingly and no further action is taken; if it doesn’t match then the record is updated and the lastModified column is also updated.  In the case that a new record is created the createdDate column is similarly set.  This applies for every row of data in the XVault database.

Once XVault has finished receiving a response for a SIF Object in a zone it then seeks all rows that have not been touched in some way, and considers them for deletion.  This consideration takes into account a soft-configuration value in XVault determining how long to retain objects for after they stop appearing in responses.  For any object with lastReceived before that threshold point the record is deleted.  This auto-deletion mechanism effectively provides a configurable period where records no longer presented by a school are eventually expired (and removed from the XVault database), without causing data deletion for schools that are experiencing e.g. a loss of service and are not returning any data at all.  The threshold value is measured in hours and can be set to immediate deletion, the default of 48 hours, or disabled and this can be done on a per SIF Object basis.

Where an event message is received from a school regarding the deletion of a record from the MIS data source, XVault will apply that change immediately regardless of the retention settings.