What is new in FRENDS 4.3

FRENDS version 4.3 is soon to be released. We will take a look to some of its new cool features.

Process editor

There is a brand new process editor based on bpnm-js. This a major improvement to anyone who creates or maintains tasks. The editor is highly responsive and flexible while maintaining the same philosophy behind it: creating descriptive processes which can be read by anyone. It includes the following features among others.

Copy/paste  and group moving functionality

This one is a huge time saver. You can not only copy/paste one single task, but also a group of them which allows you to quickly prototype an idea. You can also move many tasks at once to arrange the process in the shape it make most sense for your needs.


There is a new box/shape which allows you to evaluate single expressions and assign them to a variable. Below you can see two expression block one  called combine Invoice and InvoiveLines and another which is just being placed.



It allows add elements to the diagram which do not execute any code but support the process documentation. For example, if a task retrieves information from a database, you could add a database storage shape to make this clear.


Parameter editors

There are improved parameter editors, with XML, JSON and SQL highlighting. Below the new editor is showing a JSON syntax error.



You can use the mouse scroll-wheel to quickly zoom in and out of your process which is perfect when you have a large process which wouldn’t otherwise fit in your browser’s 100% view.

Subprocesses and scopes

Subprocesses let you create a logic reusable unit that can be shared among many processes.You can easily create one error handler which is common to all your process or reuse  any other type of component. Below an example where The retrieve customer information is a call to a subprocess.

Screen Shot 2016-12-23 at 12.04.36.jpg

Additionally you can group some functions in one scope. Scopes let you make a clear statement that some task belong together. Above, two task has been grouped in a scope called prepare response. Additionally you can associate tasks that will be affect the scope for example to have a custom error handler.


Creating a draft let you save the process in a uncompleted state, so that you can come back and finish it later.

Screen Shot 2016-12-23 at 12.05.54.jpg

Let’s say you are working in a large process and you are called for a ad-hoc meeting. The process validation will not let you save a broken process. In the past you had to either discard the changes or leave the browser open  risking of loosing the work you have done. Now you can save it and fix it later.

Screen Shot 2016-12-23 at 12.54.34.jpgscreen-shot-2016-12-23-at-12-08-14

That is all for now. We are very exited that a new an better FRENDS it is just around the corner. Stay tuned!


Posted in Uncategorized

How Do We Make FRENDS Professionals?

Usually when one starts to learn new technology, one can google tutorials and other training material. But being the creators of FRENDS we are ourselves responsible of creating all that material to the web and cannot just google it. How can one become a FRENDS professional when there is no W3Schools of FRENDS?

When we hire new integration consultants or get new partners, the first thing we do, is give them a FRENDS course. One of our more experienced consultants use one of our sandbox environments to show the newbies what all marvelous stuff one can do with FRENDS. The course can even be held via Skype, so we have also been teaching our partners and customers, that are not located near us, the same way.When the new releases bring cool new stuff to FRENDS, R&D gives demos of the new features. That way the developers learn to use the latest features.



Many of us usually learn best by doing stuff themselves and trough try and fail -process. That is why we have our sandbox environments where anybody can try building FRENDS processes by themselves. I personally loved my very first FRENDS course where we built a FRENDS process simultaneously on our own computers while the colleague giving the lecture did the same thing on the screen. What a great way to learn!

We have such a luxury that we have FRENDS R&D sitting almost next to most of the developers and  not over the sea on a different timezone. When we have taken our first steps with FRENDS and started to do real stuff on customer projects, we can always go to them and ask if we do not know the best way to do something. We also have an internal discussion forum, where one can ask questions and other developers and R&D explain how they have resolved similar problems. Peer support is the best kind of support!



Many of our clients do some of the FRENDS development in-house, because FRENDS is very easy to learn and use. We call them DIY-customers. DIY-customers naturally get the FRENDS crash course in the beginning too. After that they have one consultant assigned to be their personal tutor. The tutor visits or has Skype meetings with the customers on regular basis. In those meetings the customer’s own developers can ask all the questions that are troubling them at that time and get on with developing.

We are currently building a knowledge base based on the internal discussion board to save the great tips and “how tos” for generations to come. And of course we are updating the documentation all the time. And we DO have lots of stuff already online! If you want to become a FRENDS professional, you can start for example by watching our tutorials on our Youtube channel or see the documentation in FRENDS Wiki.

Posted in Uncategorized | Leave a comment

What’s new in FRENDS4.2


A new version is just around the corner! Today we’ll look at all the great new things you get when you update to 4.2.


There’s a completely new view called the Dashboard view. It is in its early stages and the look and feel will change in the future, but the basic functionality is there.


The dashboard view with different widgets. The green widget is the successful processes widget and the red one the failed processes widget. Below them is the Errors widget and to the right the Process execution graph.

The dashboard view is completely customizable. You can add as many different widgets there as you wish, and position them freely how you see fit. The configuration is currently user and browser specific, so if you want your dashboard to look the same, use it on the same browser with the same login information.

Currently there are four kinds of widgets available:

  • Successful processes widget shows the amount of successful processes in given environment(s). You can set the environments which it will show the successful processes for, as well as the time limit for which the number is shown.
  • Failed processes widget works exactly like the successful processes widget, only for failed processes.
  • Errors widget shows the errors for given environment(s). Again, you can freely choose which environments the errors are shown for. You can investigate and dismiss errors via this widget.
  • Process executions graph shows either the successful processes or failed processes in the environment(s) you choose. You can also set the time limit for which the process executions are shown as well as the time interval for which they are depicted.

As mentioned before, the look and feel of the view will be updated and there will be more widgets to choose from in the future.

Process view

The process view has changed a bit from 4.1. Now the process executions list can be seen below each process name when the row, or the chevron in front of it is clicked. Now clicking the process name takes you straight to the process editor.


Clicking on the chevron in front of the process, or just the row, will open the process execution list below.




As a user you have a lot of options in this view as well. First, you can chooce which columns are shown in the list. The default options are presented in the picture on the right.

By default only the State, Start time, Duration, and Error info are shown. On top of those you also have Id, Version, Trigger, and Agent columns to chooce from.




You can also filter the items on the list. By clicking on the “Filter” button, depicted in the top right corner of the list view, you open the filtering options. The options include the start and end time for the time period under observation. There’s also a text filter with which to filter the instances based on the text in Error column and the promoted value columns.


The filtering options include start and end dates and a text filter.

The list also shows whether the agent has the most up to date information or not. First of all, if the agent has been inactive for a long time, it is shown at the top of the view. The user is also notified whether the latest changes to the process configuration or trigger state has been updated to the agent.


If the agent is offline or not responding, this message is shown at the top of the process view.

When the process is updated on the UI, but not on the agent, the message “Updating to version X” appears next to the process name. When the agent is up to date, only the version number is shown.


When the process configuration is not updated to the agent, the message “Updating to version X” is shown.




Similarly, when the triggers are activated, they might not be immediately active on the agent. When the trigger is activated, it is first shown in grey, so that the user knows it is activated, but the agent is unaware of this. When the agent has activated the trigger as well, the trigger turns blue.


Promoted results

In 4.2 it is possible to promote the results of a process or a single task or scope of a process. These values can be viewed in the process execution list and they can be used in monitoring rules (explained below.)


The third field from the top is the selection which promotes the value of the task. In this case it is named “developer actions”.





In the process execution list, you can choose the promoted value as one of the columns. They appear at the bottom of the column selection list. By selecting the values to be shown in the process execution list, you can view the return value of the task, scope, or process.



Monitoring rules

Promoting certain values makes it possible to monitor those values. It is possible to merely observe that the value exists, or to set different requirements for the value itself. It is also possible to set a rule to monitor the number of values passing that criteria or, again, monitor the sum or minimum or maximum values of the values passing the criteria.


An example of a monitoring rule.

It is possible to just generate the graph and look at when it meets the rule and when there are errors. It is also possible to set the rule to send an email alerting the relevant people when the rule isn’t met.

Miscelaneous smaller improvements

There are numerous smaller improvements done to the UI. Here are the biggest improvements.

Comments for tasks

It is possible to write comments for single tasks, which can be seen when the mouse is hovered over the task in the editor or execution graph.


On the left is the editor where the comment can be set. On the right is the comment which can be seen when the mouse is hovered over the task.

Major and minor versions for processes

It is now possible to set the major and minor version number for a process when saving it. It is also possible to switch between versions through the actions menu.


Above: It is possible to chooce the version for the process.     Below: The version will be shown after the process name. The first number is the major version, second minor, and the third is a running number the user cannot set.

Task parameter descriptions

If task parameters are commented in the NuGet package, those comments will be shown when the mouse is hovered over the parameter name in the process editor. Otherwise the parameter’s type is shown.


Task package descriptions

The task packages can be described in a comment in the NuGet package. That description will be shown in the task view.


Task updating

Now it is possible to check whether tasks can be updated with the click of a button. On the top of the Tasks view is a button labeled “Check for updated packages”. When it is clicked, it checks whether any packages can be updated. If they can, an “Update” button will appear next to the package name, as can be seen in the picture above.



So hold tight: 4.2 is coming soon!

Posted in Uncategorized | Leave a comment

Monitoring and viewing process executions

Previously we’ve seen what happens in the background when a process is created and run on FRENDS4. We’ve also found out how to create processes in this multipart series. This time we’ll see how the users can monitor the process executions and see what happened in each one.

Process list view shows all of the processes in the environment. For each process there’s information relating to the process executions.


This is what the process list view looks like. Click for a larger image.

On the left side of the process is an icon depicting the state of the last execution. The possible icons are the following:

  • Started – The Agent service has started to execute the process. The process instance will be in this state until finished.
  • Finished – The process instance has finished executing successfully.
  • Exception – The process has failed with an error.
  • Terminated – The process has been terminated, either by user request, or being marked as marked as a zombie

Next to the icon is a number of unacknowledged erroneous instances, if there are any. If the instances which result in errors are acknowledged as soon as they are seen, the number indicates new error instances since the last time they were checked.

In our case the last execution ended in an error and there is one unacknowledged error.

To the right of the process name, version, and description, are the instance counts in a given time period. The instances are grouped by state: running instances (depicted with a  icon); instances, which ended in a success (); and instances, which ended in an error (). The time period can be adjusted with the drop down menu at the top of the table.

In our case no instances are currently running, 6 instances have been run successfully, and one instance has ended in an error.

Clicking on the process opens a process instance view. It lists all the instances of the process and gives more information about them. This includes, but is not limited to:

  • The status of the process instance. The statuses and icons are the same as the last execution icons in the process view, with the addition of running process icon ().
    • Here, there are TWO icons for errors:
      •  means an unacknowledged, or new, error
      • acknowledgedError.png means an acknowledged error
  • The version of the process was run.
  • The start time of the instance.
  • The trigger of the instance.
  • Where the instance was run (agent and environment).
  • Possible error information

It is possible to delete instances, terminate running processes, and acknowledge new errors.


Process instance list view lists all the process instances. Click for a larger image.

Clicking on an instance opens a more detailed view of the instance. It will open a process graph where the execution path is highlighted with color and the path not taken is grayed out. If the execution ends in an error, the error is shown above the graph and the node in which the error occurred, is highlighted in red.


Process instance view shows how the process execution progressed. In this case there was an error within the foreach loop: the task as well as the foreach loop are highlighted in red to depict that. Click for a larger image.

Clicking on the nodes opens a popover which shows more information of the shape. For example, for the task nodes the popover will list the parameters given to the node, as well as the return value of the node. If the node threw an error, the result field of the node will show more information about the error.


Clicking on a shape shows more information on it’s state and values during the execution, whether it ended in error (left) or success (right). Click for a larger image.

As you see, it is possible to get quite a bit of information out of process executions with FRENDS4.

Posted in Uncategorized | Leave a comment

Creating and editing processes, part 4: Throwing and catching errors

In the previous posts in this series we’ve discussed the importance of processes and using them to describe the work you do, started creating a process and created tasks, and created loops, decisions, and finished a process.

So why is there a part 4?

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

In FRENDS4 there are two shapes relating to error handling: the error scope and throw error node.

Error scope is depicted with an exclamation mark within a circle (processEditor_errorHandlerButton_small)in the shape selection bar. Those can be added to specific tasks, foreach nodes, or the entire process. It is a box, similar to a foreach loop. If an error occurs within the task, foreach node, or process the error scope is created for, the graph in the error scope will be run.

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 an error handler for the task to either try again or notify the owner of the process of the failure.


An unfinished error handler for fetching the actions from the kanban board task.

A global error scope for the entire process can be created too, to catch any kind of error thrown at any point of the execution of the process.

The other shape not used in our graph, is the throw error node. It is depicted by a circle with a line going through it (processEditor_throwButton_small) in the shape selection bar. If there is an error situation, which is an error and should be differentiated by, for example, a unique error message, throw error nodes are the tool for that.

Throw error nodes look a lot like return nodes, 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.


A throw error node. The error message is an empty string by default.


Now you know all there is to know about creating a process with FRENDS4!

Posted in FRENDS4 | Tagged , | 1 Comment

Creating and editing processes, part 3: Loops, decisions and ending a process

In the previous parts of this series, we’ve discussed why understanding your work in terms of processes is important and gone over how to create tasks with FRENDS4.

We left off when we realized a loop could make our lives a lot simpler. Let’s see if it really does.

In FRENDS4 a loop is created by clicking the circular arrow (processEditor_loopButton_small) on the bar above the graph.


A foreach loop will contain its own graph. Its start node will contain the rule for the looping.

The foreach loop is a box into which a new graph can be drawn. It has its own start node, where the looping condition can be defined, as well as a shape selection bar.

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 shape is needed. It can be created from the diamond shaped button (processEditor_decisionButton_small) on the shape creation bar.


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

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 diamond. 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 off to the right of the decision shape has a condition. The path going down from the decision shape 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.

Return node signals the end of the loop and can be created with the button with a square with an arrow pointing out of it (processEditor_returnButton_small). 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.


A return node with its default value.

A return node also signals the end of the entire process. Just like the return node in the loop, the return node of 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.


The complete process graph.

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

Posted in FRENDS4 | Tagged , , | 2 Comments

Creating and editing processes, part 2: Creating a process and tasks

In part 1 we discussed how easy it is to create processes with FRENDS4. However, we didn’t actually show how it is done.

Well, without further ado, let’s create the appreciation process!

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


The “Create new” button at the top of the process view.

On the top of the screen are the fields for the name, tags, and description of the process.

The name is mandatory. It should describe the process well while being concise. It will be the main way to differentiate between different processes. Our process will be called “Appreciation process”.

The tags are optional and can be used to group processes with similar purposes, structures, components, etc. together. Tags are an effective way to filter processes in the process view. In our case “blog” is a sensible tag.

A process can 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.


The name, tag, and description of the process can be edited at the top of the screen.

Below the name, tags, and description fields is the process graph. By default there is the start node, which cannot be removed. The triggers for the process are stored and edited here. Triggers will be covered in another post.

Other shapes can be added from the bar on the top of the graph.


The shape selection bar. The shapes in order: task, decision, loop, error, return, and throw error.

First we’ll 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 clicking the rectangle button (processEditor_taskButton_small) on the shape selection bar. We’ll give it a good name and select a task type from the drop down menu.

The task type menu contains all task types we have imported to our system in the Tasks view.


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.

Loops, as well as the rest of the process, will be covered in the next post of the series.

Posted in FRENDS4 | Tagged , | 3 Comments