Automating Processes with a Client-Service Desktop App

Micro-RPA isn't sexy but boy can it solve problems.

Automating the flow of data in an organization is anything but accessible. This is especially the case when collaborating with people or adding new processes. There are too many variables (both logical and in code) to consider.

Most of the time when a business decides that automation will cure a process bottleneck, a developer is drafted in to save the day with a series of scripts, applets and custom services which are designed to be:

• Maintainable only by said developer.
• Written in a specific programming language.
• Inaccessible to non-technical people.

The alternative? It might be that an off the shelf RPA solution is the ticket. Solutions like Blue Prism and ThinkAutomation are fantastic tools which are used globally to steer the everyday flow of data.

But what if the company is looking to the developer to create something similar but not as armed to the teeth with automation tools and tricks?

The ‘Client-Service’ app is a viable solution.

What is a ‘Client-Service’ Application?

‘Client-Service’ is a term used to describe a simple software architecture used to create manageable server-based automation software. It is most suited to situations where a similar subset of automation problems exist but where it’s also necessary to keep the system easily accessible to non-technical people.

The model consists of a Client; a front-end, desktop application with one purpose: to place configuration data in a database, followed by a Service, (in most of my work, a Windows service) whose job it is to constantly check the database for new tasks to perform and then to perform them, thus achieving a configurable automation solution.

The main benefit here is the GUI. If the requirements are set out properly early on, a developer can ensure that the GUI is as flexible as possible for someone to configure a new automation task.

Similarly, the service need not be overly complicated. More often than not, the service itself is a timer checking the database every x seconds or minutes for a new record to process.

Once it has found a record, the service can call the relevant logic to complete the task, along with any required parameters from the pulled data. We could even get real fancy and pass the processing off to a separate service. I like this approach because it encourages a separation of responsibilities known in software engineering practice as decoupling. The advantage of decoupling is that a point of failure is confined to one area of the architecture, limiting the effect on other areas such as the database or the GUI client.

My Foray into Micro-RPA

I recently adopted this approach in the development of one of my own applications, AutoEvent. Written for systems sdministrators, AutoEvent automatically scans the event viewer of a Windows machine for logs that meet specific conditions (eg: Error log, a log containing specific keywords, etc). When these logs are generated, AutoEvent performs a basic action in response such as sending an email or running a program. (A similar feature used to be native to Windows but was removed not long ago, hence the reason for me writing the application.)

AutoEvent adopts the client-service approach, as it has a front-end client that allows a user to set up some triggers which are stored in a database for a background service to pick up.

It’s Not Trying to be Sexy

Yeah, it’s basic. It uses WinForms so it’s not sexy, but it doesn’t need to be. When using this model in a micro-app like AutoEvent, it’s easier to sacrifice the sleek visuals you find in larger Enterprise applications. Instead, the focus stays on regaining control over the way business automation is handled. As you’ve probably noticed, it’s a very basic architecture, which is probably it’s greatest asset.

So next time you think adding to a new library of automation scripts that only you can maintain, think about building a new micro-app using the client-service model. You’ll not regret having your own slice of micro-RPA goodness and more importantly, the non-technical people in your office will thank you for it.