We’re currently seeing an issue where certain fields populated in Workday are not being pulled into SailPoint. For example, Email_Address_Home is populated in Workday (under the Contact Card of the worker), but it is not flowing into SailPoint.
The schema attribute and XPath we are referencing is:
To troubleshoot, I downloaded SoapUI and attempted to connect to Workday using the WSDL. However, when making a Get_Workers call, I receive a “username and password invalid” error. The credentials are confirmed to be correct, so I’m unsure why authentication is failing.
Could someone advise on:
How to determine the correct schema attribute and XPath for fields that need to be populated in SailPoint?
Why the SOAP call might be failing despite valid credentials?
Any recommended approach to validate and troubleshoot additional fields that are not syncing from Workday to SailPoint?
We are seeing similar issues with several other fields as well, so any guidance on a way to validate the mappings would be greatly appreciated.
This is what we have on a SaaS connector. Note that the namespace difference isn’t a concern, the VA connector uses ns1 where the SaaS connector uses wd. Keep using ns1 and don’t use wd
To me it looks like you are filtering out anything that is public. I’m guessing this might be considered private data so you may want to remove the Public being true.
As to the connectivity issue, soap calls might require you to do the username@
To troubleshoot missing Workday attributes in SailPoint ISC, first verify that the field is returned in the Workday Get_Workers API response using SoapUI. If the attribute is not present in the API response, SailPoint cannot retrieve it. Next, validate the XPath mapping and ensure the attribute exists in the SailPoint source schema. After updating the schema, run aggregation again. For the SOAP authentication issue, confirm the correct Workday endpoint, tenant name, and WS-Security configuration.
I did try the username@tenant and still isn’t working via soap UI. I tried it with CURL command with same credentials and it is working.
This is the error I am getting in soapui
<SOAP-ENV:Envelope xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/”> SOAP-ENV:Body
<SOAP-ENV:Fault xmlns:wd=“urn:com.workday/bsvc”>
SOAP-ENV:Client.authenticationError
invalid username or password
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
I’m using the same endpoint and credentials that are configured in my Workday source. I’m appending ?wsdl to the end of the URL so I can import it into SoapUI. I am not sure what else I am missing because the creds are working in my workday source
What AuthN mechanism are you using? If username password, then you may need to construct a soap security header in the payload, not http header, if you’re not already. AFK at the moment, so can’t provide an example
One thing on the credentials is that on the endpoint configuration in SOAPUI you do need to select “PasswordText” for the “WSS_Type” value. Maybe you already have that but I know that caused me some grief initially when setting up my Workday connection.
In terms of the WSDL… I dont remember exactly how I got there but there was a URL I was able to enter that basically gives information on the back end interfaces (Maybe interfaces is not the right term but it might be enough to jog someone’s memory) in Workday and on one of those there was a link to download the WSDL. I think we had to have our Workday support team reach out to Workday support for those directions. Maybe your Workday support will know or can reach out to support if needed.
The “No Authorization” part is correct. The only thing I see thats different in my setup is that I am specifically calling an API version (v32.0 in my example). The only other thing is your request is not really formed properly, it should be searching for a particular worker and yours still has the ? in there. I dont think that either of those would produce the invalid username/password error but its worth a try. Outside of those I dont see anything else that looks off.
