Hello,
It appears that SailPoint’s built-in connector for UKG Pro Core HCM calls a specific API endpoint (Employee-Changes) that is the only API endpoint which has a rate limiting on it.
I am wondering how others with a UKG authoritative source have dealt with this? Do you just leave it? How does it effect the timeliness of your lifecycle states? Did you end up switching to a Web Services connector and build out the API connection yourself?
We scheduled the aggregation for every 6 hours and worked within the limit of the API. If there was a change made in between aggregations, we run one manually. I’m sure you can build a WebService connector if you absolutely have to run, say, every 1 hour, but I’d recommend seeing if you can work with the stakeholders to align on every 3 hours so that you can take advantage of OOTB features and not have to worry about maintaining your own connector
When you say ‘run one manually’ do you mean you just go manually change a lifecycle state? Or that you run an aggregation to get one of the additional syncs inside of your 6 hour window?
I was able to get in touch with UKG’s API team and received the below response. Is there any plan on SailPoint’s side to update (or at least release a v2) of the connector?
Apparently it is still referencing one of their older APIs, which is the problem.
This API generates a table that can be queried, and the limit is how often that table gets updated. So you can query however often you want, but that data won’t be updated until 3 hours after the last generation. 10 years ago, when this API was created, the concern was that if this API was allowed to constantly regenerate that table, it would affect system performance.
Other APIs more recent (better hardware in our datacenters), or just query data directly from the database, so rapid querying does not affect performance.