Mind your own business (logic)

You might have have heard that you need to separate the business logic from the data access. Or sometimes from the domain model. But what does this mean and how does it translate to robotic process automation?

There are always different ways to do things and as such you shouldn’t think of this as “the right way” but rather as one of many ways to do it. The way that I separate the two is actually in the same way as Blue Prism, in actions and processes respectively. If you have experience with Blue Prism, try to forget that for a while, since this is supposed to be about the concepts, not the technical implementation.

Actions

Actions are small objects which performs an action (hence the name), typically on a single element. For instance, an action could be to press a specific button on a web site. The point of actions is that they should be reusable in different processes. In the picture below I have nine different actions which controls various elements on a generic web shop.

You may argue that Sign in is actually three actions: enter username, enter password and click sign in. And in principle you would be correct. But this is one of those grey areas, where you need to make a judgement on what makes most sense to you (after all, you rarely use any of the three sign in components on their own).

It is important to keep business logic out of the actions. For instance, it might be tempting to add some validation to Check out, to ensure that the order isn’t too expensive. DON’T DO THAT! If you need that functionality, instead make an action that can read the total price and then make the validation in the process (which we’ll get to in a minute).

You may also consider bundling multiple actions. DON’T DO THAT EITHER! With a few exceptions (like the sign in from above) bundling actions will also imply business logic by saying that these actions always goes together in a specific order (hint: they don’t).

Processes

Once you start combining actions in a specific order (and possible add stuff like validations, etc.) you get a process. In the picture below is the same actions as above, but in a specific order. They now form a process, which is to look up an item in an Excel workbook, search for it and buy the cheapest one.

The process above has business logic, even though the actions are the same as before. In addition to actions, processes can also contain other steps, like validations or calculations. Where actions are reusable, processes are not. But by making sure that all the actions are generic, we have made a solid foundation for any future automation of the system where the actions apply.

Final thoughts

A typical automation assignment starts with a process. You then need to take that process and break it down into all the different actions that composes it. An actual business process is typically way more complicated than the example above. So take your time, talk to the business people and make sure you understand the process and the system. Otherwise you are in for a rough ride.