Hi! Client has a propietary HR system that we want to use as an authoritative source. System is cloud, and it has a rest API, but in order to retrieve all users with their detail, several calls has to ve performed, like:
-getEmployees: get employees basic details
-getEmployeesOnVacations: retrieves employees that are on vacation TODAY
-getLeavers: retrieves employees that left organization LAST MONTH
As seen, some logic is needed in order to get employees FULL detail as ISC expects. I am wondering if SaaS Connectivity connector can be avoided, is it possible through a web service connector, or does this logic exceeds its limits?
Hello julian, what i understand yes you can do different API calls form a webservice connectors to retrieve different type of employees and also depending on the lifecycle of the employee
If I understand the requirement correctly, a web services connector should be able to do this. You could try doing multiple get employee operations, which will daisy chain those calls. Or you could try a before rule.
Hi Vincent, I found little documentation on multiple endpoints on documentation. I understand that we can have 3 endoints, one for retrieving employees (for example, a, b, c and d), other endpoint for retrieving employees thar are on vacation (for example, b and d) and other for retrieving leavers (for example, c). My doubt is how I can consolidate these responses in only one, like this:
a - active
b - vacations
c - terminated
d - vacations
Have you checked out this documentation on Multiple Independent Endpoints for aggregation? You basically can setup multiple account aggregation operations as needed and they will run in their respective order. Ensure that all of the attributes in each operation’s response mapping are in your account schema.
Hi Zach & Vincent
Have you ever made that to work?
I’ve two independent endpoints that I need to utilise to pull back all my users, and only the 1st one aggregates. The 2nd one doesn’t even start.
Tried chaining, just for giggles and that really doesn’t work.
Phil
EDIT: Don’t know what I did, but the chaining started working for the independent endpoints. The schema is massive as each endpoint has differently named attributes for the same values, but it all works
End point 2: returns only employees on “vacation“
End point 3: returns only “terminated“ employees
not like :
Case 2:
End point 1: returns all “employee“ basic data
End point 2: returns only “active” employees using something like emp id from 1
End point 3: returns only employees on “vacation“ using something like emp id from 1
End point 4: returns only “terminated“ employees using something like emp id from 1
if its case 2, you sure can (should. don’t even think of other options even if there are ) do as Zach pointed.
but if its case 1, options I can think of are :
option 1: have 3 sources and have transform on each identity attribute to build identity profile. painful to build and probably painful to maintain too.
option 2: Before prov rule to make 3 calls to each end point and built RO.
option 3: your own custom connector which is going to be almost same as option 2
) do as Zach pointed.