DEV Community


How process automation works: a Linx perspective

Linx Software
Rapid development and deployment of back-end applications. Build and host APIs, integrations and automations in low-code.
Originally published at on ・6 min read

A key part of digital transformation is process automation. Greater efficiencies in resources, time and cost can be achieved when business processes are automated.

Do you want to automate your business processes with Linx, but you don’t know how it all works?

How to build an automated process with Linx

Let’s connect the dots by starting with your desired end-result and working our way back from there. For now, let’s keep it simple and settle for an automated process flow as your desired end-result.

You may ask:

To have an automated process flow, what do I need?

You need a running Service event that will execute your process flow at specific times or under specific conditions.

What is a service event?

The services available in Linx include Timer, Cron, DirectoryWatch, MSMQService, RabbitMQService, RESTHost, SimpleRESTHost and SOAPWebService. Each service can be configured to trigger an associated service event when specific conditions are met.

Let’s take the Timer service as an example: you can configure it to trigger the TimerEvent at for example 7 am every weekday. When the clock strikes 7 am, the TimerEvent will trigger, and execute your process flow, which could, for example, involve the retrieval of the previous day’s sales records from a database, writing them to a CSV file and emailing it to the regional sales managers. In this context, your process flow is essentially an ‘event handler’.

Host your solution on Linx Server

Ok great, but before we look at the details of the process flow as the event handler, first tell me this: what must I do to have a running Service event that will execute my process flow when I want it to?

You must start your Service event, but for that to be possible you need a Solution that has been deployed to Linx Server that contains a Service, which in turn contains your Service event. In other words, you need a Service and service event, inside a Solution that is running on Linx Server.

Once the Solution that contains your Service and service event has been deployed to Linx Server, you can start your Service event on Linx Server.

What must I do to have a deployed Solution on Linx Server that contains a Service event that will execute my process flow?

Short answer: you must design a Solution, which is an application that contains all of your programming logic, including the relevant Service with its configured properties, and the process flow that will ‘handle’ the service event when it is triggered.

Ok, but where do I design this Solution?

You design solutions in Linx Designer. From there you can deploy your solution to Linx Server. The Linx application consists of Linx Server and Linx Designer.

Create your solution in Linx Designer

Ok, so I use Linx Designer to design my Solution that I will then deploy to Linx Server… but what goes into designing a Solution?

Well, remember your desired end result? You want an automated process flow. The automated process flow requires a Service event to be triggered and it needs an event handler (all the functions that drive your process flow) to execute when the Service event is triggered. That is essentially what you have to include in your Solution design.

Let’s take it one step at a time … the Service event: how do I add this to my Solution?

Services are contained in Plugins from where they can be added to your Solution. Ok, so your next question is probably going to be: where do these Plugins come from and how do I access them so that I can add my Service to my Solution?

Linx comes packaged with numerous Plugins that are available to be added to any Solution. Adding a Plugin to your Solution is as simple as clicking an Add button. Plugins can contain Services, as well as Functions and Types.

Take the Timer service as an example: to add the Timer service to your Solution, first locate the associated Plugin, which is the Utilities plugin, then drag and drop the Timer service from the Utilities plugin onto your design canvas to have it included in your Solution.

Before you ask… the Timer service must be configured by setting specific properties that provide an indication of when the service event must execute. (As we go along, keep your desired end result in mind: automatic execution of your process flow at the times you want.)

Ok so now I know how to set up my Service, which means I know how to get my Solution’s Service event to execute at the right times. How do I get my Solution to know what to execute though? Is that the Process you mentioned earlier?


How do I add a Process?

Easy. When you create a Solution in Linx Designer, a Process is created by default. You can use this Process, just rename it if required. You are also able to add additional processes, by adding them from the toolbar.

Ok cool, adding a Process is a no-brainer. It’s more about what is included in the Process that is important, right?

That’s correct. What makes a process work is what you add to it. You can add Functions and Types to a Process.

Where do these Functions and Types come from?

Hey, you should know this by now! Functions and Types are contained in Plugins, just like Services are contained in Plugins.

So similar to adding a Service by first adding a relevant Plugin that contains my required Service, I have to add a Plugin that contains my required Function or Type?


And after I have added the required Plugin, I drag and drop the Function or Type from the Plugin onto the design canvas to have it included in my Solution?

Yes… make sure you first select the required Process to which you want to add your Function or Type by clicking on the Process in the Solution Explorer, and then drag and drop the Function or Type onto the design canvas.

Ah, ok I get you. So let’s say I added a Function to my process, what else do I need to do?

Just like with setting up a Service, you have to set the relevant properties associated with your Function, so that your Function will execute correctly.

Ok, so after I have designed my Process to reflect my process flow requirements, what do I do next?

Three things: firstly, you have to make the connection between your Service and your Process, so that when your Service event is triggered, it not only knows when to trigger but also what to execute.

That sounds complicated…

Not at all! You simply select your Service event by clicking on it in the Solution Explorer section, then you drag and drop your Process from the Solution Explorer section onto the design canvas, which then links your process to your Service event. Voila!

Ok, so how do I know that my Solution will actually work?

That’s the second thing you still have to do: debug your Process, so that you can either see what is failing in your process design and setup, or you can confirm the successful execution of it. If your Process is failing, take note of the debug output values, and go back to your Process to fix the problems. Then debug again, until everything is working as expected.

Let me guess what the last step is… I can now deploy my Solution to Linx Server, right?


To close off, let’s go back to where the discussion started: after your Solution is deployed to Linx Server, what do you have to do next?

I have to start my Service event to finalise the implementation of my automated process flow.

Well done!

The post How process automation works: a Linx perspective appeared first on Linx.

Discussion (0)

Forem Open with the Forem app