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, which is a series of 0’s and 1’s. Binary code is low-level code, and is 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, output can serve as:

Support output, used to enable or facilitate the overall process (i.e. used as input to other functions or processes); or 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 API’s, and a whole lot in between, including files of various types (including JSON, XML, text, CSV and PDF), message queues, encrypted data, compressed files and emails. Go here to learn more about what Linx can do for you.

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:

External objects or data consumed by a Linx function, e.g. an Excel spreadsheet. 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. Custom Types, which can be used to create a complex type with one or more properties. Properties can in turn be of any Type or Custom Type. 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 values that are re-used, might change

Continue reading

This post was originally published on this site