CSV to Workday Tenant
Submitted by @stodoroska from Interworks This pipeline reads a CSV file, parses the content, then the Workday Write Snap is used to call the web service operation Put_Applicant to write the data into a Workday tenant. Configuration If there is no lookup match in the SQL Server lookup table, we are using MKD as a default code for country code. Sources: CSV file on the File share system Targets: Workday tenant Snaps used: File Reader, CSV Parser, SQL Server - Lookup, Mapper, Union, Workday Write Downloads CSV2Workday.slp (17.3 KB)
Change Data Capture from Workday
This is often a requirement from a variety of Workday customers to extract data within a time range i.e. extract data that was changed 7 days ago or 2 days back or even within the last day. Classic examples are: Terminations within last 90 days or 30 days New hires for the next 7 days who were entered within the last 7 days All active and only terminations within last pay period or 15 days It is very easy to accomplish this. Attached is a sample pipeline that extracts worker data whose preferred name changed since last July 2016. Obviously you can parameterize these date ranges and make this a batch job that runs every night or morning. The most important thing is to understand that Workday provides something called Transaction Log which keeps a track of all transaction changes within workday. Note that Workday keeps changes as part of transactions and every change has an underlying transaction which is basically identified by Transaction Type Listed below are some things you can refer for easy development of integrations. WKD_TRANSACTION_LOG.SLP - a simple pipeline that gives changes in preferred names since Jul-2016 Workday Community Documentation Reference: Workday Resource Center - Sign In Listed below is the mapper which tells the workday read snap on what changes to extract Attached is a sample pipeline. WKD_Transaction_log.slp (6.6 KB)
How to get JSON node which cause Workday webservice error under Workday Write response message?
Hi Everyone, In SOAP UI/ Workday Studio’s SOAP response, we usually get Web Service(WS) error xpath which tell us the node/XML xpath cause webservice error. This xpath allow developer to understand which section of WS request cause the error. Example of SOAP response having error: wd:Validation_Error wd:MessageInvalid ID value. ‘BUSINESS ASSE’ is not a valid ID value for type = ‘Location_Usage_ID’</wd:Message> wd:Detail_MessageInvalid ID value. ‘BUSINESS ASSE’ is not a valid ID value for type = ‘Location_Usage_ID’</wd:Detail_Message> wd:Xpath/wd:Put_Location_Request[1]/wd:Location_Data[1]/wd:Location_Usage_Reference[1]</wd:Xpath> </wd:Validation_Error> Similarly, I am looking for specific node which cause any webservice error when Snaplogic’s Workday Write snap execute. Unfortunately, current Workday write does not give such node details in SOAP request that causes WS error. Getting such JSON node or Xpath location will help my business scenarios which needs to identify specific address section that causes WS error for Put_Student_Application. Under this web service, Workday allows us to add different types addresses related to student including friend and family (like, mailing, permanent, parent address etc.). Below is error message of Workday Write: From above error message, we are able to get error description and suggested resolution but it does not give any information regarding which address section (either personal mailing, permanent, parent address etc) cause said WS error. Kindly advice if anybody came across such scenario and how we can handle such cases. Regards, Sandeep Meitei
Sample for Mapper and Workday Writes that include multi instance fields and nodes
Does anyone have any samples or tips for mappers and using the Workday Write snap for Multi instance fields? In XSLT, we use apply-templates to copy this…but would like to see how this is done within SNAP. Thanks in advance JeromyWorkday Account Creation
Here are few steps on how to create a Workday Account for the Workday Read and Write Snaps. There are some important facts that you must know in order to create a Workday Account in SnapLogic. Here is a screenshot of the basic Workday Account Creation dialog box As you can see, there are some important fields. Label: An account Label for you to easily identify this Workday Account. This will be visible in your accounts section. Username: The Workday Account User Name (Typically an ISU - Integration System User) through which the workday connection is made with proper security configured on that account. Password: The workday account password Version: Typically the latest version just in numbers. As of this writing, it is “28.0” (Quotes not needed) Your Tenant and Host follow a combination of details assigned to you by Workday. Tenant: Typically a tenant name is assigned and allocated by Workday. During implementations, it will have _impl<1> as a suffix as negotiated during the implementations. The tenant name is usually a negotiated acronym during the Workday Implementations. Every environment has a different tenant name as is a general practice in multi-tenanted environments. So, be sure to find out the tenant name and environment you are connecting to. Host: This is often a quirky item where there is a lot of confusion. This is no different if you have already connected to Workday using Workday studio, EIBs etc. Typically Workday has multiple data centers and each customer is assigned a data center and a disaster recovery data center. So the host name is generally established during the implementation phases. As of this article’s date, Workday has 3 data centers and their respective derivation of information is as follows. These are directly quoted from Workday Community websites and can be verified if you have access to the Workday Community. 1. Portland 2. Ashburn 3. Dublin Remember that host name determines where and which environment you are connecting to. These vary during implementation times before you are in production and will change significantly after you are in production The other way you can get the host name is from the REST or Workday URL from a custom report developed in Workday. Once you have the custom report, click on Actions–>View URLs–> Copy the hyperlink for the Workday or Rest or any other URL on that page. The host name is the first part of the report URL. Hope this helps a bit in configuring the account for Workday. You can use the Workday Dynamic Account in case if you want to use variables to determine your connection details. The Dynamic Account supports Expressions.State Department Per Diem Rates to Workday Import Expense Rate Table
Pipeline sample that grabs per diem rate data from State Department website and imports it into Workday Rate Tables. It gets a little complex as far as the data mapping and filters, but cuts down on tedious manual maintenance of these tables. We run this once a month. There is definitely room for improvement like adding some validation checks. One big issue is that the import is all or nothing; if a single record doesn’t match between the State Dept. spreadsheet and Workday, it fails. Also, the Workday call itself always returns as if it succeeded, so you have to do a search for ‘import expense rate table’ in Workday to see if and what any errors are. You will likely have to play around with the mapping and filters to get the Excel data to match the Spend_Data_ID fields for locations in Workday. And the State Dept adds a new location every couple months which will cause the integration to fail unless you enter the new location in Workday. So, not perfect, but certainly saves HR a few steps. Erik Pearson Senior Software Engineer Bowdoin College HR_PerDiemRates_HR_Import.zip (7.8 KB)
Issue: Mapper object array incorrect in to Workday Write output
We are building a boomerang integration, which gets values from workday, adds/changes some of the data, and resubmits the data back to workday. In the mapper, I want to grab an entire section and rewrite it back to the submit without changes. this section has varying levels to it, and would be risky to map all the children… so need to copy all. This section(array) is called ‘Course_Section_Combination_Instructional_Format_Contact_Hours_Data’ as shown: The issue I’m hitting with this is that the mapper produces one output, but the workday write shows another. Why doesn’t the workday write, take the values from the document? Is there a better approach to a boomerang integration? More similar to the old xml/xslt approach where we 1.GET data, 2.XSLT/identity transform, 3.Submit data ?Complex XML Processing & HR Onboarding/Off-Boarding with Workday
This pipeline illustrates two of our commonly encountered customer scenarios: a) An example of complex XML processing, and b) A real world example of what HR On-Boarding/Off-boarding might look like with Workday data I have used variants of this pipeline in multiple POCs and wanted to share this for the benefit of the field team. Below is a screenshot of the pipeline and a detailed walkthrough of what it attempts to achieve. Lets review this pipeline. On the left, we start by reading an XML extract from Workday, that contains, a) New Hires, b) Terminated Workers, and c) Active (that are neither new hires or terminated) Our goal in this pipeline is to separate out these three kinds of workers, and write them in their own XML files. These target XMLs represent feeds to one or more systems that process employee on/off-boarding. Workday’s Employee extract also provides some aggregate data in the XML header. This header information is present in our source extract. Our goal is also to preserve this header, and introduce this in each of the target XMLs, with an update to a specific header field (worker count) that reflects the total number of workers being written to each target XML file. The source and target XMLs are attached to this wiki page. Pipeline Walkthrough As soon as we read in the source Worker XML and part the file, we make a copy. Along the top path, we process the XML payload. Along the bottom path of the copy, we extract and preserve the header for use at a later time. Lets look at each of these paths separately. A. XML Payload processing We first remove the hierarchy in the Worker data by using a JSON splitter (Flatten Workers). The core of the Worker processing happens within the ‘Split-Worker Status’ stage which is implemented using a Router snap with ‘First Match’ enabled. We separate out the three types of workers using the logic below: Terminated Workers: jsonPath($, “$[‘ws:Status’][‘ws:Employee_Status’]…*”).indexOf(“Terminated”) != -1 Active Workers: jsonPath($, “$[‘ws:Status’][‘ws:Employee_Status’]…*”).length == 0 Newhires: jsonPath($, “$[‘ws:Status’][‘ws:Employee_Status’]…*”).indexOf(“Active”) != -1 Once we have the workers split by type, we start adding back the hierarchy. We do this in two stages: a) Add back the ws: prefix: This is done using the Group By N snap with a $ws target field. b) Reintroduce the XML Header We introduce the preserved XML header into the output of stage a) above. More details on header introduction covered below. B. XML Header Processing We preserve the root element name(Worker_Sync) through the mapping: We add the processed payload (the workers separated by type) under Worker_Sync through the mapping: Finally, we use update the worker count field ($[‘ws:Worker_Sync’][‘ws:Header’][‘ws:Worker_Count’]) within the newly introduced header through: Once this is done, our XML is ready to be formatted and written to its target file (or fed to another endpoint). Please note that you need to leave the root element empty in the XML formatter in order to eliminate the default tags from being introduced.Scenario 1 - Workday XML Manipulation_2016_07_05.slp (29.0 KB) Scenario 1 - Workday XML Manipulation_2016_07_05.slp (29.0 KB) Scenario 1 - Workday XML Manipulation_2016_07_05.slp (29.0 KB) Core Connector Worker Output (4)-renametoxml.slp (113.2 KB)
