Connector¶
Overview¶
A Connector is a middleware software which is responsible to contain everything necessary to integrate ATS systems and the Video Interview Suite. The reason behind it is to keep both the ATS and the interview suite clean of the conversion logic and keep all that logic in one single and isolated environment, synchronizing data, converting different data types and user roles, etc.
Architecture¶
As the diagrams below illustrate, the starting point is to recognise the 3 components: ATS, Connector and the interview suite, where the ATS and the interview suite are systems that keep each their own approach and business logic, while the Connector is a middleware, responsible to bridge between both, converting and syncing data. That means the integration is done by nearly 100% in the Connector side, with no needs (usually) in ATS and interview suite sides.
The main expected pieces in a Connector are:
- interview suite API consumer
- Webhook endpoints
- Synchronization logic
- Equivalence/matching table
- Integration Frontend
interview suite API consumer¶
It’s basically about to authenticate in interview suite API as a user and persist or retrieve data to/from it. Authentication is still to be defined but it will be either OAuth2 based on a token (authorisation code) or SAML2.0 server side.
Webhook endpoints¶
For every relevant event happening in the interview suite, a request is sent to registered Webhook end points. The end points are URL which are publically available, under SSL certificate (HTTPS, can be a self signed certificate) and must be registered for such company in the interview suite.
These webhook endpoints will be called every time a Project is changed or deleted, the same for Candidates, Ratings, etc. and that will allow the Connector to synchronize data back to the ATS or even make decisions regarding to certain business logic.
Synchronization logic¶
This is the piece of software responsible to synchronize Projects, Candidates, Applications, Users, etc. between the ATS and the interview suite, back and forth.
For ATSs supporting their own Webhooks, it can be that Connector implement endpoints to respond to them. That’s the ideal setup as it’s lightweight and more real time behaviour.
For ATSs without support for Webhooks themselves it will be necessary to implement a bot running every N minutes to synchronize data from ATS to the interview suite API.
Equivalence/matching table¶
For synchronization, it’s necessary to maintain a small local database with tables for equivalent IDs, matching IDs in ATS with their respective entities in the interview suite.
Integration Frontend¶
These are public URLs to be used as IFrame, Popup windows or just links as part of the ATS interface, representing interview suite information for the ATS user.
It’s important to point out that these aren’t replacing the interview suite screens but only representing what can be seen by a user when they are in the ATS interface and that shows (if supported by their SDK) pieces of the interview suite as they must be for that specific ATS.
For example: when a user is in the ATS interface, in Job Requisition page, an iframe will point to a URL in this “Integration Frontend” to show “Video Interview Questions”, which in the interview suite are attached of a Project respective to such Job Requisition.
If an user wants to see the whole project as it is and administrate or evaluate candidates, the recommended interface to use is the standard interview suite system.
Workflow¶
Ideal Setup¶
When the ATS supports webhooks for Job/Requisition/Project/Application/Candidate changes.
Static Setup¶
When the ATS hasn’t support for Webhooks, which obligates the Connector to run a periodic synchronization worker.
Quick Setup¶
The third alternative is to use the interview suite interface directly via SSO authentication method and implement only the background bits of the connector. That means a link in the ATS will point to a URL in Recruiter system and open a popup or new tab with such page. The authentication will be granted via SSO (SAML2 or OAuth2) and the user can use the standard interface. That’s quicker to implement and easier to maintain.
