Process Flows: From Input to Output

Code is the backbone of most software programs and applications. Each line of code serves as an instruction—a logical, step-by-step mechanism for computers, servers, and other machines to perform an action. In computer programming, there are different levels of code. Computers understand binary code, a series of 0’s and 1’s. Binary code is low-level code, also referred to as machine language.

This blog post builds on from a previous post, Coding at a high level with low-code, where we looked at the importance of understanding algorithms and what that entails in low-code software development. In that post, we briefly looked at problem-solving skills, understanding systems development life cycles, and what process flows are.

What is a process flow?

Any application or solution will contain a set of instructions (activities or steps) that interact in a specific sequence to achieve or produce a particular end-result. This can be referred to as your solution’s process flow. We can look at a process flow as consisting of these elements:

• Input
• Processing
• Output

Let’s consider the above process flow elements in a different sequence, now starting with the end in mind, and within the context of creating a basic Linx solution:

• What is the required output of my process?

Example: A text file containing records.

• To create my output, is there any input that I require?

Example: Data from a specific database table.

• To process my input into output, which Functions from which Plugin(s) do I require?

Example: The ExecuteSQL function from the Database plugin to read from the database table and the TextFileWrite function from the File plugin to write to a text file.

Let’s unpack each element of a process flow to see how it works in Linx.

Output created by Linx

In general, the output can serve as:

1. Support output, used to enable or facilitate the overall process (i.e. used as input to other functions or processes); or
2. End-result output that relates to the purpose or goal of your solution.

With Linx you can create many different types of output, ranging from database entries to hosted APIs, and a lot in between, including files of various types (including JSON, XML, text, CSV and PDF), message queues, encrypted data, compressed files and emails. Output can be created by specific functions, or by an entire, complete process. We will explore this in more detail in the Processing section, below.

Input in Linx

Input could come from different sources, including:

1. External objects or data consumed by a Linx function, e.g. an Excel spreadsheet.
2. Simple Types, which you can easily drag-and-drop into your process flow and set default values to, e.g. integer, string, list, boolean, byte, dateTime, decimal and double. Types can also be complex, with one or more properties, e.g. the Xero plugin contains an Invoice type with properties that describe the data a Xero invoice requires.
3. Custom Types, can be used to create a complex type with one or more properties. Properties can in turn be of any Type or Custom Type.
4. Settings, which are values that can be used anywhere in your Solution. Functions cannot change Settings, they are read-only at run-time. Settings can, however, be changed on Linx Application Server by the administrator to cater for different run-time environments. Settings are used for re-used values, which might change when the Solution is deployed to a different environment or have security ramifications.
5. Output from a preceding Function or Process. As you will see from the next section on processing, functions are used to create output with. That output could be used as ‘support output’ to the overall process flow, and as such become input to another part of the process.

Processing in Linx

When trying to solve a problem, consider this:

• In Linx, a process can contain Functions, Types, Custom Types and even other Processes. Typically, a process flow consists of a combination of these different components, with each contributing to the functioning of the process by providing input to the process, or creating output as part of the process.
• The functions and types contained in a process, are added to the process from their parent ‘containers’, called plugins.
• Functions drive processing by performing specific tasks to turn input into output.

Types of Functions:

• Linx built-in functions:
  The built-in Linx ‘plugin’ contains functions that can be used programmatically to:

1. Set values (e.g. SetValue, AddToList, etc)
2. Execute tasks or procedures (e.g. CommandLine, Sleep, etc)
3. Control the logic flow through conditions or decisions (e.g. IfElse, ForEach, DoWhile, etc)

• Plugin-specific functions:

Linx has a long list of pre-packaged plugins you can use to create your applications. Each plugin contains functions that are relevant to that plugin, e.g. the TextFileRead function contained in the File plugin, the GetAccounts function in the Xero plugin, the ExecuteSQL function in the Database plugin, the CallRESTEndpoint function in the REST plugin, and hundreds of other functions contained in several different plugins.

Function properties: Functions have associated Properties (attributes), which can be set to determine how a function must behave. For example, the  TextFileWrite function has the File path property that indicates the path and name of the file to write to. When you start designing your solution, keep this in mind:

• Will you make use of different but related processes to create your output, or will you only need one process?
• To create output, what is the best sequence in which the relevant types, functions and processes should be arranged?

Services, events and event handlers

Up to this point, we have looked at what goes into a process flow. Services and their associated events make it possible to determine when your process flow must execute. For example, the Timer service (contained in the Utilities plugin) can be set up to execute the Timer Event at specific times or intervals. The Timer Event can be linked to your process flow so that when the event executes it runs your process flow. In this sense, the process flow is your event handler.

Further reading: Automating workflows (BPM) with Linx