Toggle document index

Overview

The data migration APIs are used to export and import categories, jobs and users between tenants.

The roles of each app

The ATS:

  • is the source of truth for the data objects: categories, jobs and users
  • provides low level API access to CRUD the data objects
  • notifies replicating apps of changes to the data objects via delta pings
  • maintains a journal of remaps (i.e. delete of one CV and transfer of all associated data objects to another)
  • deleted CVs can still be accessed by id (and may include a remap CV)

The Uploader app:

  • provides high level, long-running upload-style APIs for the data objects (e.g. pass the entire list of all active users in one API call)

The Category Editor app:

  • is a drag and drop editing interface for category values
  • users can delete a CV, and also first transfer all its data objects (jobs etc.) to another CV

API flow to/from your app

Category manager UI

This section shows the API flow when using the category manager to edit values of a category in the ATS - e.g. removing the "Data Sciences" in favour of "IT".

Changes like these may affect objects such as jobs in the ATS, e.g. in this example, all jobs that were previously Data Sciences will now need to be re-categorised as IT.

Since it is the source of truth for jobs, the ATS also informs other apps that care that jobs have been updated.

As the master record holder for categories themselves, the ATS also informs any other apps that care that category values have changed.

Apps that care would include e.g. a career site app might have its own employee testimonials objects where Jake says how great it is to work in the Data Sciences team at Acme.

That testimonial would be pinned to the career site's own copy of the Data Sciences category value (within the IT category). By listening to updates from the ATS, the career site is able to transfer Jake's testimonial from Data Sciences to IT.

note right of catman: user clicks on an existing node\nto learn more note right of catman: catman asks apps what they\nhaveto share catman->ats: POST /categories/byID/{}/values/byID/{}/summary catman->careersite: POST /categories/byID/{}/values/byID/{}/summary note right of catman: user creates a new CV catman->ats: POST /categories/byID/{}/values note right of catman: {"name": "Birkenhead"} note right of ats: ats notifies replicating apps ats->careersite: POST /categories/byID/{}/values/byID/{}/deltaPings note right of catman: user drags Takapuna (1001) onto North Shore (1003)\ni.e. inactivate + remap of a CV note right of catman: catman asks apps what they\nthink of the change catman->ats: POST /categories/byID/{}/values/byID/{}/changeImpact catman->careersite: POST /categories/byID/{}/values/byID/{}/changeImpact note right of catman: catman performs the change catman->ats: POST /categories/byID/{}/values note right of catman: {"id": 1001, "available": false, "remappedTo": 1003} note right of ats: ats updates jobs,candidates, users, etc.\nand informs downstream apps of the changes ats->careersite: POST /jobs/open/byID/{}/deltaPings ats->careersite: POST /jobs/open/externally/byID/{}/deltaPings note right of ats: ats informs downstream apps of the\nchanges to the category values themselves ats->careersite: POST /categories/byID/{}/values/byID/1001/deltaPings

Upload app

The upload app provides a bulk way to synch up category values.

note right of someapp: some app fires in an upload someapp->uploader: POST /categories/byID/{}/values/uploads note right of uploader: uploader fetches current\nCVs from ats uploader->ats: GET /categories/byID/{}/values note right of uploader: uploader uses discrete APIs\nto insert, update or inactive\nCVs in the ats to match uploader->ats: POST /categories/byID/{}/values (create) note right of uploader: {"name": "Newtown"} uploader->ats: POST /categories/byID/{}/values (update) note right of uploader: {"id": 20045, "name": "Brooklyn"} uploader->ats: POST /categories/byID/{}/values (inactivate) note right of uploader: {"id": 87544, "available": false} note right of ats: ats notifies replicating apps\nof changes ats->careersite: POST /categories/byID/{}/values/byID/{}/deltaPings

Career site is installed and tracks CV changes

The careers site maintains its own replicated copy of the tenant's categories and category values.

note right of careersite: app is installed, initial load careersite->ats: GET /categories careersite->ats: GET /categories/byID/{}/values careersite->ats: GET /categories/byID/{}/values note left of ats: the ATS alerts replicating\napps of changed or deleted CVs ats->careersite: POST /categories/byID/{}/values/byID/{}/deltaPings note right of careersite: the replicator grabs CV's new state,\nincluding remap info careersite->ats: GET /categories/byID/{}/values/byID/{} note right of careersite: replicators maintain cursor of\nlast delete

Career site comes back up after restart

While the app was asleep, there may have been changes made to the CVs.

Its not enough to just call GET /categories/byID/{}values, since that only returns values that are available. Other values may have been made unavailable while we were down, and they may have remap info that we need to know about to transfer our objects across from the inactivated CV.

Another API is used to fetch the latest entries from the journal of remaps.

note right of careersite: check for missed deletes (with remap info) since checked careersite->ats: GET /categories/byID/{}/values/remapped?seqGt=22 note right of careersite: and fetch the current state of the CVs careersite->ats: GET /categories/byID/{}/values/remapped?seqGt=22