Task

In order to perform most functionalities in Frends Processes, Tasks are the core building blocks. The effectiveness of Frends is built on top of Tasks (and BPMN), connecting the Process to outside world and systems and also helping with data manipulation for the general use cases.

What is Task?

Tasks are the bread and butter of Frends, providing pre-defined functionality as a drag and drop shape to the Processes. They can be used for general actions, such as making HTTP requests and converting CSV to JSON, as well as for more specific tasks, such as uploading an object to Amazon S3 or deleting an SObject from Salesforce.

Many types of Tasks are included in Frends out of the box, and more can be obtained by importing other premade Task Packages as well as your own custom Tasks to your Frends Tenant.

The Tasks are essentially pieces of C# code that are packaged and interfaced so that they can be placed into the Processes, so in case you need functionality that is not yet offered by the official or other Task Packages, it's possible to create your own Custom Tasks, or make a request for a Task to be made for you.

Types of Tasks

While the exact number of different Task types is ever changing and growing, Frends currently supports integrating to hundreds of different systems and environments, with multiple Tasks available for each system, for different operations. And that is only accounting for the officially supported Tasks and systems. In addition, there are countless custom Tasks made by our users for their own use, of which some of them have published as community Tasks as well.

In order to find out more about the officially supported Tasks, you can check out our Tasks directory at https://tasks.frends.com to see if a Task exists for your use case. You can also check out the Task management view in your Frends Control Panel to see what Tasks have already been imported, and what is available for import.

If a Task does not yet exist for you, please make a request for it. Or, if you prefer, creating your own custom Task is always possible. All the Tasks are open source, so any one of the official Tasks can be easily adapted to your own use case with some C# programming.

For example, Tasks exist for at least the following target systems and technologies to perform integrations with:

Usage

To use a Task in your Process, simply add a Task shape to your Process Editor, and connect it as part of your Process between a Trigger and a Return or Throw shape. Tasks are always one sequence flow in, one out, with optionally an Intermediate Return or Catch shape connected to them in addition.

After adding the shape to your Process, you need to select the type for your Task, which defines what it actually does in your Process. Selecting the type will also provide the Task a display name, which can also be defined before selecting the Task type, and changed afterwards to suit your needs.

If, and when, your chosen Task type requires input parameters, fill those in as needed.

After the Task shape, if you need to use the result of its operation in your Process, you can access it using #result reference value in later phases of your Process. You can use either the unnamed #result reference to access the result value, or specify the name for the #result reference as #result[Name of Task] to be sure you are referencing this specific Task, and not the latest #result in general.

Architecture

While Tasks do not directly interact with Frends architecture, Tasks are used to perform most of the connectivity and operations in Frends Processes. As such, Tasks can have effect and require actions in your infrastructure through requiring firewall openings, available resources for performance as well as require permissions to internal or external resources and data, depending on the use case.

Behind the scenes, Tasks are snippets of C# code that will be executed on your Agent's .NET runtime, as part of the Frends Processes. While the official Tasks are designed to be safe to use and form the core of how Frends is designed to operate, custom Tasks from external sources could have security implications to your environment due to introducing unknown code to your execution environment. Make sure you trust the authors of any custom Tasks before importing and running them as part of your Processes, and review the source code in case there is any doubt about the legitimacy of a Task.

Configuration

To set up a Task shape, add it to your Process canvas and connect it to your Process flow using Sequence flows. After this, you can configure the shape to required type and values.

The following configuration parameters exist for Task shape.

Display name

Shapes can be given a display name in Frends Processes to distinquish them from each other. Shape's display name has no technical purpose and is only for documentational and visual purposes only. For shapes returning a #result reference value, the display name can be used to specify which result is meant.

Display name is given to the shape by double-clicking it on the canvas or through its configuration parameters.

Type

Task shape's type specifies what the shape does and thus what configuration parameters it has available. You can check the possible types at Types of Tasks section of this article.

Skip logging result and parameters

Toggle option to select if the values of this shape should be included in logging or not. Default is false. If set to true, Process Instance logs will show the result and parameter values of this shape as << Omitted >>.

Dispose at the end of the scope

Toggle option to select if the result and other memory allocations should be released after the containing scope exits. The containing scope can be the Process execution itself, Scope shape, or a single iteration of Foreach or While Scope shape.

Can be useful if the shape results in a large amount of data, allowing its early release from memory if it's not needed later in the Process.

Promote result as

Toggle option to select if the result value of this shape should be promoted in the Process Instance list, and an text input field if set to true. Default is false. Promoted values appear in the Process Instance list in their own column along with error and result values. Promoted value column is named with the text input field appearing when this is set to true.

Promoted values are always logged fully in the Process Instance view, regardless of the log level settings.

Retry on failure

Toggle option to select if the execution of this shape should be retried automatically, in case it results in an error. When set to on, the upper limit of retries can be set before ending the execution in failure.

There is an increasing delay time between the retries. After first attempt the delay is one second, and the time is doubled after each attempt, up to 512 seconds at 10 retries.

Reference Values

Task shape provides a #result reference value, which contains its operation's result values.

#result

#result reference value can be used to access earlier shape's return value. For Scope shapes, the value is specified using Return shape, while for Task's the #result is populated directly by the Task.

When Return shape is used to end Foreach or While shapes, the expression or HTTP content values in Return shape are available through #result reference value as an array of values for each iteration.

#result reference value by default references the last Task's or Scope shape's return value. Instead of unnamed #result reference, you can also use named #result reference value.

Named #result

Named #result reference value is used with square brackets, much like dictionary's or object's fields would be used, such as #result[Handle elements] or #result[HTTP Request]. This way it can be specified which shape's result you are using.

When using named #result reference value with Scope shapes and Return shapes, it should be noted that the #result reference value is named by the Scope shape and not by the Return shape, although the value is specified in the Return shape. Thus, when using the named #result value, such as #result[Handle elements], the Scope shape's name should be used.

Examples

You can learn more about Task shapes from the following guides and examples.

How to create a Process with Frends

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.