CompSci for Workday® - DRY Code

CompSci for Workday is a two part series of lessons for Workday developers and users. Most of the Workday integrations I have seen have come from designers with an HR background and not a Computer Science background. While their code is often very functional, they could save a lot of time and effort if they followed some of the core principles of Computer Science. This article addresses DRY Code, it is a central lesson of Computer Science and how it can apply to Workday Integrations. On Friday, we will post the second part of the CompSci for Workday series.

What is DRY Code?

Don’t. Repeat. Yourself. Otherwise known as DRY. If you have taken any coding lessons, you have probably heard this mantra and more than once. The core idea is that if you find yourself writing the same or similar code multiple times you have already made a mistake and need to refactor (redesign) your code.

Here is an example of some non-DRY code. Let’s say we have a shape with 4 sides named side1, side2, side3, and side4 and we want to get the perimeter, but we want to make sure none of the sides are equal to zero, we could build it like this:

In layman's terms this code checks each side to see if any are equal to zero and if so it prints out 'Error'. The problem is I repeated the same part over and over and over again. Around the second time you type out the same thing your coding sense should be tingling that you are making a mistake. This is not DRY code since you repeated yourself several times. There are many ways we could alternatively handle this such as looping through an array:

running it through a separate function:

These alternatives send off an array of sides to a function that in turn checks each side and also sends the array to a function that sums up the sides to arrive at the perimeter. If the functions are well written it won't matter how many sides get fed in, the code won't ever have to change. This uses a concept called SoC but that is a topic for another post.

But why would you do this?

It may seem like extra effort to write DRY code, but it pays in dividends when a project changes. What happens if the code has to account for 6 sides, 12 sides, 200 sides? What if you don't know how many sides will come in until it is run? What if you have to check each side for 3 parameters instead of just one? DRY Code not only makes your code easier to re-use, it also allows you to make corrections more quickly since you don't have to correct each repetition.

This is great and all but how will this help me in Workday?

You aren't usually writing out lines of code in Workday Studio. Studio has some tools to help keep integrations DRY:

Splitter

This is probably the most common DRY component. Workday's Splitter lets you write code one time and have it apply for each line/entry in the message.

Subassemblies

Subassemblies are magical and criminally underused. Most large integrations have them to help break up the studio into more readable chunks, but they are rarely used beyond that. Have you ever had to repeat the same process multiple times in the studio?

For example, in a Studio Integration I had to check for illegal characters and cases in an output before pushing it out to a SOAP call. Several SOAP calls occurred, and each needed to be checked. The client was able to add more characters and cases at any time. Rather than punch out the code over and over again, I made one subassembly to filter the characters and used several Local-In steps pointing to this subassembly over the course of the code.

There are also advanced use cases for subassemblies, one such case is using local parameters to pass in situational code. A great example of this is with common local error handlers; let’s say you want to send code over to an error handler but don't want to build an error handler for each and every situation. You can pass in things like the error code and details through parameters that get read in the subassembly to provide a contextual response.

Route Loops

One of the least common applications I've seen of the Route step is the loop component. Route loops can run for a set number of times as dictated by you or loop until a condition is true. You do need to be careful and avoid infinite loops, but it can be very useful in iterating over a data set when a splitter won't do.

Multiple Workday-In points

Did you know you can re-use a whole integration? Let’s say you have a studio that is used to process payroll results for Division A and you need to set up a similar one for Division B with minor differences in the setup step. Do you just close the integration for Division A? While that is an option and it will keep them distinct, there can be some complications. Flash forward 1 year later, the company has expanded with Divisions C, D, E, and F. No problem, just clone it 4 more times! Suddenly Division A's payroll fails, and you have to find the bug, fix it, and test it on all 6 distinct integrations. I've been here first-hand, and it is awful.

What if instead of building 6 different assemblies, 1 assembly could host all 6 integrations? If you use 6 Workday-In points and route them all to distinct async-mediations to set up their properties, you can then route every one of those async mediations to the same "core" integration. This means if you solve a bug in the core integration for 1 division you have solved it for all 6.

Wrapping up

This was just an overview but hopefully this provides some food for thought on how you can make your integrations DRY-er. Keep an eye out for the second part of this series which will be posted on Friday.