◷ Reading Time: 4 minutes
FlexRule Server will setup a platform for managing business logic (i.e., rules, decisions, flow, etc.). It exposes this logic as a REST API for execution. It also provides the capability to manage and monitor different parts of its infrastructure as well as your business logic.
Generally, FlexRule Server has two individual processes:
- Master
- Agent
Each of them is responsible for different tasks.

General Process
FlexRule Server offers a business logic server which has two main responsibilities:
- Management: Allows the management of logic and nodes
- Execution: Runs the logic models by providing values and returning the results
FlexRule Server is built on top of two different types of nodes to process requests:
- Master Server node
- Execution agents node
These can be installed on one machine, but ideally you will distribute them across your network on different machines for scaling the execution process. When requests come to a Master, it looks into the pool, selects free and healthy agents, and send the execution requests to the agent. Once the agent executes the logic, it returns the result back to the Master and the Master sends the result to the requester.
Master
Master Server has different parts:
- API host
- Executing logic (only if configured)
- Security control
- Authorization (OAuth – password flow)
- RBAC permission control
- Managing resources (e.g., Packages, Users, Accounts, Permissions, etc.)
- Monitoring Health (e.g., Database, Master server, agents, etc.)
- Logic Repository
- Log Repository
- Workbench host
- Job distribution and management
Agent
ExecAgent is the processing node that executes the logic. This uses FlexRule Runtime to load and execute logic. You don’t necessarily need an Agent node. You can add it later on for scalability purposes.
Agent node responsibilities are about Logic Execution only:
- API
- Logic execution
- Job dequeue
Deployment Strategy
There are many difference choices of deployment for FlexRule Server, each of which are designed to answer different architectural concerns.
One Node
When a simple deployment is required, One Node can be used to deploy a Server with a minimum configuration and set up. This model is the Master only model. In this scenario, the Master itself will take care of both the management and execution of logic.

You only need to install the Master on a machine.
Two Nodes
Balancing between the Management and Execution responsibilities of a Server can be implemented by using this deployment strategy. This allows you to split management and execution responsibilities into two Nodes.

You need to install a Master and an Agent. The Agent can be either on the same machine than Master or different one.
Master with Distributed Agents
This deployment strategy enables high-availability scenarios. This mode allows you to create a cluster of processing power for your logic. Which means when a Master receives the execution requests, it will distribute them to Agents for processing.

You need to install the Master and Agents on different machines.
Distributed Masters and Agents
This deployment strategy allows for high-availability and fault-tolerance for requests from clients and can be built via deploying multiple Master Nodes and putting them behind a load balancer that routes requests based on load. If a Master Node is down, then your load balancer can route the request to another available Master Node. Master Nodes have access to the same pool of Agents.

This strategy requires sharing the database between Master Nodes. To set up a database shared across all the Master Nodes, you need to use the MS-SQL database provider.