Overview
The following document lists infrastructure tasks and recommendations for you to setup your Bizagi project in a high availability system architecture.
This document serves as an IT checklist to prepare the infrastructure (for the first time setting up Bizagi), and it will also provide the guided steps to configure your Bizagi project once this infrastructure is ready.
The following image illustrates the system architecture involved in a high availability setup:
Before you start
The procedure presented in this document, applies when there's no connectivity between your authoring server (known in Bizagi as the development environment) and the final operating servers where you want to roll-out the implementation (known in Bizagi as the production environment).
For instance, this procedure is useful to configure a high availability production environment on cloud services (such as Azure), while having the development environment on servers which are not necessarily in the cloud.
Therefore, this procedure relies on the Advanced deployment concept to publish the Bizagi processes into your final environment (as described at Advanced Deployment).
The following architecture characteristics apply as well:
•A .NET platform (For example, Windows Server 2012 with IIS 8).
•A SQL Server database (Like version 2012).
•A Windows shared drive for the documents repository (attachments).
What you need to do
In order to configure Bizagi in a high availability architecture, the following sections will guide the procedure on what you need to review or carry out:
1. Preparing the infrastructure.
This section lists the considerations and recommendations to prepare the underlying infrastructure of your Bizagi project.
2. Installing Bizagi
This section describes the considerations and recommendations when installing Automation Server.
3. Configuring your Bizagi project
This section provides a step-by-step guide to configure your Bizagi project.
4. Going live
This section describes the next steps needed to go live with your set up production environment.
Procedure
Follow the guidelines and steps presented below.
1. Preparing the infrastructure
The following prerequisites consider the relevant hardware and software aspects to setup the database tier, the digital process tier, and a compliant configuration of other systems and applications integrated with Bizagi.
1.1 Database Tier (SQL Server)
The database tier (data access layer) is where the database engine lies.
For high availability, 2 or more nodes are configured in a clustered SQL Server instance to support failover capabilities.
1.1.1 Hardware configuration
Make sure you are complying with minimum hardware requirements or preferably, that this hardware meets an appropriate sizing estimation for your project.
For instance, for Bizagi version 11.2, consider:
•RAM greater than 16 GB.
•2 or more hard disks with more than 80 GB of free space.
•Processor with 4 cores minimum. 3 GHz for processing recommended.
•Using redundant power supply.
•Using more than 1 NIC (1 GB or greater).
Additional recommendations:
•Note that the minimum hardware specifications listed above should be complemented with your specific project's requirements by carrying out a thorough a sizing analysis.
•It is strongly recommended that the database server is dedicated to hosting Bizagi's database exclusively.
•When setting a database cluster, all common recommendations for a clustered setup apply, such as making sure your nodes use: redundant measures for your SAN (if you are using one), best practices for the network connection between your nodes (optimal bandwidth and latency, additional NICs if needed), etc.
Bizagi is intensive in data access, and therefore it is really important that redundancy measures do not take up significant resources used by the database nodes' processing or transportation.
1.1.2 Operating system configuration
Make sure you are using a supported operating system and its configuration in all of the nodes that are part of your database cluster.
Consider:
•A supported operating system version and language (i.e, Windows Server 2012, English language).
The same operating system version and service packs in all nodes.
•Configuring the regional settings accordingly (server date and language).
The same configuration for all nodes.
Additional recommendations:
•All common recommendations for servers set up apply, such as disabling automatic updates for the operating system.
Make sure you consider updates within your patch management policies.
•Considering within your anti-virus policies that database files should not be scanned.
1.1.3. SQL Server installation
Make sure SQL Server is properly installed on all of the nodes that are part of your database cluster.
Consider:
•A supported version of SQL Server is used (For example, when using 2012: version 11.0.5058.0 x64).
The same version in all nodes.
•A supported collation is used by that instance (i.e default and recommended collation is SQL_Latin1_General_CP1_CI_AS).
The same collation in all nodes.
•The version and collation matches the one used in your SQL Server instances of your authoring and testing environments.
•Activating SQL Server authentication mode (mixed) for all nodes.
•Creating at least one SQL Server login account which has master and tempd rights (a Process administrator account having the public server role, rights to create database, backup database and grant view any definition on the master database, rights to create, select and drop table, grant view any definition on the tempdb database).
This account having the same login and password in all nodes.
Additional recommendations:
•You may consider customizing your SQL Server configuration by setting your SQL Server instance in a port different than the default 1433 port, and setting it as a named instance (i.e to accomplish security through obscurity measures).
You should also disable the sa account and use a different sysadmin account instead, and used enforcement of strong passwords.
Consider that all configuration mentioned above (including a port number or named instance) for all nodes of your SQL Server cluster should be homogeneous.
•Note that a Bizagi project uses 1 database at your SQL Server instance, and therefore an active-passive SQL Server cluster setup is commonly used (recommended for most scenarios).
However if your project handles a really large volume of information and you plan on using a replicated database (ODS) for reports and analytics, you may consider an active-active setup (multi-instance failover cluster) instead so that you separate the host of the transactional database from the one providing reports and analytics.
1.2. Digital process Tier (.NET platform)
The digital process tier is where Bizagi Work Portal operates.
In a .NET platform, Microsoft Internet Information Services hosts the Work Portal.
For high availability, 2 or more active nodes are configured in a cluster in order to provide load balancing capabilities.
1.2.1. Hardware configuration
Make sure you are complying with minimum hardware requirements or preferably, that this hardware meets an appropriate sizing estimation for your project.
For Bizagi version 11.2, consider:
•RAM greater than 16 GB.
•2 or more hard disks with more than 80 GB of free space.
•Processor with 4 cores minimum. 3 GHz for processing recommended.
•Using redundant power supply.
•Using more than 1 NIC (1 GB or greater).
Note that the minimum hardware specifications listed above should be complemented with your specific project's requirements by carrying out a thorough a sizing analysis.
1.2.2 Operating system configuration
Make sure you are using a supported operating system and its configuration in all of the nodes that are part of your cluster.
Consider:
•A supported operating system version and language (Like Windows Server 2012, English language).
The same operating system version and service packs in all nodes.
•Configuring the regional settings accordingly (server date and language).
The same configuration for all nodes.
Additional recommendations:
•All common recommendations for servers set up apply, such as disabling automatic updates for the operating system.
Make sure you have latest updates and consider their maintenance within your patch management policies.
1.2.3. IIS installation
Make sure IIS is properly installed on all of the nodes that are part of your cluster.
Consider:
•A supported version of IIS is used (i.e when using a supported operating system, your IIS version is supported). For instance in a Windows Server 2012, IIS 8 is used.
The same version in all nodes.
•Enabling the following server features for your IIS Web server:
IIS 6 Metabase compatibility, IIS Metabase and IIS 6 configuration compatibility, and IIS Management Console (Web Management Tools), .NET Extensibility 4.5 and ASP.NET 4.5 (World Wide Web Services), Static Content (Common HTTP Features), Static Content Compression and Dynamic Content Compression (Performance Features), Basic authentication, Windows authentication and IP and Domain restrictions (Security features).
Additionally, consider enabling the SMTP Server feature as well to use the IIS SMTP service as a bridged connection to your corporate SMTP (recommended).
Additional recommendations:
•Consider having at hand a valid server certificate to configure HTTPS use later on (for enhanced security).
•If you plan to install Automation Server through its installer as described later on, you will not need to consider further prerequisites.
Otherwise and only if you will not run the Automation Server installer, you will need to make sure you install Microsoft's .NET framework version 4.5.2 full.
1.3. Other systems and applications
This section applies for your corporate systems and applications that will be integrated with Bizagi.
This depends on the services your Bizagi project will use specifically.
1.3.1 Domain - Service account
Domain setup does not require any action or special modifications for Bizagi.
You will only need to consider, that using a dedicated service account for Bizagi is recommended according to best practices.
For this, make sure you create a domain account which will be used to start up the Work Portal services (i.e become the identity used by the application pool at the IIS and by the Scheduler service) and that its password does not expire.
1.3.2. File server - Shared folder
When using a shared folder in a file server, as your repository of documents (case attachments), set that the domain account specified above, has rights to read and write to that folder.
Make sure this file server is accessible by all nodes of your Bizagi cluster.
|
In case that you wish to use your corporate ECM system to store documents, make sure that you can access to it by relying on optimal latency and connectivity, usually achieved and recommended through a VPN configuration. |
1.3.3. Load balancer - Sticky sessions
You may use a load balancer that can direct requests between the different nodes of your Bizagi cluster.
It is recommended to use a hardware load balancer such as F5.
Make sure you enable sticky sessions in the routing configuration of your load balancer (regardless of the algorithm used to balance requests).
In the end, you will publish the URL of the load balancer to which your end users access Bizagi. This URL can use an IP or DNS name and a virtual directory which needs to be mapped to route to the nodes and virtual directory of your Bizagi cluster.
1.3.4. SMTP server - relay support
You may use your corporate SMTP server to send out e-mail notifications.
Make sure that your SMTP server supports relay.
It is recommended to rely on the SMTP service of the IIS as an intermediate service between Bizagi and your corporate SMTP server (a bridged connection) in order to make sure relay is supported and to customize configuration parameters to integrate to your corporate SMTP server (such as use of authentication, a different port number other than the default port 25, etc).
More information regarding the use of the SMTP service of the IIS at Using an SMTP server.
1.3.5. Firewall settings - ports
Make sure that authorized ports and access is granted accordingly between your different servers as described below.
•Connectivity from Bizagi servers to the database tier is done through the TCP port specified by your database instance (or listener's configuration).
•Connectivity to the Work Portal from the end user's devices, is done through standard HTTP ports (the default port 80 or 443 when using SSL over HTTPS).
You may modify the default port later on when configuring your Bizagi project.
1.3.6. Others
Depending on the integration requirements of your Bizagi project, you may need to make sure other corporate systems and applications are available and using an adequate network connectivity (e.g, an identity provider system or LDAP, cloud services, integrated APIs, systems or databases).
Make sure you consider as well any additional topics related to accessibility (ports), authorization/security, or licenses of third party components.
Additional recommendations:
•Depending on your SLAs, consider any redundant measures for the availability of such services or systems.
For instance, for the SMTP server and If no redundancy is involved, through relay support notifications will be enqueued.
It is recommended to enhance availability and redundancy of your file server and the contents of its shared folder, since these will store case documents.
2. Installing Bizagi
Installation of Bizagi for a production environment is done by running the installer of Automation Server in all nodes of your cluster.
The latest installer is available for 64-bit platforms directly at http://www.bizagi.com but keep in mind that the version of the Automation Server has to match the version of the Bizagi Studio used in the authoring environment.
Additional recommendations:
•All common recommendations for programs installation best practices apply, such as installing Automation Server at a different partition than the default C:\ drive.
•Verify that the installation of Automation Server creates a local user group called Bizagi and that your user is explicitly included in it.
This user group is used to open Bizagi Management Console to administer your Bizagi System.
Similarly, in order to create and update projects, you will need to have your user explicitly included in the Administrators group.
You may also verify that the Bizagi Management Console is installed.
•At this point make sure that you have purchased a Bizagi license to support your production end users.
Reboot the server if needed (Bizagi installation may prompt about this).
3. Configuring your Bizagi project
Follow these steps to configure the components needed of the underlying infrastructure for your Bizagi project.
Through these steps, the production operating environment is prepared and made ready for processes deployment.
3.1. Define which of your nodes will be your master node
From the set of nodes having Automation Server, one of these will be set as the master node of the cluster, rendering all other nodes as slave nodes.
Make sure you define this master node so that you can identify it at any time.
3.2. Create the production environment project (at the master node)
From the master node, run Bizagi Management Console with administrator rights to create the production environment project.
Name this project exactly how you want your published Bizagi Work Portal to be accessed by end users (though a rename is possible afterwards).
Specify the connection to your database tier (i.e, failover cluster instance or listener) making sure you use the SQL Server process administrator account as created and described in section 1.1.3.
Your created project should result in: A database at your database tier, a scheduler service set as a local Windows service, and a local web site at the IIS.
The local web site (Bizagi Work Portal) is created under the Default web site and is set to use a 64-bit application pool, solely for Bizagi, and which is automatically created in this process (the pool is called Bizagi 64-Bit ASP.NET v4.0).
Once the project has been created, stop the local scheduler service.
Additional recommendations:
•All common recommendations for programs installation best practices apply, such as creating this project at a different partition than the default C:\ drive (in this path, relevant folders and files will be placed).
3.3. Delete the created database
At the database tier, delete that created database in section 3.2.
This database will not be the final one so it is disregarded this way.
3.4. Create the clustered components (at each slave node)
From each of the slave nodes, run Management Console with administrator rights to create the required clustered components for that production environment project.
Name this project exactly how you named the project as performed in section 3.2.
Specify the connection to your database tier (i.e, failover cluster instance or listener) making sure you use the SQL Server process administrator account (this account having the necessary rights, as discussed in section 1.1.3).
Your created project should result in: A database at your database tier, a scheduler service set as a local Windows service, and a local web site at the IIS.
The local web site (Bizagi Work Portal) is created under the Default web site and is left configured to use a 64-bit application pool, solely for Bizagi.
This pool is called Bizagi 64-Bit ASP.NET v4.0.
Once the project has been created in each slave node, stop the local scheduler service.
Make sure you perform the next step 3.5 (deleting the created database) before repeating this step in additional slave nodes.
Additional recommendations:
•All common recommendations for programs installation best practices apply, such as creating this project at a different partition than the default C:\ drive (in this path, relevant folders and files will be placed).
3.5. Delete the created database
At the database tier, delete that created database in section 3.4.
This database will not be the final one so it is disregarded this way.
3.6. Create the production database
From the master node, run the tool called CreateDatabase.exe with administrator rights to create the production environment database (this tool is located in the folder where the Management Console is).
Configure the CreateDatabase.exe.config file to: Use a connection sting that specifies the connection to your database tier (i.e, failover cluster instance or listener) making sure you use the SQL Server process administrator account as created and described in section 1.1.3, to name this database exactly as the name given in steps 3.2 and 3.4.
When creating the database, make sure you tick the checkbox that indicates that this database will be marked as a production database.
This should result in a created final database at your database tier.
|
At this point and when using a failover cluster instance for database high availability, you would set up your SQL cluster aspects so that your nodes synchronize and you can access the database via a listener or virtual node. |
3.7. Carry out best practices for SQL Server storage configuration
According to the hardware characteristics of your database nodes (i.e number of hard disks, number of processors or cores), you may configure the data files and logs for an enhanced performance (by scaling them out).
Best practices oriented to storage configuration for in a SQL Server database include recommended measures such as:
•Considering creating multiple data files and filegroups for Bizagi's database, in order to benefit from parallel I/O operations (according to your hardware characteristics).
•Placing log files on their own volume, separate from data files.
Log files are almost exclusively written to sequentially, and not often read (exceptions to this are synchronization measures involved in database mirroring or AlwaysOn availability groups).
This configuration favors a fast write performance.
•Placing tempdb in its own volume.
Tempdb is used for myriad purposes by SQL Server internally, so having it on its own I/O subsystem helps.
•Similarly, considering storing database backups in their own drives for redundancy purposes, as well as to reduce I/O contention with other volumes.
•Configuring tempdb with multiple data files and filegroups pre-sized equally to avoid auto-growth (using one data file per CPU).
Additional recommendations:
•When pre-sizing, consider common recommendations such as: Disabling auto-growth for data files, having the data and log files use no more than 90% of the available disk space, having the log file twice the size of a single data file, and setting auto-growth for the log file to a specific size.
•At this point you may verify that Bizagi database has snapshot isolation enabled. Specifically:
Allow Snapshot isolation: True (ALLOW_SNAPSHOT_ISOLATION ON)
Is Read-committed snapshot isolation on: True (READ_COMMITTED_SNAPSHOT ON)
Note that when using the above snapshot isolation levels, it becomes even more important that you boost the resources and enforce best practices for, the tempdb database (i.e, using a separate volume that guarantee high speed I/O operations).
The above recommendations does not imply that such tasks would not need to be constantly monitored or tuned.
If applies to your database cluster, at this point you may also consider configuring your Availability group synchronization, since no more backup restores will be done in this procedure.
3.8. Create a dedicated SQL Server account for Bizagi operations
Create a SQL Server account to be used solely by Bizagi.
This account will be used both by the scheduler service and the local web site (Bizagi Work Portal) and will have only the strictly necessary rights at your SQL Server instance and at the specific database created in the section 3.2.
Necessary rights are the public server role, and the following user mappings for Bizagi database: db_datareader, db_datawriter, public, rlBA_SQL_BizAgiWebApp, and rlBA_SQL_ExecuteBizAgiSPs.
Additional recommendations:
•All common recommendations for this account apply, such as making sure it has a strong password but it doesn't expire.
You may initially set the same password for this account as the one used for the process administrator account created and described in section 1.1.3.
This way, you won't have to modify right away the password of the connection string, but do it later on.
•Recall that if you are using some sort of mirroring or database synchronization for failover or disaster recovery measures (e.g an AlwaysOn availability group), you will need to make sure that such SQL Server account is created consistently across the multiple instances of your redundant nodes.
3.9. Edit the Work Portal settings
From each of the nodes, go into the IIS manager to edit the settings used by the Work Portal's web site.
At this point, you should consider:
•Installing and creating the HTTPS binding that considers your server certificate, as recommended in section 1.2.3 (considering your load balancer server name as well). Consider the port you will use for HTTPS in further configuration (load balancer, firewall, etc).
•Separating the SOA web services physical folder apart from Cache.asmx, WFEQuery.asmx and WFAsync.asmx so that you can include additional security measures such as basic authentication for these resources.
In case that your project does not need to publish Bizagi's API, you may leave such SOA web services completely restricted.
•Including any additional security definitions according to how you expect access to the Work Portal, such as defining an IP whitelist.
•Using the dedicated domain service account as the identity set to start up the application pool used by Bizagi (will require that this account is granted the log-on as a service right).
For this account, verify proper rights for that dedicated service account to the physical path of the web site files and folders.
From each of the nodes, make sure you edit the Work Portal configuration file which is the web.config file located at the physical path of the IIS web site's folder.
When editing this file consider:
•Editing the connection string, so that it uses the dedicated SQL Server account as created in section 3.8.
Keep the same password if it applies (temporarily), as recommended in that same section.
You may use the same password for an initial connection setup and later on, change the password by specifying an encrypted one that relies on the encrypting option available at the administration menu of Bizagi Work Portal.
•Including the following lines inside of the <appSettings> element, for all of your nodes (master and slave nodes).
Consider setting the Protocol=HTTPS when using SSL over HTTPS instead of HTTP, as recommended in section 1.2.3.
<add key="SERVER_NAME" value="YOUR_VALUE_HERE"/>
<add key="APP_NAME" value="YOUR_VALUE_HERE"/>
<add key="PROTOCOL" value="HTTPS"/>
Note that for Server_name value, you should specify the load balancer's virtual name. For the App_name value you should specify the load balancer's virtual web site. This keys are needed for links in email notifications (e.g. Case link) a redirected to the right server.
Forcing the TLS version
If you are using HTTPS with the TLS protocol, and you have to use a specific version, for example, version 1.1 or 1.2. You need to add the following key:
<add key="TLSSupport" value="Tls1.2" />
Consider reviewing if the end-user browser has the TLS enabled. These browsers versions enable the TLS 1.1 version by default:
Browser |
Version where TLS 1.1 is enabled by default |
|---|---|
Internet Explorer |
11 |
Microsoft Edge |
All versions |
Google Chrome |
22 |
Mozilla |
27 |
To review if TLS is enabled in your browser, follow these steps:
Microsoft Internet Explorer
1.Open Internet Explorer
2.From the menu bar, click Tools > Internet Options > Advanced tab
3.Scroll down to Security category, manually check the option box for Use TLS 1.1 and Use TLS 1.2
Google Chrome
4.Connections are automatically negotiated at the highest grade.
5.If you are using Google Chrome version 22 or greater, TLS 1.1 is automatically supported. TLS 1.1 & 1.2 are automatically enabled from version 29 onwards.
Mozilla Firefox
1.Open Firefox
2.In the address bar, type about:config and press Enter
3.In the Search field, enter tls. Find and double-click the entry for security.tls.version.max
4.Set the integer value to 4 to force a maximum protocol of TLS 1.3.
For further information consult. HTTPS protocol.
3.10. Edit scheduler settings
From each of the nodes, make sure you edit the scheduler's configuration file which is the BizAgi.Scheduler.Services.exe.config file located at the Scheduler folder of the physical path where you created the Bizagi project.
When editing this file consider:
•Using the dedicated domain service account as the identity set to start up the Scheduler by editing the service's properties (will require that this account is granted the log-on as a service right).
For this account, verify proper rights for that dedicated service account to the physical path of the web site files and folders.
•You may also choose to set dependencies or further retry actions.
•Editing the connection string, so that it uses the dedicated SQL Server account as created in section 3.8.
Keep the same password if it applies (temporarily), as recommended in that same section.
You may use the same password for an initial connection setup and later on, change the password by specifying an encrypted one that relies on the encrypting option available at the administration menu of Bizagi Work Portal.
•Including the following lines inside of the <appSettings> element, for all of your nodes (master and slave nodes).
Consider setting the Protocol=HTTPS when using SSL over HTTPS instead of HTTP, as recommended in section 1.2.3.
<add key="SERVER_NAME" value="YOUR_VALUE_HERE"/>
<add key="APP_NAME" value="YOUR_VALUE_HERE"/>
<add key="PROTOCOL" value="HTTPS"/>
Note that for Server_name's value, you should specify the load balancer's virtual name. For the App_name's value you should specify the load balancer's virtual web site.
•Include the following lines inside of the <appSettings> element, but only in all of your slave nodes.
<add key="DisableAsynchCaseClosing" value="1"/>
<add key="DisableInterfaceErrorLogger" value="1"/>
This way, only the master node will be performing system maintenance tasks.
3.11. Apply your license
Apply your Automation Server license.
Contact our support team in order to assist when applying the license.
By default, the scheduler service will run system maintenance tasks everyday starting from the 23:00 hours to 24:00 hours (server time).
System maintenance tasks namely involve moving information of closed cases and activities from one table to another (tuning).
Maintenance will stop at a time close to that end time, regardless if moving some records is still required (these will be left pending for the next execution).
To change or broaden this maintenance time frame, please notify our support team.
Note that you should change the time frame considering that it does not affect your System's operation (to be set at non-busy hours), and preferably according to your project's sizing regarding an estimation of the amount of cases and activities closed per day.
3.12. Start/restart your services
From each of the nodes, make sure you start each IIS service (a restart is useful to make sure you flush any previous cache).
Similarly and from each of the nodes, make sure you start or restart each scheduler service.
If you want to change the password for the dedicated SQL Server account as created in section 3.8, you may do so and make sure you update the configuration files to use such password as done in the 3.9 and 3.10 sections.
|
At this point, the underlying platform for Automation Server runtime has been set up. Though this environment will not have yet those published processes, at this point, IT aspects such as those related to security settings and access, or overall operations of Bizagi services can be verified. This way, the runtime environment awaits for a process deployment before going live. |
4. Going live
At this point, infrastructure is set up for your High availability Bizagi system (your Bizagi project is configured and mainly awaits process deployment).
4.1 Process deployment
Note that there are 2 alternatives for process deployment: The one-click deployment or the Advanced deployment tool.
Recall that the whole procedure presented above, and the following guidelines in this document are based on the use of the Advanced deployment (the one-click deployment is not used at any point).
This way, you will need to execute the Advanced Deployment tool to end up applying scripts to the production database created in section 3.6.
For further documentation about Advanced deployment click here.
Pros of using the Advanced deployment are:
•It does not involve a backup restore which can take longer and lead to a more confusing procedure.
•As a complete setup procedure, it has fewer considerations making it take less time. It allows you to leave the infrastructure ready for your production environment (e.g, after the deployment you do not need to apply any additional scripts to configure your license or cluster, nor to use the Management Console for preparations).
Cons of using the Advanced deployment are:
•The development environment will not be deployment-aware, meaning that it will not acknowledge the existence of a production environment and hence it will not perform validations on delete or modify commands.
This means that Bizagi Studio users need to be extra careful not to delete in the development environment, any object (nor modify its key definitions) that have been already deployed to production, as this may result in data integrity issues.
At this point, you may proceed to use the deployment tool in Bizagi to publish processes into your production environment database.
Note that in this specific scenario, you don't need to create the blank database for the production environment, because it has already been set.
|
We recommend read carefully the preconditions and requirements for deployment, documented in here. |
Future steps - version upgrade important notes
Acknowledge the following notes for a Bizagi minor version upgrade in the future.
Note that upgrading to a major version is not considered below as this subject would need previous assessment from Bizagi Ltd.
These notes should be relevant for you to plan your next Bizagi version upgrade.
General procedure recommendations
All common recommendations for a system upgrade apply, such as:
•Coordinating, reviewing and communicating the upgrade plan.
•Scheduling the upgrade to be carried out at non-working hours.
•Assessing risks and taking backups of all components of Bizagi.
•Making sure that the version upgrade has been properly tested and certified in your development and testing environments (considering also if you need a staging environment depending on the nature of your processes and existing cases). Verifying the upgrade as well in production.
Customizations and overrides
Identify if your project has any given customization files or overrides definitions.
This way, apart from backing these added files (.js, .css, .dll, etc) before an upgrade, make sure you re-apply such changes after a version upgrade has run its changes and replacements.
This applies too with the step carried out in section 3.9, where the Cache.asmx, WFEQuery.asmx and WFAsync.asmx web services are left separated from the business-oriented web services.
After an upgrade you will need to review or re-apply configuration changes after automatic changes and replacements.
Upgrading all nodes
Recall that all the nodes of your cluster use their own set of Bizagi components (scheduler and local web site).
When upgrading the project, make sure you acknowledge this procedure needs to be done through the Management Console in each node.
After upgrading each node, edit or verify the SQL Server account (login, password) used in the connection string used both by the scheduler and the Work Portal, so that it is set as described in sections 3.9 and 3.10.
You will need to also re-apply changes in the configuration of the scheduler as a service: the log on identity of the scheduler service (reconfigure it to start up by using the domain service account), and further dependencies or retry actions.