Written for Frends version 5.4

A Process can be anything from brushing your teeth to handling an order on an online store from the customer buying the good to shipping it. The best way to describe these is to break them down into smaller pieces.

Brushing your teeth: “Get a toothbrush and toothpaste. Squeeze a small amount of paste onto the brush. Brush the outside, inside, and cleaning the surface of each tooth. Rinse your mouth and toothbrush in the end.”

Handling an order in an online store (grossly abstracted and simplified): “When the customer checks out the shopping cart, handle payment. After that has gone through, create an order for the product. The physically closest warehouse, which has the product, will take it upon itself to handle. It will then package the product and send it to the customer.”

It is always better if the Processes are automated. Many adults do not consciously think about the steps they take when they brush their teeth. Likewise, it is always nicer if a person does not have to oversee and handle, say, which warehouse is the closest to a customer AND has a specific product.

Frends is created with a slight adaptation of W. E. Deming’s quote in mind: “If you can describe what you are doing as a process, you’re already half done.”

When you define a business process in Frends, you’re already halfway to having it automated. You might not necessarily know exactly how each step will be implemented, but once you’ve defined a process with Frends you can hand it off to a person, who can handle the details and make it work.

At its best, Frends can act as both the documentation and implementation of a process.

While creating a Process is easy, explaining how it’s done, is less so. We’ll continue with the actual implementation next.
​

To create a new Process, we first go to the Process View and click the “Create new” button.

You will then be taken into the Process Editor page. In the top left corner, you will see "Name", you can select this, and the "Settings" side bar will open.

Here you can name your Process. The name is mandatory. It should describe the Process in a quality but concise manner. It will be the main way to differentiate between different Processes. Our Process will be called “Appreciation Process”.

A Process can also have a description, but it is not mandatory. It can be useful if there are many similar Processes with only slight variation in names. The description can also help if a new person starts working with the Processes: If the Processes are described, there’s less need to refer to other documentation, to determine what the Process does and why. You can add a description in the Settings menu.

Once you have named and given a potential description to the Process, you can turn your attention to the functionality. In the Process Editor, you will see a large empty space called the Canvas. By default, there is a Trigger Element, which cannot be removed.

Triggers are registered by the Agent and can only activate if the triggering event is registered by the hosting server.

Triggers are an integral part of any Frends Process as they are the way a process can be started dynamically based on an event that the Agent is able to receive. The trigger also acts as a starting point for the process and the first step in the Process diagram.

These events can include:

This means that if you are creating a REST API you should use and configure an HTTP Trigger or an API Trigger as the start event for that integration Process. Likewise in the case of a batch job you should most likely use a Schedule or a File Trigger.

Note that you can have as many Triggers as you would like in any Process, and you can combine different Trigger types together. This means that you can create an integration Process that is run whenever a file is created to a folder AND at least every 6 hours.

Elements can be added from the Toolbar on the side of the page.

For the example Process that we will create, we will first need to get the developers’ information from the database. Namely, who they are, what their usernames are on the Kanban board, and what their email addresses are.

For this we need a Task. We can create one by selecting the Trigger Element and clicking "Append Task":

We must assign an action to the Task from the dropdown menu within the Task. For this Process we can use the "ExecuteQuery" Task.

All Tasks look like rectangles, but they can do wildly different things based on the type of the Task and the parameters given to it.

In order for the Task to do anything, it needs parameters – otherwise it won’t know what to do and in which database to do it in. The parameters needed by a Task vary depending on what the Task does. In the example above we need to define the query and the connection string of the database as well as the root element of the resulting XML.

However, we do not have that information handy, nor do we want to spend time on creating the actual SQL query. So, we’ll just leave it blank for now and get back to fill in the details later. Right now, the most important thing is to create the Process flow, so even if I fall sick or have an accident immediately after finishing this Process, it is easy for someone else to pick it up and finish it.

Once our Process has the information of each developer in our team, it will have to check the actions of each developer and send an email based on that information. Since the actions will be repeated for all developers, it’s sensible to create a Loop. This way we need to define the actions only once.

For this Process, we will add a Foreach Loop. A Foreach Loop can be added by selecting following highlighted symbol from the Task Toolbar:

A Foreach Loop contains its own separate Canvas. It has a start Element which contains the rule for the looping. You can add Tasks within the Foreach Loop that will execute depending on the logic in the start Element.

First, we’ll create a Task to get the developer’s actions from the Kanban board. Creating it will be very similar to the creation of the previous Task – only the type and parameters are different.

Depending on whether or not any actions are found in the Kanban board for the past day, different things will be done. For this, a decision Element is needed. There are two types of decision Elements, the Inclusive Decision Element and the Exclusive Decision Element. These Elements are explained in these articles:

Exclusive Decision

Inclusive Decision

For this Process we will use the Exclusive Decision Element, which is added by selecting the following highlighted symbol from the Task Toolbar:

The condition is stored on the path and not the actual Element. This is because multiple paths with different conditions can exist for the same Element.

It could be named, but more important is to name and define the conditions that define the path the process will take. Those will be defined on the path(s) leaving the decision Element. The path leaving the bottom of the diamond will be the default path taken if no other path can be taken due to the conditions.

The path going up from the decision Element has a condition. The path going down from the decision Element is taken if the condition of the other path is not met.

Next is the creation of the Tasks which read the email messages from a file, choose a random message from the messages and send the message.

Once the message is sent, the set of actions is done and we can either start a new set of actions or leave the Loop, depending on whether there are any developers left to process.

To leave the Loop we must add a Return Element, which signals the end of the Loop and can be created by selecting the following highlighted Element from the Toolbar:

Attach the Return Element to the final Task in the Loop. This can also be done by selecting the final Element in the Loop and selecting the same Element which is called "append Return" from the popup.

It is possible to define the return value, so that the Tasks after the Loop can work with the data processed and created in the Loop. Our Process, however, ends right after the Loop, so there is no need to do anything fancy to the return value of the Loop.

Finally, we should add a Return Element after the Foreach Loop to signal the end of the entire Process. Just like the Return Element in the Loop, the Return Element for the Process can also be set to return a certain value or object, which can be taken and processed outside of the Process. For example, in the case of an HTTP Trigger, the website that triggered the Process can show the user different things based on the result of the Process.

Our Process does all it needs to do – there is no need for the return value of the Process, so we will not do anything fancy to it.

And there we have it. Our Appreciation Process.

We did not use all possible Elements in our Process. In the next post we’ll go over the ones not used here.

Our Process is very optimistic – we always assume that things work. However, we can rarely afford such optimism.

In Frends there are two methods you can use relating to error handling: Catch/Scope and Throw, both Elements to be used in the Process Editor.

To look at the first method, you can use a Catch Element to handle an exception. The Catch Element is depicted by the following highlighted Element type found in the Toolbar:

Catch Elements can be attached to specific Tasks, Foreach Loops, or the entire Process. Catch Elements point to Error Handler Elements, which can be a Task, Code, Call Subprocess or Scope Element that is used to handle an exception caught by a Catch Element.

The most common Error Handler Element is a Scope Element. A Scope Element groups other Elements together and handles any exception in the main Process flow without impacting the Process flow in any way, all action in the Scope Element is not visible outside of it. The Scope Element is the following highlighted Element found in the Toolbar:

Our Process, while great and potentially very good for our developers, does not have any sort of error handling. Hopefully these emails aren’t the only way the developers get appreciation. If the emails stop coming, it will be fairly simple to determine what the issue is and fix it, so that the appreciation emails will start coming again.

We could add a Catch and Scope to our Process to either try again or notify the owner of the Process of the failure. Here is an example of what this could look like:

The other error handling method is the Throw Element. It is depicted by the following highlighted Element found in the Toolbar:

Throw Elements are used to throw an exception when an error occurs in the Process, but Throw Elements take an expression as a parameter which allows you to customise your Process' response to the error.

If there is an error situation, which is an error and should be differentiated by, for example, a unique error message, Throw Elements are the tool for that.

Throw Elements look a lot like Return Elements, since both effectively end the execution of the Process.

Our Process does not have these sort of error situations, so the nodes are not used. Below is an example of what the Throw Elements looks like:

Now you know all there is to know about creating a Process with Frends.

Next, learn how to Use the Parameter Editor.
​