Is this still slated to happen on 12/31/24? from what I can discern the replacement connector provides no feasible way to use delta aggregation to onboard a new identity.
The CCG logs from the HCM cloud replacement connector indicate it only gets the following data from the ATOM feed for a new hire
“Context” : [ {
“PeriodOfServiceId” : “300000297419686”,
“PersonName” : “Sparrow, Jack”,
“PersonNumber” : “214176”,
“PrimaryPhoneNumber” : “”,
“PersonId” : “300000297400893”,
“PeriodType” : “E”,
“WorkerType” : “EMP”,
“DMLOperation” : “INSERT”,
“EffectiveStartDate” : “2024-12-26”,
“EffectiveDate” : “2024-12-26”
} ]
So attributes like FirstName LastName, addresses, phones etc. are not available here to map to the identity that is created. The only Atom feed that contains this information would be an empUpdate entry which is not actually a generated atom feed during a new hire found event, like empassignment is, This ATOM feed event is something sailpoint had us enable based on the connector setup docs, but this feature is not available with empUpdate to trigger on ‘new hire event’ like the former, so how is one supposed to get personal information into sailpoint that would be stored on the employee record from oracle?
From reviewing copious CCG TRACE aggregation logs during a delta it makes no calls to the workers API when a new hire is found either, so effectively no personal information data is actually able to be mapped into a new identity with the delta aggregation. Unless I am missing something here, despite the docs stating that delta aggregation fully supports joiners, it does not support joiners, meaning the only valid option is full aggregation every time you need new employee information, or running a manual getObject single aggregation by hand to populate that data.
that said, I see that the connector does attempt to aggregate the ATOM feed user/userRequests where some of this data is supplied, but not in the same data model as the connector expects with Changed Attributes object and corresponding ATOM feed attributes, it’s an XML and its not parse-able with the current UI configs per my understanding as atom feed attribute UI defaults to ChangedAttributes[*].new on the backend, not to mention that it uses entirely different attribute names like givenName versus FirstName.
I’m not sure how this connector REST only version can cease to exist when the replacement doesn’t provide an automated way to get a new hire from Oracle, is Sailpoint just expecting us all to run export files constantly to get new hire information? That seems to defeat the purpose entirely.
It is very common to have a new hire daily within our organization, and in order to provision birthright accounts, i see no indication that a new identity can be properly delta aggregated into Sailpoint with the connector that supposedly replaces this?
I have been tirelessly trying to find the answers to this through tickets and escalation and I find it very concerning that it seemingly doesn’t work as advertised and nobody can answer my questions. The documentation on this is very barebones regarding examples and explanations as well.
This is a reminder that Oracle Fusion HCM connector is scheduled for End of Life(EOL) dated 31st Dec 2024!