Integration Development

Integration flows in Frends are referred to as Processes. Processes consist of elements such as Triggers, Tasks, Subprocesses, decisions and loops. Processes are created by connecting elements together and configuring their parameters.

Step by Step Tutorial Available

If you prefer more visual or interactive guidance on how to create Processes with Frends, you can find a step-by-step walkthrough from your own environment's home page, under Onboarding by selecting "Tutorial 1, Step 3: Creating my first Process" tutorial.

Creating New Process

The Process list displays the already created Processes in the Environment.

In order to create a new Process, click on Create New button while in Process list view and having the Development Environment selected. All new Processes have to be created and edited in the Development Environment, from where they are then deployed to other Environments and Agent Groups for execution.

When creating a new Process, you can start by providing the Process a name and optionally a description. To use the latest versions in Frends, targeting .NET 8 is recommended, while .NET Framework 4.7.1 or .NET Standard 2.0 are only used to support legacy environments.

As an example, let's create a Process which is started manually without parameters, calls an API endpoint and then returns a result. Because the start element, called Trigger, is already provided, we can continue forward by adding a Task to the process.

You can drag or click and place the Task shape from the leftside toolbar to right of the Trigger shape.

To make the Task perform an API call, click on the Select a Task field and search and select HTTP Request Task. When the Task type is selected, the right sidebar contents change to show the Task parameters. In here, enter the url as https://examplecrm.frends.com/api/customers and make sure Method is GET. Rest of the options can be left as-is for this example.

Once the Task is configured for our use, we need to connect it to the earlier shape. To do this, click on the Connect tool from the left toolbar or from the quick toolbar next to the Trigger shape, and draw an arrow from the Trigger to the Task shape.

Finally, we need to end the Process and save it. All Processes start with a Trigger, and end to a Return shape, or optionally to a Throw shape. Let's drag a Return shape to the right side of the Task, and connect it to the Task shape to create a complete Process flow.

For the example, we want to return the API response's body. We can do this by selecting the Return shape, and writing #result[HTTP Request].Body to the Expression field. Make sure the field's type is set to Expression, and not Text, in order to Frends consider the content as C# code and not text.

Once ready, we can validate and save the process. You can optionally provide a Description or a comment to version history, what was changed in this version. It's recommended to always include a short comment on what was done.

Validation at this point means that the Process is taken through C# compiler and checked for errors, but it does not save the Process in any way. To save the Process for testing and deployment, select Create new Process. Saving the Process also validates it for errors, but save is not done if any errors persist.

When editing a Process, the save button changes to Save changes. If you want to save your Process but not create a new version for use yet, you can instead select Create new draft from the small arrow menu. This way you can save your work even if the Process is not yet valid.

Once the saving and validation succeeds, you are taken back to Process list view with your new Process highlighted at the top of the list. From there, you can run it, deploy it or continue editing, among other options.

Once Processes have been created and possibly initially tested out, it's usually recommended to deploy them into another Agent Group for further testing as well as for production use. This guide will take you through the steps and requirements to do so.

Step by Step Tutorial Available

If you prefer more visual or interactive guidance on how to deploy Processes with Frends, you can find a step-by-step walkthrough from your own environment's home page, under Onboarding by selecting "Tutorial 4, Step 5: Deploy my first integration" tutorial.

Requirements

In order to be able to deploy Processes to another Agent Groups and Environments, you will need to have configured at least one other Agent Group in your Frends Tenant. While the Agent Group can be in the same Development Environment as is provided by default, it makes sense to add another Environment at the same time.

After deployment, you will also need an Agent, a Frends runtime executable on a server, within that Agent Group in order to execute the Processes deployed there. Not having an Agent will not block deployment, however, so you will not need any extra hardware or server configuration in order to follow this guide.

Environment Variables and Subprocesses

In case your Process is using Environment Variables and/or Subprocesses, there are some actions that need to be taken before deploying a Process can be done.

First off, any Subprocesses used in your Process must be deployed before the Process can be deployed. Deploying a Subprocess is done in exactly the same way as shown in this guide for Processes, but in Subprocess list view, of course.

Secondly, all used Environment Variables must have a defined value for the target Environment before Process deployment. This ensures that all values are there for the Process and it can be executed after deployment.

How to deploy a Process

In order to deploy a Process, head to Process list view and select the Environment and Agent Group where the wanted Process version resides. This is usually the development Agent Group if we want to deploy the latest development version, or testing Agent Group if a tested version of a Process is being deployed to production.

During deployment an older version can also be chosen to be deployed, but to deploy the very latest version of a Process you need to deploy from the development Agent Group.

When you are in the Process list, browse or search for your Process, and click on the ellipsis button on the right side of the row. This will open the actions available to do for the Process.

To begin the deployment, select Deploy Process to Agent Group. This will open a new modal dialog that will have the options and actions for deploying the Process.

First option to select is where do you want to deploy your Process to. By default, the next Environment's first Agent Group is selected. Order of these can be changed when creating and modifying the Environments and Agent Groups.

After selecting the target Agent Group and thus the Environment, you can also change which version of the Process will be deployed. This will also show where each version is deployed to already.

When editing a Process, a new version will be created each time, but only to the Development Environment. In order to push the changes to other Agent Groups and Environments, the Process needs to be deployed.

By default, the latest version within the current Agent Group is selected, and this is most often the version we want to deploy.

To finally actually deploy the Process, we have two options: Deploy and activate Triggers, or just Deploy.

When Triggers are activated for a Process, it means that any automated execution conditions for our Process will become active, and the Process will execute when the conditions match. When in deactivated state, even if the Process has for example a Schedule Trigger, the Process will not start automatically. Manual execution can be done in both states, however.

Deploying and activating Triggers will enable the Process to be automatically launched as soon as the deployment is complete. Only deploying the Process without activating Triggers will leave the state of the Process as it was before in the target Agent Group. If the Process was active before deployment, it will stay active afterwards as well.

By clicking either button, the Process will get deployed to the chosen Agent Group if everything went OK and all preparations were complete. In case there were any errors or missing details, an error will be shown and the dialog will not close. Most common error is that the Process is using Subprocesses or Environment Variables, which were not defined and deployed before deploying the Process.

In order to run a Process when you need it, instead of relying on automation from the different Triggers, there's a useful action called Run once for the Processes and Subprocesses in Frends. This will execute the Process with the Manual Trigger commonly available in Processes.

Step by Step Tutorial Available

If you prefer more visual or interactive guidance on how to run Processes manually in Frends, you can find a step-by-step walkthrough from your own environment's home page, under Onboarding by selecting "Tutorial 1, Step 4: Running the Process" tutorial.

Requirements

To run a Process manually or automatically through Triggers, an Agent is required in the Agent Group the Process is deployed to. Agents are what actually perform the actions defined within Processes, so in addition to Environment and Agent Group, you will also need an Agent on a server or computer to run Processes.

Frends at a minimum comes with Development Environment with a Cloud Agent set up, so it's not required to have your own Agents running to follow this guide, but for other purposes than light testing or development, it's recommended to set up your own Agent as well.

Having a Manual Trigger in Process is not required. In case there is no Manual Trigger in a Process, an implicit Manual Trigger with no parameters will be used to trigger the Process. However, if the Process expects some values from an API Trigger for example, the values cannot be provided and the Process execution will likely fail.

How to run Process once

In order to run a Process manually, head over to Process list and select the Agent Group you would like to execute the Process in.

When correct Agent Group is selected, find your Process from the Process list and click on the ellipsis button to open Process actions.

You can then select Run once to launch the Process.

In case there are any parameters defined in the Process's Manual Trigger, the values will be prompted from the user before starting the Process. If there are no parameters defined, the Process will launch immediately.

Once the Process has started execution, you can go ahead and open the Process Instances for the Process to see what is being done within the Process execution.

In order to see what happened during integration flow execution, Frends has a view called Process Instance.

Step by Step Tutorial Available

If you prefer more visual or interactive guidance on how to view Process logs with Frends, you can find a step-by-step walkthrough from your own environment's home page, under Onboarding by selecting "Tutorial 2b, Step 2: Process Logs" tour.

Accessing process instances

The Process Instances are accessible through Process list by selecting Show Process instances. You can also access the Process Instance list by clicking on Last execution or Instance counts per day columns from the Process list.

Then selecting any of the Process Instances on the Process Instance list will take you to the chosen execution's Instance view.

Process Instance list filters

In the Process Instance list, you can filter the shown Instances using time period and the state of the Process Instance. The search also supports searching for results and values promoted from the Process execution using SQL wildcards.

The Instance list is automatically refreshed by default, to show the current state of the executions in almost real time. In case there are a lot of executions happening, setting the Auto refresh to Off might help in focusing on the earlier executions.

Process Instance view usage

From the Process Instance view it is possible to see what happened at each stage of the execution, shape by shape.

From the view, it's possible to click on the Process elements to see details of that part of the Process. Depending on logging settings in the Process as well as in the Agent Group, some details of the execution might not be always visible.

Functionality in the Process Instance view is similar to Process Editor view, but instead of allowing editing the Process and shape details, it shows what happened during the execution.

Common information shown for each shape are:

• Start time, when the execution of chosen shape was started

• Duration, how long the execution took for that shape

• Task or Expression, what was executed

• Result, showing what was the result of the execution

If extended logging is enabled for the Process or Agent Group (Log everything in Log settings), the input parameters are also logged and shown here. Because extended logging has some impact on performance, this level of logging is recommended to be used only temporarily. The Log settings provide an easy way to set Log everything for only a specified duration.

It's also possible that log settings were adjusted so that Only errors are logged, or Skip logging result and parameters is enabled for some elements in the Process. In these situations details for successful shape executions are not logged. This is useful for production use, when there can be many and more executions and as long as there are no errors, most details of the executions are not needed.