Trigger

Triggers play a crucial role in Frends, acting as the initiators for process executions. These Triggers are events or conditions that, when met, start a workflow within the platform. Here’s a deeper dive into their functionality and use cases.

What is Trigger?

In Frends, Triggers serve as vital components that automatically start Processes by responding to specific events. Triggers are adaptable, ranging from HTTP requests to changes in file directories, allowing developers to tailor the start of a process to meet their needs. For example, an HTTP Trigger can seamlessly activate a Process in response to a web service call, while a File Trigger can initiate Processes for data synchronization or document processing.

Frends platform ensures Processes are activated precisely when needed. This automation not only ensures prompt responses to events but also optimizes resource allocation by allowing the Processes to execute only when truly needed. With Triggers, Frends provides a powerful and user-friendly solution for managing and automating workflows effortlessly.

Types of Triggers

Frends provides multiple different Triggers for the majority of use cases out there. In case a predefined Trigger does not exist for your use case, there is always the option to use Conditional Trigger, to which you can specify the logic as a Subprocess, making possible to monitor and react to anything that happens in other systems, that might require a Process to start.

You can view the Trigger-specific details of each type at their respective page.

Manual Trigger

Manual Trigger does not contain automation, instead the Trigger is executed only when user starts the Process. In Subprocesses, this is the only type of Trigger available, starting the Subprocess when called by a Process. Parameters can be added to the Trigger, which are then prompted from the user when running the Process, or in the Process development when Subprocess is added.

File Trigger

File Trigger monitors specified locally mapped directories for new files to initiate Processes. Ideal for handling file-based data exchanges and automation.

Schedule Trigger

Schedule Trigger relies on time-based scheduling. You can set specific times or intervals to start a Process. This is ideal for tasks that need to be performed regularly, such as daily reports or data backups.

Conditional Trigger

Conditional Trigger starts the Process when a condition is met. The condition is defined as a Subprocess. Subprocess is executed with a specified time interval, and the logic within Subprocess decides if the main Process should start or not.

HTTP Trigger

HTTP Trigger starts the Process in response to an incoming HTTP request. This is useful for API integrations, allowing external systems to invoke Frends Processes via web requests. HTTP Trigger does not contain OpenAPI specification or API Management features, the Process acts as a standalone API endpoint.

API Trigger

API Trigger, like HTTP Trigger, the Process is started in response to an incoming HTTP request. Unlike HTTP Trigger, API Trigger requires OpenAPI specification to be created in API Management before this can be used. Fields defined in API spec are included automatically as Trigger variables in the Process.

AMQP Trigger

AMQP Trigger or Queue Trigger listens for new messages in AMQP 1.0 message queues and activates Processes accordingly. Suitable for event-driven architectures where asynchronous communication is key.

Service Bus Trigger

Service Bus Trigger is like AMQP Trigger, and listens for new messages in Azure Service Bus queues and topics, and activates Processes accordingly. Suitable for event-driven architectures where asynchronous communication is key.

RabbitMQ Trigger

RabbitMQ Trigger is like AMQP Trigger, and listens for new messages in RabbitMQ message queues and activates Processes accordingly. Suitable for event-driven architectures where asynchronous communication is key.

Azure Event Hub Trigger

Azure Event Hub Trigger is much like AMQP Trigger, and listens for new content in Azure Event Hub messaging system and activates Processes accordingly. Suitable for event-driven architectures where asynchronous communication is key.

TCP Trigger

TCP Trigger is similar to API and HTTP Triggers, but instead of having incoming HTTP request, the Trigger listens for raw TCP messages coming to network interfaces on the Agent machine. Process is triggered by TCP Trigger once a complete message has been received, up to the defined end of message bytes.

Usage

Triggers are used when developing a Process to specify how the Process starts. They are the first shape in the Process Editor canvas. You can then configure the Trigger to match the integration scenario that is being developed.

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 as well as run on schedule every 6 hours.

When using multiple Trigger shapes, they all must be connected to the same first non-Trigger shape in the Process. In case you need to identify which Trigger was triggered, you can use Decision shapes to check #trigger.name or #trigger.type reference values and act accordingly.

Subprocesses can only have one manual Trigger, to which the parameters for that Subprocess are specified in.

Scopes and other container shapes also have one Trigger shape included in them, but they do not provide any configuration options or parameters, and they cannot be referenced through #trigger reference. They simply act as the starting point of that Scope. They also cannot have more than one Trigger shape in them.

Environment Variables in Trigger parameters

Environment Variables can be used in Trigger parameters for fields which accept text input, such as File Trigger's File filter or Conditional Trigger's Subprocess parameters. The format in which those are input varies slightly from the usual expressions within a Process.

While typically a field is chosen to be either Expression or Text, which determines if the expected input value is in C# code or plain text format, Trigger parameter fields will always be considered as Text fields, with a caveat. Environment Variables can be input directly into Trigger parameters using the #env reference values, without using Handlebars ({{}}) syntax. Environment Variable references are translated directly into their value, while all other text content will not be evaluated.

For example this is a valid input for a File Trigger filter:

FilePrefix#env.ExampleGroup.FileName #env.ExampleGroup.FileSuffix

And would produce a value such as "FilePrefixFileName .csv", if content of the Environment Variables were "FileName" and ".csv". Note that the space between or after Environment Variable is required to separate the name of the Environment Variable from other input.

If the input value contains Handlebar characters or other C# code, those will not be evaluated, like in this example:

{{#env.ExampleGroup.FilePrefix}}_{{DateTime.Now.ToString()}}.csv

The result for that input in a Trigger parameter would result in something like the following, not evaluating the Handlebars or the included C# code, except for the Environment Variable reference value:

{{FileToSearchFor}}_{{DateTime.Now.ToString()}}.csv

Manual Trigger parameters for a Process are the only exception to this. Parameter input fields for a Manual Trigger do not evaluate any reference values or C# code.

Architecture

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

Configuration

To set up a Trigger in Frends, navigate to the Process where you want the Trigger and include the appropriate Trigger type. Define the Trigger's parameters, such as the schedule for a schedule Trigger or the URL pattern for an HTTP Trigger. These configurations determine when and how the Process gets executed.

You can read more about the configuration options for Triggers on each Trigger type's page. All Trigger types include these configuration parameters.

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.

Trigger's name is available through #trigger.name reference value. Trigger's name parameter is the display name value that is commonly available for all shapes in Frends.

Type

Selection for type of Trigger. This parameter defines how the Trigger is triggered, and enables different configuration options for the Trigger. Trigger's type is available through #trigger.type reference value.

Reference values

Triggers provide the #trigger reference values to the Process. While each Trigger type provides slightly different set of values, these are the common values for all Trigger types.

In case there are multiple Triggers in the process, only one of the Triggers will be executed for each Process Instance, and that Trigger will be the one to provide the values for the reference.

#trigger.name (String)

Name of the Trigger that was executed, defined in name parameter.

#trigger.type (String Enum)

Type of the Trigger that was executed, defined with the Trigger type selection.

Can contain the following values:

#trigger.username (String)

Username of the user who started the Process. The exact value can vary between Trigger types. In case of manual Trigger, this is the username (email) of the user in Frends Control Panel. In case of API Trigger, this is the name of the API key used to connect to the API, if API key is used as the authentication method.

Examples

You can learn more about using Triggers from the following examples.

How to create a Process

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.