I need a sanity check here, hoping someone in this community has successfully setup this source. I have already opened a pending case with SP for vendor assistance but I feel this has to be something I’m just missing or mis-interpreting from the docs.
We have setup the HCM Cloud connector that is a hybrid flat file/ delta aggregation source. The connections for both the SFTP files and the API are fine, viewing CCG logs I can tell the delta aggregations are picking up the changes on the oracle side. However, the attributes it sees as changing are not updating on the account attributes itself. From what I can tell all my attributes are exactly as laid out in the documentation provided by oracle for their atom feeds and worker resource.
Per the docs the changed attributes array is supposedly default and as you can see from the sippet from CCG the response is returning correctly.
My current mapping configuration on the connector setup is below. I blew away all attributes to try and just test this with a few to validate functionality. However, when i run an aggregation i get 0 accounts scanned, no updates at all to the attributes that were stored on the file, and no errors indicating what is wrong.
This is the mapping from the source configuration as current
However, none of the atom feed mappings that you setup in the attribute mapping area for use with the empupdate ATOM feed Generate with a new hire. So, none of the default configurations will pull in first name, last name, addresses etc. Those only seem to appear in the user/userRequests ATOM feed which is not tied to the workers attributes in question for the aggregations.
I can see in the CCG logs for the connector it is aggregating this atom feed, but the data is not mapped to the same name/value pairs or an assumed “Changed Attributes” array like empupdates or empassignments. So how is it supposed to pick up these data points? for example, FirstName is givenName in the user/userRequests/ ATOM feed, and the object body is not the same format as the other ATOM feeds. it makes zero sense to me why this is not explained in the docus anywhere.
If anyone reads this who has successfully set this up I would really appreciate some examples, to me, this simply is not a good replacement for the current hcm connector that is EOL. Unless I am missing something - this simply doesn’t work the way it is described in the documentation.
how is an org supposed to do delta’s after a one time load when the very data that they’re trying to pull doesn’t sit in the ATOM feed in the way that your told to map it from the documentation?
I also see that the ATOM feed for users/userRequests is the only entry generated with this information at a new hire creation point. meaning that the only real way I see this being practical is that newhire entry creates the identity, but then you need to do a getObject to get the rest of the data for a record that was not generated via the flat file load?
How is this supposed to ingest a new record that doesn’t exist in the flat file? You can’t have the flat files running at the same time as delta so its impossible to get fields like Person_Address_Line1 for example, as the user/userRequest ATOM feed doesn’t even make that available as an individual attribute.
The new Oracle HCM Cloud connector has some pre-built setup we should not change, then only it will work as expected.
You should not change the Attribute Mappings, it should contains 13 pre built-in mappings.
You don’t have to edit JSONPath Mapping
You need to add all the required Schema attributes under Account Schema
If you wish to filter any accounts then you need to use the filterString under the connectionAttributes using the Source Update API path endpoint and it should be within ().
If the test connection is failing or you see 0 accounts then enable the Disable Integrity Check option and try once.
If you see any accounts missing in the aggregation, then login into the SFTP server and get all three files(Active, Future, Terminated), decrypt with the PGP keys, and make sure those accounts are present. If not ask the OHCM person to run the Batch Job to get the latest file.
These are all some point I remember when I was on-boarding this application.
While I understand what you’re saying in regards to not needing the Json path mapping area, I do understand its point and it does seem to work to get things like phone numbers that are not stored in the same object where you may need a phone with a different phone type for one schema attribute etc. That part is working, so are single aggs.
Where i’m struggling here is onboarding of a new person, I see no relevant way that the connector is supposed to grab the detail from a delta aggregation, things like firstname, lastname, address lines, phones etc are all stored on the employee during a new hire event. But the API’s being called do not seem to be the right ones to get this data or parse it accordingly, the only data that seems to come in during a new hire agg event is things that come in the EmpAssignment atom feed, so we effectively don’t even have a name (which is the most critical) and no automated way to pull in the extra data either as ATOM feeds are one time logs, so you can’t just get it later with the schedulable functions on the connector.
Are you saying that you were able to get a new hire delta that included these attributes by having only the default? because nothing in the default seems to be the data that I am missing etc. So how would you then create AD accounts or other systems without even a name?
