Welcome to part 2 of our CompSci for Workday series. In part 1 we took a look at DRY code, part 2 is all about Encapsulation, another core lesson of Computer Science, and how it applies to Workday.

What is Encapsulation?

Encapsulation is one of the core design concepts of Object Oriented Programming (OOP). The idea is that related functions and data should be encapsulated together. This reduces clutter, hides unnecessary information from users and creates cleaner, more reusable code. Encapsulation overlaps heavily with another core OOP concept, Separation of Concerns. Separation of Concerns is the principle that no object or structure should manage any data that doesn't directly concern it. Properly encapsulated code should already separate concerns.

In more practical terms

Think of a restaurant and its staff. You can think of the kitchen and the cooks as a team we will call "back of the house" and the servers and host as a team we will call "front of the house". The two teams communicate to each other and transmit information between them but there is no reason for a waiter to go to the kitchen and start cooking. It is also unusual for a cook to bring out the food and refill a table's drinks. Both the front of the house and back of the house can be seen as encapsulated structures. Each team has everything they need to do their jobs and while they work with other teams it is through predefined routines or interfaces (waiter enters an order into the computer, chef gets the order and makes the food, chef plates the food, waiter brings it out to the table).

Why is this important?

This sort of thinking is vital because it allows you to modify programs without having to rebuild from scratch. For instance, in our restaurant, if the kitchen changes from electric to gas stoves or from steel to cast-iron cookware, the kitchen staff will have to adapt but the front of the house doesn't have to change anything. The front of the house might not even know these changes took place since it doesn't affect them. The same thing is true in our programming. A great example of this in the tech world is payment interfaces. Amazon might change its checkout screen to be more aesthetically pleasing but that doesn't mean that any of the actual payment processing code has changed.

It's like a black box

Sometimes encapsulation can be called "black box coding", where you think of a function or chunk of code as a black box. Once it is built all you need to know is what goes in and what comes out. You know an order goes into the kitchen and 15 minutes later your food comes out. You don't need to know how it is cooked, just that if you order properly, your food will arrive properly.

But How Does This Apply to Workday?

Encapsulation can be seen all over Workday even without building integrations. Workday's data structures all use encapsulation. Here are some examples:

All personal information on workers are nested inside Employee Objects when you run a report.
Reports run only on the data source you select and without calculated fields cannot pull data outside of its primary and secondary objects.
Workday Web Services take an input, run an encapsulated process, and give you your output. You can't always dig into the how or why, it is a black box.

You can use this thought process to build better systems and integrations.

Encapsulating Data Sources

One of our clients had seven different integrations that all worked with absence and leave data. The client had built custom reports for each integration even though much of the data was the same between reports. An improvement Makse Group implemented was to standardize the reports. The only concern of the absence calendar report was to return all of the absence calendars currently active for the company.

Encapsulating Studio Code

Let's say I have a studio that pulls up a worker report. For each worker, if it finds that the current date is later than the employment date, it starts the termination process. This would be a rather basic integration, without encapsulation it would look like this:

While this might be a small integration, it could quickly get out of hand if more functionality is added and therefore why we encapsulate it.

After performing some encapsulation the "FireWorker" subroutine is now a black box. It takes in a worker and runs the SOAP call to fire them. This can be reused between integrations and can also be improved or modified without restructuring the core code.

At first glance this may not seem space-saving but imagine that we are asked to add error handling to this system, or that FireWorker needs to check every time for a contingent worker or whether a position is exempt from this process. Encapsulation ensures that even if the code gets larger, it stays clean and easy to edit.

Encapsulating Integrations and Business Processes

Now, let’s say a third-party service needs you to transmit your benefits information to their server but they need it in their own format, not the Workday default. You could build a studio integration as a one-step process that calls web services or reports, runs through XSLT steps or logic trees and then sends it out through an FTP step. This would work and technically it would be a smaller business process but it is a bad instance of encapsulation and separation of concerns. We have three things that need to occur:

Gather the data from Workday
Transform the data into the proper format
Transmit the file to the vendor

The way this would be handled using encapsulation would be to set up a business process beginning with a Core Connector Benefits integration, followed by a Document Transformation integration, and finally a Delivery Service step. Each link in the chain has a set job to do and doesn't need to know that much about the other steps. In our encapsulated version, if the SFTP destination changes we don't have to dive back into the studio code and retest the whole process, we just modify the Delivery Service step. If the vendor changes formats one year, we only need to worry about our Document Transformation step.

How to Incorporate Encapsulation

One of the most useful ways to think about encapsulation is by breaking down large projects into sub-tasks and large volumes of data into groups. If you think about the project like an assembly line and focus on building smaller routines that accomplish one task flawlessly before passing the product to the next task, you can get a better handle on encapsulation.

Core benefits of encapsulation include:

More reusable code
Easier to read processes and code
Less time spent on fixing/improving systems
More secure data

Let us know if you found this series helpful or if there are other areas you would like to learn about. You can contact us here.

CompSci for Workday® - Encapsulation