As a consultant who spends a significant amount of time working on HRSD projects, I often find myself face-to-face with a Workday integration. I cut my teeth with the old HR Integrations application, which included a Workday integration (among others). ServiceNow has since released a new version of the Workday integration that might be easier/better/faster/whatever, but I haven’t used it yet. (The organizations I have worked with have an existing Workday integration and don’t want to spend the project dollars on rebuilding something that’s already working and doesn’t appear to be going anywhere, even if it would mean that the Workday sync would take less than 3/4 of a day.)
Workday, for some reason, only has SOAP APIs by default. They do offer REST endpoints, but only if a custom Report as a Service (RaaS) is built, which, in my experience, requires a lot of technical know-how on the Workday side. (I’ll cover my experience with Workday RaaS and REST in another post.) The Workday SOAP API docs for the Human Resources web service can be found here (other versions here). They are a good reference, but mostly it’s a bunch of jargon that assumes that you’ve already taken the 100- and 200-level classes on Workday and web services. I haven’t, so I don’t pay much attention to those API docs.
Except, that is, for when I get an itch about the WD integration for a customer taking 17+ hours to complete due to the amount of (useless) data that comes back for each worker. So, I’ll dig into the Response_Group parameters only to come to the conclusion that the existing integration is already optimized as much as possible based on the data that the organization wants to import. But I digress.
SOAP is a giant pain in the ass at best, if you ask me. Which brings me to the purpose of this article. It’s not so much about using SOAP in ServiceNow to import Workday data, but rather how to speed up the process of getting the right data, parsing it, and extracting it efficiently. Let’s take a look at the tricks and utilities I have found that will expedite SOAP-based integrations for Workday and ServiceNow.
Response_Group – Fire Hose or Garden Hose?
I mentioned Response_Group earlier, which is a Workday SOAP parameter that allows you to somewhat restrict the data that’s coming back. It doesn’t allow you to get granular with the data elements that are returned, but rather like chunks of data. Imagine going to the library and wanting just the pages from the encyclopedia for the Human Genome Project. But instead of just getting those pages, you have to grab the whole H book. That’s what Response_Group does for you. (At least it lets you get a single book, not the entire encyclopedia set, I guess.)
Determining the right combination of Response_Group parameters can be challenging, as some will enable an information chunk and others will enable even more, but then others will restrict some of the information that was just allowed via another parameter. It can be quite confusing. The latest version of the WD SOAP API has over 60 different Response_Group parameters!
The first thing I do when trying to determine which Response_Group parameters to use is fire up Postman. I won’t get into the full logistics of using Postman here, but the basics are that you need to get the Workday SOAP function from the SOAP Message in ServiceNow, drop that in the body of a new request in Postman and set up authentication. Within the body, you also likely need to add the Request_References parameter and apply a value (likely an employee number) to the parameter that will limit the response to just a single worker (or maybe a handful) to start. This will greatly speed up the process of reviewing the data and analyzing it.
<bsvc:Request_References bsvc:Skip_Non_Existing_Instances="1">
<bsvc:Worker_Reference bsvc:Descriptor="">
<bsvc:ID bsvc:type="Employee_ID">900001234</bsvc:ID>
</bsvc:Worker_Reference>
</bsvc:Request_References>Repeat the middle three lines as many times as you want. You can also substitute “Employee_ID” for “Contingent_Worker_ID” if contingent worker data needs to be reviewed.
Once you have that, send a request and review the results. If you need more data, add some Response_Group parameters or take some away. It really is a trial-and-error situation until you find the data you need and nothing more. Postman will help expedite the process and make it much easier and faster to iterate.
XPath
This might be the most confounding yet exciting part of the entire process… determining the right XPath query to extract the data you need. Finding good resources for writing XPath queries can be challenging, especially since you might find a resource that strictly sticks to the XPath 2.0 standard, but ServiceNow uses XPath 1.0 or something (I don’t honestly know… I can’t find any place that identifies the version ServiceNow uses). I typically end up grabbing the XML from Postman and dropping it into XPather. I was leery of doing this at first, but after watching the browser’s dev tools, I found that nothing is sent back to a server unless the Save button is used. Cool!
Once in XPather, using the CTRL key and mousing over a node will automatically populate an XPath query to that points to that exact node. This isn’t the end, though… you’ll need to adjust the query to be more precise. Adjusting the XPath query at the top will allow for rapid iteration, as the results are immediately shown on the right side of the page.
The other tool I use when writing XPath queries is this XPath Cheatsheet. It contains a lot of features that I’ve never needed, but specific syntax hints on that cheatsheet are really helpful.
Also when in doubt… just copy and edit one from the existing schema maps in ServiceNow. 😋
Conclusion
This post probably has the least likelihood of being helpful in the future since ServiceNow has a newer version of the Workday integration that everyone should be using by now (the old one was deprecated after London, I think). But, with the right tools, we can hopefully keep the existing legacy integration fresh for years to come.