Frends Agents are remote execution runtimes that execute Processes.

Each Frends Agent works independently from other components and does not rely on any other component to function, for example the Frends Control Panel can be offline for maintenance, but the Agents will still execute Processes and respond to requests. The Agents communicate with the Frends Control Panel through a Service Bus connection; Azure Service Bus for cloud or hybrid installations, and Service Bus for Windows Server or RabbitMQ for on-premises installations. The Agents will receive configuration updates etc. through Messaging queues, and also use them to report execution logs and statistics.

Agents update the deployed integration flows automatically after receiving an update notification through the Messaging queue. This means that once you click "Deploy" on the Control Panel the Agent will automatically download and take into use the desired version of a Process.

Each Agent is assigned to an Agent Group.

It is possible to execute part of a Process on a different Agent. This is implemented by using a Remote Subprocess call. One scenario for such a set-up is where a Process is triggered in a cloud Environment. The Process contains a Subprocess call, which is a Remote Subprocess call. In the remote call the Subprocess is executed by another Agent, for example in an on-premises Agent Group. Remote Subprocesses are executed over an Azure Service Bus connection or RabbitMQ. There is a separate message sent as a request and another message as the result response.

API Gateway Agent

There is also a specific Agent type called an API Gateway Agent. You can install API Gateway Agents to public-facing servers without exposing your actual execution Agents with connections to internal systems to public network traffic. API Gateway Agents expose API and HTTP Trigger endpoints and forward valid requests to the execution Agents. They also authenticate and validate the requests before forwarding them upstream and throttle excessive requests. API Gateways are always configured as part of an Agent Group, and by default, they will expose the same API and HTTP Triggers as the execution Agents. You can choose to set an API or HTTP Trigger as private, which means the gateways will not expose them; they will only be accessible from the internal execution Agents.

The API Gateway Agent can act only as load-balancing proxies in front of Agents executing Processes. The gateway polls each Agent every second and removes or adds the Agents to the routing pool accordingly. A forwarded request that fails due to an unexpected error, such as a network disconnect or timeout, will also cause the Agent to be removed from the routing pool. The Agent will be returned to the pool once the gateway can successfully poll it. The traffic to upstream Agents will be routed to their configured external URLs.

If the Agent Group has more than one executing Agent, the API Gateway will do simple load balancing between them in a round-robin fashion. The API Gateway polls each agent every second and removes or adds the Agents to the routing pool accordingly. A forwarded request that fails due to an unexpected error, such as a network disconnect or timeout, will also cause the Agent to be removed from the routing pool. The Agent will be returned the pool once the gateway can successfully poll it.

API gateways are installed with the same installer as any other Agent; the configuration tells the Agent to work in proxying gateway mode.

Where can Agents be installed?

Agents can be installed on several different kinds of technology platforms:

and hosted by

The next article is Introduction to Technical Information about Frends Agents
​