By Murray Fenstermaker
Ibza Consulting, Lead Workday Developer
CompSci for Workday is a 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 themselves a lot of time and effort if they followed some of the core principles of Computer Science. These articles will each address one central lesson of Computer Science and how it can apply to Workday Integrations.
What is DRY Code?
CompSci for Workday is a 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 themselves a lot of time and effort if they followed some of the core principles of Computer Science. These articles will each address one central lesson of Computer Science and how it can apply to Workday Integrations.
In layman’s terms this code checks each side to see if any of them 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 handle this in code such as looping through an array:
Or simplify it even more by running it through a separate function:
This now sends off an array of sides to a function that checks each side and also sends the array to a function to sum up the sides to get 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 also uses a concept called Separation of Concerns but that is a topic for another week.
But why would you do this?
It may seem like extra effort to write DRY code, but it pays dividends when the 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
So, what’s the point? You aren’t usually writing out lines of code in Workday Studio. Studio already has some tools to help you keep your integrations DRY:
Splitter
This is probably your most common DRY component. Workday’s Splitter lets you write code one time and have it apply for each line/entry in the message. You are probably already using these properly, so it is great example of how you are already writing DRY code, good for you!
Subassemblies
Subassemblies are magical but criminally underused. Most large integrations have them at one point or another to help break up the studio into more readable chunks, but they rarely used beyond that. Think about it this way, have you ever had to repeat the same process multiple times in the studio?
For example, in one of my Studio Integrations 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 could add more characters and cases that they wanted filtered out at any time. Rather than punch out the code over and over again, I made one subassembly to filter out characters and used several Local-In steps pointing to this subassembly over the course of the code.
There are much more advanced use cases for subassemblies, such as using local parameters to pass in situational code. A great example of this is with common local error handlers. 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 have to be careful 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 only some minor differences in the set up step. Well do you just close the integration for Division A? That is certainly an option and it will keep them distinct but there can be some complications. Flash forward 1 year later and 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, and future articles will dig deeper into the actual tools being used and how to implement some of these solutions but hopefully this provides some food for thought on how you can make your integrations DRY-er.