Workday Integrations Made Easy Part 2 : No Object Oriented Programming

June 10, 2013 Appirio

By Vikas Wadhwani


In Part 1 of this blog, I mentioned how a typical Workday implementation, can have as many as 60 to 70 integrations to and from other systems, e.g, integrations to talent management, real estate partner, benefits partners, EEO reporting, LMS and many more. As mentioned, in a legacy platform, building this would have required significant effort, but fortunately within Workday it is much easier to accomplish. Let’s take another look at why it is more complicated integrating with on-premise systems.

Integrations on legacy platforms requires programming based on languages like Java or PL/SQL. In order to build integrations on legacy platforms developers often needed to customize their development environment to meet their technical requirements. Developers needs to deal with database drivers and utility jars to make it all work together. However with Workday integrations, you can say goodbye to database drivers such as,, log4j.jar, Spring framework, MVC framework, JRE , JVM and those out of memory errors.

On legacy platforms, building an outbound integration (from Workday to another partner) could be a challenge. This is another complex task where developers need to write hundreds of lines of code. First, developers need to write Sqls to fetch data and then write code to the read data. Second, they have to write code to transform that data to the desired format. Lastly, they must write code to persist data into the file and write more code to send the file to the partners sftp server. As you can see, in legacy platforms developers must write tons of code just to send data to their partner.

In Workday, you do not need to write any code to extract data (please refer to Part 1 of this blog to read more about extracting data from Workday). Transformation of data to the partner’s desired format only requires XSLT programming which is pretty straightforward for most integrations. In Workday, you do not need to use any other programming language to build an output file. Once the file is built, you can configure the delivery mechanism (sfp/ftp/encryption) and you are done. Delivery of the file is simply a configuration item and there is no coding required to send the file across.

To summarize, here are the benefits of building an integration in Workday over legacy systems.

  • While building integrations in Workday you do not need to customize your development environment with utility jars and drivers like log4j, classes12.jar, Spring and MVC framework.
  • You do not read to write lot of code to extract, transform and post data to your vendor. The only step which needs programming are the transform steps where you just need to write in XSLT.
  • Delivery of the file is a configuration item in Workday, so you only need to pick a delivery mechanism and then provide coordinates and credentials of that delivery mechanism.

Stay tuned for Part 3 of this blog where I am going to discuss how “Writing Webservice is a Breeze in Workday”.

Previous Article
Who's ready for Summer?…'13 that is…
Who's ready for Summer?…'13 that is…

By Jason Dent Yup, it’s that time of year again. Where Salesforce Admins around the world get that ear-to-e...

Next Article
Mobile Tech Goes Beyond the Office with Workday Financial Business Assets
Mobile Tech Goes Beyond the Office with Workday Financial Business Assets

By Dan Haigh I read a recent article in about American Airlines purchasing iPads to replace pilo...