Skip to main content
All CollectionsArchitectureFrends Platform ArchitectureConnectivity
Introduction to How Frends creates and runs Processes
Introduction to How Frends creates and runs Processes

A quick and very technical tour to internal working of Processes.

Ossi Galkin avatar
Written by Ossi Galkin
Updated over 6 months ago

Frends makes things happen under certain conditions or Triggers. The conditions can be “it’s noon”, “there’s a new file in C:\MySecretFileStash”, “someone made an HTTP call to example.com/makestuffhappen or something else.

Once the conditions are met, the things which are described by the Tasks in the Process or service will be executed. Tasks can be anything from retrieving information from a database to converting information from one format to another to sending an email. There is a set of ready made Tasks that come with Frends, but you can also make your own.

But what actually happens when we create and run the Process?

We first create the Process in the GUI on the website. Once the Process is created, it is stored to the website’s master configuration database. A NuGet package is also created and stored in the master package repository a.k.a. the NuGet store, and a message notifying all connected entities of the new Process is sent to the Service Bus.

Frends website is accessed by an HTTPS secured connection. Configuration data in the Azure database is Encrypted-at-Rest. Login to the website is done using either a frendsapp Azure AD credential, the tenant's own SSO, or a local user credential if the Frends UI is installed on-premises. The NuGet store is located in Azure Blob Storage and accessed with a TLS secured connection for cloud and hybrid installations. In the case of on-premises installations, the NuGet store is accessed through a file share. Access to the Service Bus (either on Azure or on-premises) is secured by a TLS connection. Azure Blob Storage is used for the Large Message Store (for transmitting large messages offloaded from the Service Bus) in cloud and hybrid installations and a file share is used for on-premises installations.

These things happen as soon as the Process is created.

When the Agent receives the message about the new Process, it will fetch the NuGet package containing the Process, as well as the NuGet packages containing the Tasks within the Process, from the master package repository. It will then expand the Process in its own Process store. All Processes are deployed automatically to the Development Environment and deployment to other Environments can be started from Frends UI. 

Cloud Agents use Azure SQL, and on-premises Agents use either a SQL Server Express LocalDB database or a SQL Server database (necessary for HA deployments).

As soon as the Agent knows of the new Process, it will retrieve it from the repository.

When the Process is activated via the GUI, a message is once again sent to the Agent, via the Service Bus, explaining that the Trigger is now active. The scheduler within the Agent polls the Agent’s database once a second to see, whether a Process is scheduled to run. At 2:30PM, the scheduler tells the Agent to run our Process.

The Process is activated.

The Agent will start running the Process. It also sends a message to the Service Bus, saying it’s beginning to run a Process. The message processor takes the message and saves it to the log index. Logs are stored in the same database as configurations. The website receives the message from there and updates its database and the GUI accordingly.

The Agent informs the website that it’s starting to run a Process.

After the Process is run, the Agent will again message the GUI via the Service Bus and message processor, giving details of the execution. The website once again updates its database and GUI accordingly, and we can see how things went.

The Agent informs the website that it has finished running a Process.

Did this answer your question?