Recommended Configuration

In order to have a good user experience, we recommend to deploy Flowster Studio components on a shared environment with system resources close to recommended or higher. 

Flowster Studio components are grouped into three clusters:

• Engine: contains the Rest API (Micro services based), Platform Health (Logging component), Compatibility (Utility component for .NET Framework), and Scheduling (Component which handles delayed executions)
• Execution: contains the Execution Agent
• Clients: contains Web (Portal & Administrator), Web Apps services

Flowster Studio components can be deployed as follows:

• 2 Flowster Studio - Engine component on 2 different servers using the same Flowster Studio database (1 main engine and 1 additional engine)
• 2 Flowster Studio - Execution Agent component on 2 different servers using the same Flowster Studio database (for a better performance we recommend to use dedicated servers, different than the Flowster Studio - Engine servers)
• 2 Flowster Studio - Portal component (for a better performance we recommend to use dedicated servers if the traffic caused by the number of users is high)

High Availability & Load Balancing

Load balancing is the process of distributing network traffic across multiple servers. This ensures no single server bears too much demand. By spreading the work evenly, load balancing improves application responsiveness. It also increases availability of applications and websites for users. Another advantage of using a load balancer is to achieve High Availability in the case of one system going down the other additional servers will take the load and the system will still be available for the users.

Any Flowster Studio component with an open endpoint can be load balanced. We recommend to use load balancers for Flowster Studio - Engine servers which usually are under heavy load and for the Web Clients if the traffic caused by the number of users is high. 

To summarize, the only components which do not expose an endpoint and cannot be load balanced are the Scheduling, Execution Agent services and the Designer application. All other components can have a load balancer in front to ease the traffic towards those specific components.

NOTE:

The Flowster Studio - Execution Agent component cannot be load balanced directly as it does not have an open port however you can load balance the Logging component to which the Execution Agent connects which assures load balancing for the workflow executions. Another option to obtain both HA and LB is by installing multiple agents to help the execution load and send the executions to an appropriate agent based on the internal Score from the workflow queue mechanism.

Scalability

Scaling is when you increase the number of processing machines (computers, processors, servers, etc.) to increase processing power. To scale horizontally (or scale out) means to add more nodes to a system, such as adding a new computer to a distributed software application.

Flowster Studio clusters can be scaled in order to achieve optimal performance. For example multiple engines can be installed using the same database in order to split the load if there are many queries which need to be executed. Multiple Execution Agents can be installed in order to execute more workflows simultaneously, or in different environments and last but not least multiple clients (Portals) can be installed and connected to a load balancer in order to split the load if a large number of users want to use the client at the same time.

Centralized Repository Path

The Centralized Repository Path is set during the installation and it was introduced for a better management of the activity library dlls involved in the execution process of workflows (remote execution via Execution Agent or local execution via Designer). The Centralized Repository Path should always contain the latest versions of dlls. In order to synchronize the dlls from Centralized Repository Path and dlls from Execution Agents, restart FlowsterNewExecutionAgentService services and the dlls will be updated to the ones from Centralized Repository Path (only the newer versions of dlls from the Centralized Repository Path are updated in the Execution Agent activity library directory)

In order to synchronise the local activity library from Designer application, please check 2.1.1 Update Local Activity Library. 

Users can change the Centralized Repository Path ONLY from the master database, by updating the App_Settings table.