Breaking changes in 5.3

New outbound ports required to be open for the Agent when using Azure Service Bus: 5671 and 5672. If outbound access is being limited for the Agent, those ports need to be opened outbound to the Azure Service Bus. As a workaround the transport type can be set to Amqp Websockets by adding:
to the Azure Service Bus connection string. After this the Azure Service Bus connection will use port 443 for outbound connections.

Swagger/OpenAPI validation and handling is more strict:

  • Security definition for ApiKeys requires the correct 'name' property X-ApiKey to work correctly in the SwaggerUI hosted by the Agent (FRENDS always requires the ApiKey to be either in the Authorization header with the ApiKey scheme or in the X-ApiKey header.

  • To ensure better compliance to the format the Agent expects, we suggest converting to OpenAPI 3.0 before making changes to API definitions

API Trigger query parameters are now typed when passed to the Process, this might affect Processes which expected them to be strings.


24th of February 2021

This service release contains the following changes/fixes:


  • Deployments have a comment field and a deploy time and initiator attached

  • Environment variables can be exported and imported

  • Custom API key location support for API Triggers

  • New Swagger/OpenAPI specs target OpenAPI 3.0 now by default

  • API Management page load speed improvements

  • Fixed a bug with Process automatic update checkbox not being rendered when updating Tasks

  • Fixed link to SwaggerUI on Cross-platform Agents when the API requires an API key for viewing

  • Security improvements

  • Monitoring rules view redone


  • Core Agent startup is no longer aborted due to Trigger initialization errors

  • Redundant OAuth validation validation removed for requests that do not require OAuth. (This had no functional effect, but it created misleading log events)

  • Legacy and Core Agent's API Swagger UI now work with the same redirect URI

  • Core Agent will no longer try to load Framework Processes causing errors

  • Fixed a bug where API Trigger SwaggerUI pages were not created correctly

  • Increased Service Bus retries and logging

  • Development Environment now supports multiple Agent Groups

  • Fixed bug with blob step logging which could cause steps not to be logged for a Processes

  • Speed of scrubbing large censored parameter structures improved

  • Fixed bug with foreach parameter not being censored when "Skip logging results and parameters" is selected


10th of July 2020

This service release contains the following changes/fixes:


  • Fixed an issue where intellisense was not being shown for #result[TaskName] in some cases

  • Fixed an issue where intellisense suggested the wrong path for API Trigger's body

  • Editing a Manual Trigger for a Process now correctly shows the save button

  • Improved some error messages when validating API Specifications

  • Fixed monitoring rule operator not being passed correctly to the backend

  • Notification error message now has a button for copying to clipboard


  • Agent NuGet packages are now cached locally increasing Process deployment speed

  • Agent initializes Process directories greedily to speedup first executions of a Process or a Subprocess

Log Service

  • Process step log Blob cleanup speed improved by using batch operations on Azure Storage


10th of June 2020

This service release contains the following changes/fixes:


  • You can now export Process instances as CSV

  • Restoring a Task version now correctly restores both Standard and Framework Task definitions

  • Process version change messages can now be appended with additional information

  • You can now use select multiple Tasks to filter the Process list

  • Process instance list retains filter options after navigating back from a Process instance

  • Minor bug fixes


  • Condition shapes now respect Process cancellations

  • Processes add usings and references to external types and assemblies defined by Tasks


  • Tasks may now specify external parameter types (not in the same assembly as the Task) to be expanded

  • Inherited methods may now be used as Tasks when specified

  • Tasks may specify another NuGet package which should be downloaded when discovering Tasks (that have external parameter types)


  • Azure Storage Client libraries updated to latest version

  • Added timeout on Agent's Process deployment, preventing a single deployment from freezing all Process deployments

  • Revised Kubernetes configurations and documentation

API Trigger fixes

  • Path level parameters are now passed correctly to Processes

  • CSV array in query parameters are now passed correctly as an array instead of a single string

  • Parameters are handled in a case-insensitive fashion as per specification

  • Saving a Process (with API Trigger) which is removed from the API specification is now blocked


4th of March 2020

This service release contains the following changes/fixes:


  • Promoted variables can be viewed in the Process list

  • Process change log messages can be appended

  • Monitoring rule page remade:It is now possible to have rule specific email recipientsRules can be modified after creation


  • Process and Environment Variable auto-sync disabled for legacy Agents

  • File Trigger no longer spams the the event log and it's state is updated in the UI after a failure/recovery

  • Added memory limits to Agent Kubernetes specification templates

  • Updated Kubernetes deployment for etcd to 3.4.4 and added memory limits

  • Conditional Trigger allows editing obsolete(removed) parameters

  • Bug fixed: Cross-platform Agent HTTP and API trigger fail when CORS is not enabled

  • Bug fixed: Azure Service Bus fails to check subscription existence

Process compilation

  • API Triggers support binary body through

  • Bug fixed: Building .NET Standard Processes fails when C# Statement is used


2nd of February 2020This release has breaking changes, see them in here

Cross-platform Agent and Kubernetes support

Starting from version 5.3. there are two different types of FRENDS agents. Old Agent is now called the Legacy Agent and the new Agent is called the Cross-platform Agent. Legacy Agent is fully backward compatible with existing FRENDS installations.

Cross-platform Agent

A new version of the FRENDS Agent (the Cross-platform Agent) has been created which is based on .NET Core 3.0. This new version of the Agent can execute on other platforms in addition to Microsoft Windows. This makes it possible to run Agents inside lightweight Linux containers.

Because .NET Core and .NET Framework are not 100% compatible, the old Agent (now called the Legacy Agent) is still supported and existing Agents will not automatically be upgraded to the Cross-platform Agents. Cross-platform and Legacy Agents can be installed side-by-side in separate Agent Groups. This means that existing Processes will continue to work on the previously installed Legacy Agents as before, only moving to Cross-platform Agents will require additional work in the form of changing Processes to target .NET Standard, converting Tasks to support that and testing the changes.

Old Tasks developed for .NET Framework needs to be converted to multi-target .NET Framework and .NET Standard 2.0 to be executable on both types of Agent and provide the best level of backward compatibility.

Major differences:

  • The Cross-platform Agent supports ETCD as a shared datastore between Agent Group members in addition to SQL Server

  • The Cross-platform Agent has ready-made templates for deploying on Kubernetes

  • Only the Legacy Agent supports .NET Framework Tasks

  • The Cross-platform Agent uses SQLite as a datastore when installing as a single Agent deployment, while the Legacy Agent uses LocalDB as before

  • The Cross-platform Agent has better HTTP performance

  • The Cross-platform Agent does not have an installer for traditional installation on Windows

  • Cross-platform Agents may be configured register themselves dynamically so a Kubernetes based Agent Group can scale without manually creating Agents

Official FRENDS Tasks converted to .NET Standard

The official FRENDS Tasks have been converted to multi-target .NET Framework and .NET Standard 2.0. A few Tasks could not be converted fully because of external dependencies. These Tasks are Frends.Xml and Frends.ServiceBus.

  • Frends.Xml uses an external library for XSLT 2.0 and 3.0, and XPath 2.0 support. This library is not supported on .NET Standard so a new version of the Task 'Frends.Xml.Standard' was created without support for the newer versions of XSLT and XPath. The old Task will continue to work on Legacy Agents

  • Frends.ServiceBus supports Azure Service Bus and Service Bus for Windows Server, however, the library that has support for Windows Server does not support .NET Standard. A new Task 'Frends.AzureServiceBus' was created which only supports Azure Service Bus. The old Task will continue to work on Legacy Agents

New features on 5.3

These are available no matter which agent types you use. 

OpenAPI 3.0 support

FRENDS 5.3 now supports using OpenAPI 3.0 in addition to Swagger 2.0 for specifying APIs. The same features are supported as for Swagger 2.0.

Other improvements and bug fixes

  • Trigger parameter logging can now be prevented

  • Partition support when using Azure Service Bus improving resiliency needs to be enabled manually for existing elements

  • Conditional Triggers can be limited to a single simultaneous execution

  • Tasks view remade

  • Gateway no longer adds a second Access-Control-Allow-Origin header to responses

  • Remote Subprocess messages are now persisted if no Agent is receiving them

  • The Development Environment now allows multiple Agent Groups

  • On startup, the Agents only wait for log messages to be sent for a limited time (5 minutes) instead of waiting for all of them to be sent

  • Environments can now be reordered

  • Environment's and Agent Group's display name can be changed

  • Links in Process descriptions and change messages are now clickable

  • Duplicate connections between elements no longer cause a compilation error for Processes

  • A custom well-known metadata endpoint may be used with OAuth providers

Did this answer your question?