Overview
Each Bizagi project needs an installed service called the Scheduler on its Automation Server.
The Scheduler is a Bizagi agent which is in charge of performing system maintenance, offline and asynchronous tasks, and other jobs that run in the background and can be scheduled (set to run periodically).
When running your processes in a .NET platform, the Scheduler runs as a Windows service with its name referring to the specific project's name.
The Scheduler is supported in cluster configuration, to support load balancing of background tasks.
The following image illustrates a high availability Bizagi system architecture, involving a redundant Scheduler service:
However, for projects strongly relying on background processing, you can install and use more than one Scheduler service, whether by installing them on separate servers (cluster nodes), by installing them on the same server, or in a combination of these options:
|
When setting up multiple Scheduler instances, even if you have more than one service per node, we recommend that you set these up as independently as possible (each using its own dedicated server and resources). This helps avoid single points of failure (a failure in one node, it does not affect more than one Scheduler instance). For example, you may have separate servers running Scheduler services (if helpful for your project), independently of the Work Portal of Bizagi. |
Why configure multiple Scheduler services?
By default each Bizagi project operates with one instance of the Scheduler service.
However, you can configure the use of multiple Scheduler services to work on a batch of background tasks in parallel.
This allows you to achieve either, or both of these advantages:
Configuration of a high availability system architecture.
In this setup you would have a Bizagi cluster for load-balancing capabilities, each node having Automation Server operational with its 2 main components: Bizagi Work Portal (web application) and the Scheduler.
This way, your system architecture avoids single points of failure (should one node fail, the other continues operating avoiding service disruption).
For more information about setting up a Bizagi cluster refer to Clusters and server management.
Scalability of the Scheduler.
In some scenarios and depending on the specifics of the project's implementation, using more than one Scheduler service which processes the background tasks helps make sure that background tasks are not spending too much time in the queue.
According to your specific analysis of the number of tasks that the Scheduler needs to process at one time(i.e sizing), and their expected SLAs, you could install and configure more than one Scheduler within the same server, without the need to do the same for the Work Portal (scaling out only the Scheduler).
Before you start
The steps described below, part from your project has already been set up (Automation Server properly configured, whether in a cluster or in a single-server system architecture).
Note that though the multiple Scheduler services will distribute the load of background tasks between them:
Only one Scheduler performs system maintenance
System maintenance carried out by the Scheduler involves moving information from transactional tables in the database and should be carried out during non-working or off-peak hours.
When the system has multiple Schedulers, define which Scheduler will be in charge of performing system maintenance so that you can configure it as a "master" Scheduler.
Each Scheduler takes a batch of ten tasks
When a Scheduler service is ready to process tasks (according to the Scheduler interval definition, set as described in Bizagi parameters configuration), it will lock a batch of ten tasks even though it will work on one at a time, and it is uncertain how much time will it take to process the first one or the complete batch.
Each batch of ten tasks, and background tasks processed by the Scheduler in general, follow a FIFO priority algorithm (a First in, First out queue).
This implies that if the number of incoming tasks to process at a given moment (in a very short period of time), does not exceed ten, then it is likely that additional Scheduler service will not balance the load between them.
What you need to do
To configure multiple Scheduler services, carry out these steps:
1. Install your additional Scheduler services
Do this either through the Management Console clustering options or through manual installation.
There are special naming considerations to take into account when installing multiple Scheduler services on a single server.
2. Copy the "Tools" folder when using multiple servers
Each scheduler uses some libraries of this folder, to execute some tasks. Therefore, you need to copy and paste this folder into each node.
3. Configure additional Scheduler services
Only one Scheduler is designated to perform system maintenance.
Additional configuration oriented to the number of threads run by each Scheduler is optional to optimize parallelism.
Procedure
Follow the steps below.
1. Install your additional Scheduler services
Create additional Scheduler services through the Management Console clustering options when creating a first Scheduler service in a given server.
To view more information about setting up a Bizagi cluster that already includes an additional Scheduler, refer to Clusters and server management.
If you are installing multiple Scheduler services in a same server, carry out the following:
1.1 Create a copy (clone) of the Scheduler folder.
Copy, paste and rename the folder located by default at C:\Bizagi\Projects\[your_project]\Scheduler\.
Do this for each additional Scheduler service you require in that server.
In this example, we want to have three services on the server:
1.2 Edit the .bat files inside of the new Scheduler folders.
As a best practice, edit all .bat files to render them ready when needed.
Edit install.bat, installx64.bat, uninstall.bat and uninstallx64.bat by changing the name of the Scheduler service so that it is unique within that same server:
In this example we are using the same root name, with a numbering suffix.
For service number three, we have:
Save your changes when done.
1.3 Run the installx64.bat (or install.bat if applies) file to install each new Scheduler service.
Click the installation .bat file for your server's architecture to install the service.
Do this for each additional Scheduler service you want to install.
Do this with administrator rights and confirm that you get a successful execution:
In the end, you should see your additional Scheduler services installed and listed among your Windows services:
Do not start the multiple services at this point, as you need to edit their configurations first.
2. Copy the Tools folder if you are using a different server
The Scheduler uses libraries located in other folders of the project. You need to copy these libraries in each new node of the Scheduler that is located in a different server. If you have a cluster, you must do that in every server where a Scheduler has been installed.
To do so, go to the main server, and locate the project folder, usually located at:
C:\BIZAGI\PROJECTS\[your_project]
Select the Tools folder and copy it.
Go to the project folder of the second server, and paste the Tools folder.
3. Configure the additional Scheduler services
Define which Scheduler services will perform maintenance tasks.
Review all of your Scheduler services within the solution (only one among all nodes you may have in a cluster, including multiple services you may have in each node).
You can call that one the "master" Scheduler, it does not not require further configuration.
For all other Scheduler services, edit their .config file located by default at C:\BIZAGI\PROJECTS\[your_project]\SchedulerN3\BizAgi.Scheduler.Services.exe.config, to include the following key in the <appSettings> element:
<add key="DisableAsynchCaseClosing" value="1"/>
|
When configuring more than one Scheduler service in the same node, you must change the location of the temporary folder used by each Scheduler instance (this avoids issues that may arise when multiple services try to access the same files simultaneously). To specify a different temporary folder for reach Scheduler instance, edit the Project key by ensuring you use non-repeated, different values in each configuration file. For example, for two instances in a single node: <add key="Project" value="Scheduler1" /> and <add key="Project" value="Scheduler2" />. |
At this point you can save your changes and then start up each Scheduler service (an error-free start-up validates that all of them will work together):
Considerations when using Asynchronous Activities
As an additional configuration, you may tune the Schedulers processing parameters by including the following key in their .config file (in the <appSettings> element) to configure the number of threads each Scheduler service will use:
<add key="MaxThreadsForAsynchWorkitems" value="[number_of_threads]"/>
This key is especially useful when your project may handle a large number of asynchronous tasks executions, incoming in large blocks.
|
When modifying the number of threads used by a Scheduler service (by default it uses one), consider an appropriate balance between the number of Scheduler services you will be using and the number of threads each one runs in parallel.
Modifying this value should be properly analyzed and tested, according to your project's estimated number of background tasks, the characteristics and estimated processing involved in each of these tasks, and, most importantly, according to the characteristics of the underlying hardware (i.e number of cores and processors in your servers). We recommend that you monitor this value and tune it as needed while carrying out proper acceptance tests for this scenario to use the most accurate distribution. |
When you use multiple Scheduler services to process multiple Asynchronous Activities, we recommend that you include the following key:
<add key="DisableInterfaceErrorLogger" value="1"/>
This key optimizes performance since it skips logging to the .csv file for thresholds and timeouts, and it avoids potential issues when having multiple services writing into the same file.
Numbering the Schedulers
If you are using multiple Schedulers, you must number each node, so Bizagi can realize the number of servers and Schedulers for your whole environment. For that Bizagi uses some keys that must be configured within the config file of each Scheduler, usually located at:
C:\BIZAGI\PROJECTS\[your_project]\[SchedulerName]\BizAgi.Scheduler.Services.exe.config
Then include the following keys:
<add key = "SchedulerClusterID" value = "1" />
<add key = "SchedulerClusterSize" value = "1" />
Where:
SchedulerClusterID: It is a numbering identifier, that helps Bizagi to identify each Scheduler individually. This is a consecutive number, starting from 1, and cannot be greater than the cluster size.
SchedulerClusterSize: Number of total Schedulers configured per environment.
The values of these keys depend on the number of each Scheduler. So for example, if you have two Schedulers, the configuration for each Scheduler is:
Node 1
<add key = "SchedulerClusterID" value = "1" />
<add key = "SchedulerClusterSize" value = "2" />
Node 2
<add key = "SchedulerClusterID" value = "2" />
<add key = "SchedulerClusterSize" value = "2" />
Define the Scheduler project folder
When projects are on-premises, each project has a folder located in the main Bizagi server. When you create multiple schedulers, it is important to define the project folder for the new Scheduler. To do so, the key "IsLocally" must be active, include this key with the following format:
<add key=" IsLocally " value="true" />
If you need to define a path different than the default value, you must add the [“WorkingPath”] key, this key omits the value of the [“Project”] key, therefore, the path must include the name where the directories of the new scheduler instance are created.
Example: <add key = "WorkingPath" value = "C: \ Bizagi \ Projects \ [New Instance name]" />
Important notes
Acknowledge that when having multiple Scheduler services, all of these services should be stopped before performing a process deployment.
Similarly, with this setup, consider your multiple Scheduler services when upgrading your Bizagi version.