I’m reaching out to the community for some advice on the Oracle HCM Cloud / SailPoint IdentityIQ integration.
From what I’ve seen, the standard out-of-the-box connector for Oracle HCM Cloud relies on CSV files to feed data into IIQ. While it works, this feels like a legacy approach that doesn’t quite meet the expectations we can have for a modern Cloud solution.
While it is possible to perform the initial load via CSV and handle incremental updates through ATOM Feed APIs, this approach doesn’t cover our use case as we need to aggregate non-workers as well, full aggregation is required, making CSV files unavoidable.
I’m curious to know:
How are your organizations currently integrating Oracle HCM Cloud with IdentityIQ (or ISC)?
Has anyone implemented or explored the use of a REST API connector as an alternative to the Oracle HCM Cloud OOTB approach?
We are evaluating the best path forward for our implementation, and real-world experience from the community would be incredibly valuable.
@mathieug I didn’t work on HCM integration E2E.. but we were also exploring options to connect via REST. HCM does provide REST APIs and we were planning to use a WebServices Connector and also, they can provide us REST for delta syncs as well.
I am not fully sure how it can be done, but based on our discussions with them it is doable.
We ended up giving up on the built-in connector and created a custom plugin to handle it all instead. I think that Oracle pushed back on how SailPoint was using the API in the previous version of the connector, so it had to be changed to the 3-source convoluted mess that it is currently.
Tips:
It makes life so much easier if you can convince your HCM implementers to promote any useful information about individuals to Person or WorkRelationships DFF and EFF data so you don’t have to, for example: pull Person records, find the link to a Job or Position record from that Person record’s WorkRelationships → Assignments list, pull that record in another API call, find another link inside that Job or Position record, pull that record…, etc.
HCM also has the ability to provision birthright access inside of itself which can conflict with IIQ if you don’t have a plan to deal with it.
The HCM REST API returns a ton of information that you might not want your IAM people, or anyone with access to the service account, to be able to see. Setting up a custom role inside of HCM can hide that sensitive info and PII, but it is a little bit of a pain for the HCM implementers to configure.
There are person/worker records and user records (accounts that do work inside of HCM itself). The built-in IIQ user connector is pretty good, but it doesn’t aggregate things like AoR, so you might need some customization around that kind of things too.
Some of the REST endpoints are buggy:
don’t return results past the first 500 even if there are more.
don’t respect the orderBy query paramenter
don’t respect the q (filter) query parameter
The LOV endpoints can be very helpful, but some of them can be tricky in how you need to call them
There are different version of the REST api that return different results. It’s worth playing around with them to find the right style and default-ish fields that are returned.
Most importantly, the describe endpoint is a very good resource for the actual truth of how the REST api works. The docs aren’t always correct or don’t tell you everything, so something like https://servername.fa.us2.oraclecloud.com/hcmRestApi/resources/latest/workers/describe?expand=all gives extremely useful documentation.
Could you explain in more detail how you replace a connector with a custom plugin? It seems to involve a lot of customization and be difficult to maintain in the long term.
We opened a support ticket to SailPoint to ask for their recommendations and here is their response:
According to the SailPoint documentation, delta aggregation is not supported for changes to non-worker details (e.g., first name, email) in the Oracle Atom Feeds API. The document explicitly states: “A non-workers person details (such as, first name, email, etc) is getting changed. Yes No. The Oracle Atom Feeds API does not support non-workers.”
While the connector supports “All supported scenarios for a non-worker” for joiner, mover, leaver, and account update This specific note indicates a limitation for delta changes to non-worker details via the Atom Feeds API. This suggests that for incremental updates to non-worker attributes, an API-based delta approach is not available through the standard connector’s Atom Feed functionality.
You can use the OOTB Web Services connector theoretically ; the SailPoint IdentityIQ Web Services Connector could be used if Oracle HCM Cloud exposes specific REST APIs that provide the features your team needs, such as delta aggregation for non-workers, which the existing Oracle HCM Cloud connector’s Atom Feed functionality does not support for non-worker details. The Web Services Connector is designed to integrate with applications that expose web services (SOAP or REST) and supports features like account aggregation, account delta aggregation, and various account management operations (create, update, delete). But you will need to perform integration and issues, as the Oracle API side will be out of the scope of SailPoint Support. We will provide Support for issues related to the WebService connector.
@mathieug It means OOTB connector has limitations and recommendation is to move with Webservices, if relevant APIs available. Did you reach out to your HCM team?
If I understand correctly, SailPoint doesn’t recommend the WebServices connector, they simply state that in theory, it should work. It seems to me that it’s actually Oracle that advises against it.
I have worked with a client that has the older version of the connector (Oracle Fusion HCM) which initially relied on /emps endpoint (employees endpoints) which was later soft deprecated.
Oracle silently started throttling the employees endpoints which caused various issues from no data to inconsistent data due to which the authoritative aggregation was ineffective and it had to be paused.
Later connector has been enhanced to use /workers endpoint (workers endpoint), our integration has been updated to use the workers endpoint, which resolved issues and even improved performance but it was short lived, the integration became unreliable again same as with the employees endpoint. We barely made the integration working while the newer connector (Oracle HCM Cloud) is made available, we have gotten an early efix for it, though it lacked the work_email, username write back functionality we have to move to that as the older connector was not at all reliable. After the switch, though it felt like a legacy version it worked reliably, we couldn’t say the same for the older connector.
So I would suggest that though it feels backwards the file based approach is reliable so go with it.
What we have done, as we have somewhat similar requirements as we need to manage non-workers too, we have scheduled the file extracts for every time our aggregation runs.
Few things to be aware of:
The documentation on sailpoint end of how to encrypt the files is incomplete at best, you need 2 pairs of keys, one from iiq, one from HCM: iiq pub key would encrypt the data, iiq priv key would decrypt it, hcm priv key would sign the file, hcm pub key would verify the file.
Make sure to add all the required attributes, and custom schema attributes should end with __c
Thank you very much for your feedback and for sharing your experience @BhuvaneshGeddam, it is very helpful. I’m marking your message as the solution because we’re moving towards that solution.
