Trouble pulling Workers and Departments from Workday

Tim Deniston · ‎10-29-2019

I am working on an integration between Workday and ServiceNow (New York). I am using the pre-Madrid Workday integration config, but added v32.2, which was the latest version of the API on the Workday side as of when I started this effort. I updated the HR Integrations Schema Mapping records to support v32.2 and created some new ones where the keys changed between Workday versions.

The data imports go in this order when I kick off the scheduled job: Departments > Locations > Job Profiles > Work Profiles > Effective Worker Profiles > Future Worker Profiles.

Issue 1: Departments
Watching the job tracker, I see that there are 2000+ department that the integration is trying to send over, but they are all ignored prior to making it to the staging table. So... they data is in the XML that SN receives, but it's all being skipped and doesn't make it to an import set.

Issue 2: Workers/HR Profiles
Also when I watch the job tracker, the Worker Profiles row always shows 0 records. I use the same envelope in SoapUI and Postman and can see all the records, but it's not working in ServiceNow.

I have enabled debugging via the Source record's related list (sn_hr_integrations.debug) and there are LOTS of logs, including every bit of XML from the Departments service. The Get_Workers service does not show any XML in the logs.

I am able to successfully pull in and transform Locations and Job Profiles, so I don't believe it to be an access-related issue (otherwise I wouldn't be able to use Postman to see the data).

Has anyone seen these issues before? Does anyone have suggestions on how to fix?

(I have a HI ticket open, but I'm getting desperate, as this is holding up some other work.)

Tim Deniston · ‎11-12-2019

Regarding the Worker import, I found that there was too much data being pulled for each worker and the request was timing out. There was nothing in ServiceNow's logs to indicate this even though the import was running in debug mode.

I decreased the amount of data for each worker by setting the following Response_Group properties in the request:

<bsvc:Include_Personal_Information>true</bsvc:Include_Personal_Information>
<bsvc:Include_Employment_Information>true</bsvc:Include_Employment_Information>
<bsvc:Include_Management_Chain_Data>false</bsvc:Include_Management_Chain_Data>
<bsvc:Include_Organizations>true</bsvc:Include_Organizations>
<bsvc:Include_Transaction_Log_Data>true</bsvc:Include_Transaction_Log_Data>
<bsvc:Exclude_Organization_Support_Role_Data>true</bsvc:Exclude_Organization_Support_Role_Data>
<bsvc:Exclude_Cost_Center_Hierarchies>true</bsvc:Exclude_Cost_Center_Hierarchies>

This took the number of characters (not sure if that's a valid measurement) for each worker from greater than 2,000,000 to about 75,000. It's kind of crazy that that much data was being pulled across, though the vast majority of it was unnecessary in the end.

I also adjusted the number of records using the Count property in Response_Filter.

<!--before-->
<bsvc:Count>50</bsvc:Count>
<!--after-->
<bsvc:Count>25</bsvc:Count>

The import is now running well and I'm getting all the data I need.

View solution in original post

Dsinghal · ‎11-04-2019

Regarding departments - is it due to the fact that the system does not see any difference between what is there in the system already and the data payload?

For workers can you try running the SOAP request directly from ServiceNow using navigation "HR Integrations --> HR Web Services --> HR SOAP Services" and check if the data payload is returned.

Tim Deniston · ‎11-07-2019

Through much trial and error, I was able to determine that the Worker load was not showing any data because it was trying to pull too many records at one time. Backing this down to 10 has allowed it to go through.

I had Departments at least loading data into the staging/import set table (I think after adjusting some XPATHs that changed from one version of WD API to the next). It wasn't pulling all the right data, though, so I adjusted all the XPATHs and verified them at xpather.com against an actual payload. They are all working, but once the import is running in ServiceNow, it still shows that there are 2300+ department records, but none of them land in the import set table.

I also reverted to v30.0 of the integration, as that is what ServiceNow said is the latest supported version.

Tim Deniston · ‎11-07-2019

To push me closer towards a resolution, I found that SN's XPATH evaluator may be more picky about syntax:

//wd:Organization_Data[wd:Organization_Type_Reference/wd:ID[@wd:type='Organization_Type_ID']/text()='Cost_Center']/wd:Organization_Code

does not work in SN. This is how it would need to be:

//wd:Organization_Data[wd:Organization_Type_Reference/wd:ID[@type='Organization_Type_ID']/text()='Cost_Center']/wd:Organization_Code

(The difference is that the @wd:type should be @type even though tools like xpather.com can handle it.)

SUSHMA PINNINTI · ‎05-24-2023

Hi Tim,

We are facing issue while fetching Address_data from workday into servicenow. As confirmed by workday team by default most address have private flag. And our request have been configured to consider :- defaulted_business_site_address = 0

As in the request:-

/wd:Worker/wd: Worker_data/wd: Personal_data/wd:Contact_data/wd: Address_Data[@Dealfaulted_business_site_address = '0']/wd: Address_line_data

How to pull those private flag addresses along with public flag addresses into servicenow from Workday. Please help me

Tim Deniston · ‎05-24-2023

First off, I would recommend posting your question/issue into its own thread. That will be the best way to get more eyes on it.

I believe private addresses are accessible in the Workday > Human Resources > Get Workers operation, but probably only if the account you're using has access to see them. From what I can see, the identifier that shows whether the address is public or private is here:

<wd:Usage_Data wd:Public="0">