High availability Bizagi configuration

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Automation Server configuration and administration guide > Initial project configuration > Deployment of processes and new versions > Advanced Deployment > Project configuration alternatives >

High availability Bizagi configuration

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:

 

HA_system_architecture

 

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 (e.g, Windows Server 2012 with IIS 8).

A SQL Server database (e.g, 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 (i.e 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 (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 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.

 

note_pin

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.

 

note_pin

In case that you do not wish to use sticky sessions on your load balancer configuration, you would need to store the session state information in a centralized repository, as supported by the .NET framework technology (e.g use a session state database).

More information on a session state configuration at http://help.bizagi.com/bpmsuite/en/index.html?sysadmin_ssdb.htm.

 

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).

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.

 

note_pin

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.

 

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.

Including the following line inside of the <appSettings> element, but only for all of your slave nodes.

<add key="DisableAsynchCaseClosing" 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, and a script to consider the following aspects:

Bizagi Cluster configuration (mandatory):

The database needs a script so that it is cluster-aware, meaning it carries out additional heuristics to synchronize metadata.

Maintenance time frame configuration (optional):

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.

 

 

note_pin

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 (restoring a backup is not an option because you will lose all changes made through scripts to the database such as the ones in the section 3.11).

 

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.

 

4.2 Production parameters verification

After the process deployment, verify that parameters are set accordingly, such as:

Any parameters of external systems integrated in your project (interfaces, APIs, data stores, authentication systems, or the documents repository).

Any custom files  (.js, .css, .dll, etc) need to be in place.

The connection to the SMTP service.

Lists of values for entities which are of the parameter type in Bizagi.

Business configuration regarding formats (e.g for dates and numbers).

 

4.3 Production end users configuration

Recall that the domain\admon is the system user employed by Bizagi (always created by default).

You may not disable this user since it is needed to perform automatic tasks such as timers or scheduled jobs.

However, it is strongly recommended to edit this user's setting so that it is not set with rights to access administration options.

For this, you may exclude this user from the list of authorized users to manage your Bizagi system (i.e this user should not be able to create or edit other users, should not modify parameters in Bizagi such as in entities or cases, etc).

 

Additionally and after process deployment, make sure that your end users are created in Bizagi and that these are active, as supported by your license, before going live.

 

 

 

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.