Overview
Automation Server executes your processes and delivers them to the desktops and mobiles of every business user.
For introductory information about Automation Server, refer to Automation Server.
The information presented here points out the most critical technical aspects that you should consider in your corporate infrastructure, in order to set up a Bizagi system architecture that performs under optimal conditions and according to official Bizagi Ltd recommendations.
Before you start
This information presented here is complementary to the sizing analysis you should carry out for your specific project (hardware sizing), and detailed documentation about specific system requirements (supported software configuration and versions).
For more information about system requirements, according to your specific platform, refer to System requirements.
The information presented here will not provide a guide to install or configure Automation Server or any of its required components, but it will serve as a reference architecture instead.
Concepts
The best practices and requirements presented here, consider a corporate Bizagi system architecture based on the following concepts.
High availability
A high availability architecture is designed to support best system reliability (enhanced service uptime), while implying the use of redundant IT assets that avoid single points of failure (i.e, typically for mission critical business processes).
Therefore, common recommendations such as using redundant power supply for your servers, two NICs per node, or maintaining an identical server configuration across nodes in clusters, apply for a Bizagi system architecture (along with any other similar measures).
Bizagi supports high availability by supporting cluster configuration across its different tiers, while allowing you to further scale-out the Bizagi cluster at anytime.
Bizagi product architecture
Bizagi is an intensive data-access application, which runs a light-weight application server, which is model-driven.
Therefore and given that Bizagi does not generate intermediate code, the database health and accessibility is critical.
It is strongly recommended that you make sure that the underlying infrastructure for Bizagi to access data is providing an optimal performance (avoiding data-access bottlenecks in general).
Regarding this architecture design, it becomes very important that your DBA performs continuous monitoring and tuning tasks, such as: Verifying the database integrity, updating database statistics, reorganizing and maintaining indexes, performing appropriate shrinks, or looking after the database growth behavior (i.e. filegroups, tablespaces).
Common recommendations regarding database maintenance and tuning, as issued by your database engine vendor, apply as well to your Bizagi database.
Reference system architecture
The following diagram illustrates a general Bizagi system architecture for a corporate setup.
The sub-sections below will elaborate on best practices and requirements to consider for the different assets in each tier.
Database tier
The database tier (data access layer) is where the database engine is installed (i.e, SQL Server, Oracle).
For high availability, use 2 or more nodes in a database cluster configuration (mainly for fail-over capabilities, or to use an active-active distribution when using Oracle RAC).
The following diagram highlights the database tier configuration, and which aspects are critical for best performance:
As pin-pointed above, consider:
1. DB SERVER.
•It is strongly recommended to use a dedicated database server to host exclusively Bizagi database.
This is so, in order to avoid having other databases take up the host resources and end up affecting Bizagi (or vice versa).
•Assign the most RAM possible to database servers, and according to your project's sizing estimation and keep in mind that you may scale-up the database server in terms of RAM allocation.
•If you are using Oracle, then you may choose to use an active-active scheme (Oracle RAC).
•It is especially important for the database servers to use high-speed disks (these will constantly perform I/O operations).
In case that you are virtualizing your servers (i.e on VMWare products such as vSphere, Hyper-V, or cloud compute services such as Azure or Amazon WS), then it is really important that the host machine provides high-speed disks as well and that the VM at the host is configured to use a reserved/dedicated amount of resources accordingly. For further detail on such VM set up recommendations, refer to Guidelines for Bizagi using compute virtualization.
2. NETWORK INVOLVING NODES AND STORAGE.
•Make sure an optimal network configuration for your cluster setup.
Optimal network characteristics must consider especially a low latency (e.g, usually accomplished by having the nodes of a database cluster in a same network segment or connected directly).
•Rely on your database engine vendor's official guidelines and recommendations when setting up the cluster.
Common recommendations such as using redundant NICs for cluster synchronization will apply.
3. PERFORMANCE OF THE PHYSICAL DATA REPOSITORY.
•Optimal performance of the physical data repository includes following best practices when setting up a SAN, and also providing a low latency between the database nodes and the shared storage, as well as ensuring you use high-speed disks for the underlying storage (e.g, using solid state drives), so that the I/O processes do not become a bottleneck.
•Regarding database files, it is very important that anti-virus software do not scan or interfere with them.
4. BIZAGI ODS.
•The use of Bizagi ODS configuration allows you to use BI features without affecting assigned resources for transactional operations.
Through this option, BI features (those which are not usually part of critical daily work, such as process analytics or reports) are run in separate database which is set up by means of replication technologies of the database engine per se.
This way, executing queries that typically involve large volumes of information will not impact your processes operations, especially if your system is highly concurrent.
Network between database and Bizagi
The network between the database and Bizagi servers (connectivity to the database), plays an important role in Bizagi system architecture.
The following diagram highlights this part and the aspect which is critical for best performance:
As pin-pointed above, consider:
1. BIZAGI SERVERS TO DATABASE
•Optimal network characteristics between the database and Bizagi servers, must consider especially a low latency (e.g, usually accomplished by having these servers in a same network segment, usually with a switch in between).
•It is important that an average latency of 0,15 ms is met.
A suggested bandwidth (e.g, for instance using optical fiber technology). considers at least 10,000 kb in 64ms.
Digital process tier
The Digital process tier is where Automation Server runs.
For high availability, use two or more nodes in a Bizagi cluster configuration with load balancing capabilities.
The following diagram highlights this tier's configuration, and which aspects are critical for best performance:
As pin-pointed above, consider:
1. LOAD BALANCER
•Use a hardware-based load balancer, such as f5.
Hardware appliances providing load balancing capabilities are known to support higher concurrency and overall perform better than software-based load balancers.
•While using a load balancer, make sure that you configure session affinity regardless of the employed algorithm (e.g, in a .NET-based environment, this concept is known as sticky sessions).
•Apart from session affinity, you may employ a dynamic algorithm that considers important factors of your nodes, such as: the response time or the number of connections in each one. For instance with f5, and provided that all your nodes have a homologous or very similar specification or configuration (hardware, network configuration), then you may use the Least response time algorithm.
2. CLUSTER CONFIGURATION
•Follow best practices for a cluster setup, and as issued by your database engine vendor.
Common recommendations such as using an identical server configuration for all nodes in a cluster, or disabling the operating system's automatic upgrades, will apply to Bizagi servers.
•While maintaining an identical server configuration for all nodes, make sure that these use the same service account to access the database engine, the same service account for application start-up (and further access to attachment's file server), and the same configuration to connect to the SMTP service.
For a best reliability on your hardware sizing analysis and the load balancing algorithms, use a dedicated server to host Automation Server.
Network for end users
The network used by end users to access Bizagi is not demanding in terms of bandwidth, though it should implement significant security measures.
The following diagram highlights this part and the aspect which is critical for a secure access to Bizagi:
As pin-pointed above, consider:
1. END USERS TO BIZAGI
•Security access to Bizagi is promoted by setting HTTPS support.
No special or further considerations are required in terms of the network connectivity offered for end users access (Automation Server is optimized and designed to support end users connecting from the internet or working on overall slow networks).
Bandwidth specification is mainly bound to the expected file size of documents attached to your business processes.
•Rely on a robust firewall appliance as well for hardened security measures (e.g, a WAF such as Barracuda).
Other aspects
Regarding integration with your corporate systems, rely on your ESB when applicable (for business continuity support) while ensuring that network connectivity to the ESB or other systems is optimal as well.
An optimal network connectivity should consider adequate bandwidth according to the expected volume of information to be transmitted (i.e, consider the size of documents attached to the process when sending them over to another system, or the total amount of information exchanged when invoking external web services or in B2B integration scenarios in general).