Bizagi Digital Business

Platform
User Guide

Copyright © 2020 Bizagi

Table of contents

Automation Server configuration and

6
administration guide
System prerequisites 7
Database server prerequisites 12
SQL Server prerequisites 12
Oracle prerequisites 23
Bizagi server prerequisites 28
Enabling IIS and its features 28
IIS version 10 (Win 2016 and 2019) 29

IIS version 8.5 (Win 2012 R2) 39

IIS version 7.5 (Win 2008 R2) 48

Installing the Oracle's connectivity client 54

Other assets and prerequisites 57
Installation 57
Downloading the installer 57
Verifying the installer 60
Running the installer 71
Initial project configuration 78
Deployment of processes and new versions 79
Previous considerations and requirements 80
Deployed Objects 86

Relate Objects 95

One-click Deployment 102

Test environment deployment 106

Using Release Candidate for a deployment to Test 126

Production environment deployment 129

Setting up a Bizagi cluster 148

Advanced Deployment 165

Copyright © 2020 Bizagi

Advanced Deployment executables 168

Package Visualizer 192

Data Synchronization 202

Microdeployment 219

Advanced Deployment example 228

Command line for Advanced Deployment 244

Command line deployment example 252

Other utility commands 271

Project configuration alternatives 277

High availability setup procedure 277

Manual setup procedure without installers 289

Best practices in the production environment 304

Setting up a Bizagi ODS 306
Configuring ODS for Process Analytics 308

Configuring ODS to run queries 311

Configuring the SMTP service through IIS 313

Scaling out the Scheduler service 325
Setting up a load balancer 334
Example setting up an f5 334

Security hardening at the IIS 339

Basic hardening 339

Intermediate hardening 345

Advanced hardening 352

Infrastructure alternatives 358

Setting Bizagi in an Azure VM 359
Setting Bizagi for secure internet access 369
System maintenance and monitoring 376
Backups 378
Database backups 379
SQL Server Backup and Restore 379

Oracle Export and Import 394

Work portal and Scheduler backups 404

Attachments backups 405

Copyright © 2020 Bizagi

Monitoring 406

Infrastructure and platform monitoring 407

Services monitoring 410
Bizagi Diagnostics 414
Setting up Bizagi Diagnostics 415

Advanced options when recording server events 424

Using Bizagi Diagnostics 425

General pointers and tuning tips 436

Database maintenance 439

Profiler recommendations 447
Environment settings and administration 448
Asynchronous Activities Console 449
Management Console 452
Recreate environment (from database) 457

Bizagi parameters configuration 461

Security administration 467

Scheduled jobs administration 478

How to fine tune the Bizagi Scheduler in Cluster Environments 484

Scheduler 2.0 488

Managing external systems 492

Managing integrated Connectors 493

Managing integrated SAP systems 496

Managing integrated Excel connector 497

Managing integrated Web services 499

Managing integrated data sources 504

Diagnosing errors in integrated systems 509

Diagnosing Web services errors 517

Diagnosing Connectors errors 522

Diagnosing SAP errors 528

Bizagi versions (software upgrades) 530

Upgrading the minor version 532
Uninstall 541
Continuous improvement and incremental deployments 544

Copyright © 2020 Bizagi

Guidelines for a new version of a process 549
Running Bizagi with Docker for Test Environments 554

Copyright © 2020 Bizagi

Part I
Automation Server configuration
and administration guide

Copyright © 2020 Bizagi

Automation Server configuration and
administration guide
Overview
Automation Server is the runtime platform where your designed business processes and applications operate and
are made available to your corporate end users.
Automation Server (formerly known as Bizagi Engine), executes your processes and delivers the result to the
desktops and mobiles of every business user.

In this section, you will get to know procedures, guidelines, recommended practices, and general information that
will be useful for you as an IT admin, to plan and execute these types of tasks:
· Setting up Automation Server in a production environment.
· Configuring other components of your corporate system architecture, to work with Automation Server.
· Deploying processes and new versions (business-driven improvements).
· Carrying out administration and maintenance tasks (operations).
· Monitoring your Automation Server.

System prerequisites
Overview
Automation Server operates within a corporate system architecture which includes software and assets which are
not provided by Bizagi Ltd.
Such software and assets are covered in this section as system prerequisites.

System architecture
A Bizagi system requirea the following components apart from Automation Server:

1. A process repository.
A RDBMS in which your Bizagi project stores the process models and related business data.
The process repository is a database which Bizagi creates, and which resides in a pre-configured instance of a
database engine (a database server).
The database can be set in a database cluster to support fault tolerance (or to support scalability if using
technologies supporting active-active schemes, such as Oracle RAC).

Page 7 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. A Bizagi cluster.
A server having a .NET platform (having an IIS), on which Automation Server is installed.
For high availability and scalability, you can set up a Bizagi cluster with multiple nodes having Automation Server, set
behind a load balancer.
Automation Server has two main components supporting the runtime of your processes:
· Work portal: A web-based portal where end users log in and work on processes.
Bizagi Work portal is set as a web application in a web server (IIS).
· Scheduler: An agent run by Bizagi as a Windows service. It runs system maintenance and offline and
asynchronous tasks. You can schedule the tasks to run in batches.

3. Additional assets.
A corporate system architecture, may include these other assets:
· A load balancer, to support high availability of the solution (as a scalability measure for the Bizagi cluster).
· An HTTP server, to support reverse proxy capabilities (for internet access to Bizagi).
· A database replica, set to be an ODS (Operational Data Store), to enhance availability of data for reports or daily
transactions.
· A file server or an ECM system to store files and documents.
· Any other corporate systems or servers integrated with the Bizagi processes, such as: An LDAP server or Identity
provider system to enable integrated authentication, an SMTP server for notifications, a SAP system, an ESB
providing integration services, servers publishing web services, or separate databases.

Page 8 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Page 9 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Required profiles
To run system administration tasks, the following profiles are usually involved and recommended:

1. A database administrator (DBA).

Should have specific expertise in the database engine (SQL Server or Oracle) that you are using.

2. A platform administrator.
Should have specific expertise regarding the web server you are using, as well as expertise about the operating
system on which it runs.
Similarly, this profile should be able to handle, redirect or escalate subjects related to any additional infrastructure
or systems involved, such as the load balancer's configuration, a proxy server, DNS configuration, etc.

3. A business administrator.
Should know about the implemented processes and all parameters and variables affecting the Bizagi operating
environment.
Should lead the deployment plan of processes as well as their upgrades into new versions and, have full rights in
Bizagi for the administration options.
This role can be taken by a leading business analyst or architect.

Page 10 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Page 11 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Database server prerequisites

Overview
A Bizagi project stores the processes models and related business data in a database (created with Bizagi's meta
model), as described at System prerequisites.
To create the database, you need to have installed and configured a database instance on your database server.

Further information
For more information about database prerequisites and configuration refer to these topics:
· When using SQL Server, refer to SQL Server prerequisites and configuration.
· When using Oracle, refer to Oracle prerequisites and configuration.

SQL Server prerequisites

Overview
Automation Serveruses a database server to store your processes and their related data.
Microsoft SQL Server is supported for database server configuration.
You need to install and set up a SQL Server instance, ensuring you comply with the information below.

Supported versions and editions

The following are supported:

VERSION VERSION NUMBER

SQL Server 2017 14.0.3048

SQL Server 2016, service pack 2 13.0.5026 or above

SQL Server 2016, service pack 1 13.0.4001 or above

SQL Server 2014 12.0.2000 or above

SQL Server 2012 11.0.2100 or above

SQL Server 2008 R2, service pack 2 10.50.4000 or above

SQL Server 2008, service pack 3 10.00.5500 or above

For Automation Server, supported editions are Standard or higher.

SQL Azure is not supported.

The database instance must be set up with a collation which:

· Is case-insensitive (CI).
· Is not a Turkish collation

Required configuration
Configuring a SQL Server instance to work with Bizagi, requires the following:

· SQL Server in mixed mode authentication

Page 12 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Make sure that SQL Server authentication mode is enabled for your database instance (in mixed mode), at least
initially to create a Bizagi project. You may later choose to authenticate users based on Windows authentication.

· TCP/IP protocol enabled

Make sure the TCP/IP protocol is enabled for your instance, and check for recommended settings such as
establishing an explicit TCP/IP port (instead of using dynamic ports) and allowing remote connections when
needed.

· Authorized login accounts

You need one authorized login account using SQL Server authentication and having the required rights for
processes execution (for Bizagi's database).
A separate login account having sysadmin rights is required for administration tasks.

Verifying SQL Server prerequisites

Carry out these steps, to make sure that your SQL Server instance is set to work with Bizagi.

Before you start

To verify the configuration of your SQL Server instance (or to set it up), you need these SQL Server client and
configuration tools.
SQL Server Management Studio and SQL Server Configuration Manager.
Both tools can be included when installing the SQL Server database. If your SQL Server version does not include the
SQL Server Management Studio, you may download and install it directly from Microsoft's official web site at no
cost.

Which version do I have?

To determine the version of an installed SQL Server, use the SQL Server Management Console.
Run the following command while connected to your database instance:
Select @@version

This shows you information about your instance:

· The product's official name and service pack
· The exact version number and its date
· Additional details about the SQL Server edition and bit support.

Required configuration

Page 13 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Check or configure the following requirements.

1. SQL Server in mixed mode authentication

Run the SQL Server Management Studio.
Right-click to select its properties:

In the Security option, make sure that the SQL Server and Windows Authentication Mode is checked and then click
OK.

Page 14 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. TCP/IP protocol enabled
Run the SQL Server Configuration Manager.

Page 15 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Enable the TCP/IP protocol for your database connection by locating the specific database instance (under the SQL
Server Network Configuration).
Right-click on this protocol and select Enable:

We recommended that the TCP port be explicitly defined (by default as 1433), so that dynamic ports are not used
by the instance:

You may want to make sure that the SQL Server Browser service is in Running mode as well:

Page 16 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Changing these settings may require restarting your database service.
The TCP/IP port configuration requires that there is no firewall rule or corporate security software blocking the
port used for your database connection.

For remote connections, configure the Allow remote connections property.

This property can be reviewed or activated through the SQL Server Management Studio, and in the database
instance's properties.
Under the Connections option, make sure that this property is selected:

Page 17 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
3. Authorized login accounts
While using the SQL Server Management Studio, make sure you can rely on an account that has sysadmin rights
(e.g., with the sa default role).
With this account, you can create the Bizagi database.

We recommend having two types of users:

· Sysadmin user for the Management Console.
· Public user for Work Portal and the Scheduler.

Sysadmin account for the Management Console

You can configure a different account to administer for the Bizagi database.

Page 18 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Public user for Work Portal and Scheduler
Make sure you create or verify that the login account you will use for Bizagi Engine meets the following conditions:

· The login account uses SQL Server authentication mode:

Page 19 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· The server roles specified for this login must include: public.

Page 20 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· The login must include the following user mapping items for that specific database: db_datareader, db_datawriter,
public, rlBA_SQL_BizagiWebApp and rlBA_SQL_ExecuteBizagiSPs.

Page 21 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 The db_datareader, db_datawriter, public, rlBA_SQL_BizagiWebApp and rlBA_SQL_ExecuteBizagiSPs user
mappings apply for your project's database. This means that you need to apply these mappings once your Bizagi
production environment database has been created.

Recall that in order to create that Bizagi database, you need to have previously used a sysadmin account.

· Check that the login is enabled and not locked out:

Page 22 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You may modify or review that this SQL Server account login, is used in the connection string of the Work Portal and
the Scheduler connections, by editing their corresponding configuration files.

· The connection for the Work portal is modified, by editing the web.config located at the Web application
folder of the given project environment (by default at C:\Bizagi\Projects\[PROJECT_NAME]\WebApplication).
· The connection for the Scheduler service is modified, by editing, the Bizagi.Scheduler.Services.exe.config file
located at the Scheduler folder of the given project environment (by default at C:
\Bizagi\Projects\[PROJECT_NAME]\Scheduler).
· This connection is specified in both of the above into the following key:
<add key="DSNDB" value="Current Language=us_english;Initial
Catalog=[MY_PROJECT_DATABASE];Data Source=[MY_SQL_SERVER_INSTANCE];User
ID=[MY_NEW_LOGIN];Password=[MY_LOGIN_PASSWORD];" />

Oracle prerequisites

Overview
Automation Server requires a database server for your processes repository.
Oracle database is supported for the database server configuration.

Page 23 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You need to install and set up an Oracle instance, ensuring you comply with the information below.

Supported versions and editions

The following are supported:

VERSION

Oracle 12c

Oracle 11g R2

Supported for Standard and Enterprise editions.

Express (XE) edition is not supported.

Supported character sets for Oracle databases are both Unicode and non-Unicode. However,
· Migrating Oracle databases to Unicode (from non-unicode character sets) is not supported.
· For Unicode Oracle databases,
· String attributes will hold a maximum of 1000 characters.
· If you need more than 1000 characters, extended text attributes should be used.

Prerequisites and recommendations

When configuring your Oracle database:

1. If you are using archiving (enabling the Archive mode), we recommend you use two destinations for your
archivelog.

2. We recommend using Automatic Shared Memory Management (ASMM configuration).

You need to assign a minimum of:
· 4 Giga bytes for SGA memory.
· 3 Giga bytes for PGA memory.

Page 24 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
3. We recommend assigning a block size of at least 8000 bytes, and specifying a maximum of 300 processes.

4. We recommend using 4 redo logs groups, each one of them assigned to use 3 Giga bytes.

Note that the above recommendations are strictly the minimum prerequisites for your Oracle 11g instance.

Page 25 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Further sizing considerations will depend on your project's characteristics, and a detailed analysis to determine
scalability and additional demands, is recommended.

When using an Oracle cluster (i.e, RAC), consider the usual recommendations as issued by Oracle, such as using a
high speed network connection for Heartbeat purposes.

Verifying Oracle requisites

Carry out the next steps, to make sure that your Oracle instance is set to work with Bizagi.

Which version do I have?

To determine your version of an installed Oracle instance, connect to your database instance and run:
select * from v$version;

This query should display a supported Oracle version.

Required Bizagi user configuration

Once you are certain you have installed your Oracle instance while meeting the prerequisites, create a specific
admin user for Bizagi (to initially create the database, to upgrade Bizagi's version and perform other tasks).
This user is called BizagiAdmon.
You need to create this user for Bizagi, in your Oracle instance by running a script.

Procedure
To create the user by running a SQL script, follow these instructions:

1. Connect to your Oracle instance as the sys user (sysdba)

2. Edit the ConfigureInstanceForBizAgi-[Oracle_Version].sql. script

Locate the Bizagi installation path and browse into the Project model's database folder (by default at C:\Program
Files\BizAgi\BizAgi Enterprise\ProjectModel\Database\).
For Oracle 11g R2, edit the script called ConfigureInstanceForBizAgi-11g.sql.

The script has a .basql file extension.

In other to retrieve the actual script, rename this file extension to .zip and then extract its contents.

To edit the script, remove the comment lines that mark the following variables, and edit their values:

Page 26 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· BA_TABLES_DATAFILES_DIR: Replace with the path to where you want to create the tablespaces datafiles.
· BA_LOBS_DATAFILES_DIR: Replace with the path to where you want to create the datafiles holding Bizagi LOBS.
· BA_INDEXES_DATAFILES_DIR: Replace with the path where you want to create the indexes datafiles.
· BA_BACKUP_PATH: Replace with the path to where you want to store automatic backups.
· BA_BIZAGIADMON_PASSWORD: Replace with the password for the BizagiAdmon user.

3. Run the script.

Run the edited script and make sure the operation completes successfully.

This script is subject to change in each Bizagi version.

Use the script that corresponds exactly to your installed version of Bizagi.

4. Configure the optimizer.

The following is applicable to Oracle version 12 and is a recommended guideline due to Oracle's report on BUG
21615091 (https://support.oracle.com/rs?type=bug&id=21615091).
Connect with a user with DBA rights (e.g, DBA, SYSTEM) and run the following script to configure the optimizer:
ALTER SYSTEM SET "_optimizer_reduce_groupby_key" = FALSE;

Page 27 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Bizagi server prerequisites

Overview
A Bizagi project running on a .NET platform relies on an IIS web server (Microsoft's Internet Information Services), as
described at System prerequisites.
For high availability and scalability, you may set up a Bizagi cluster with multiple nodes having Automation Server, so
that the nodes are set behind a load balancer.
Consider that Automation Server has two main components supporting the runtime of your processes:
· Work portal: A web-based portal where end users to log in to work on processes.
The Work portal is set as a web application inside of the IIS.
· Scheduler: An agent run by Bizagi as a Windows service, in charge of running system maintenance, offline and
asynchronous tasks, all which you can schedule and run in batches. The Scheduler is by default, and usually, set
within the same server having the Work portal, though you may choose to install these two separately.

Prerequisites
You will need at the Bizagi server, the Microsoft .NET 4.6.1 full Framework.
You may install this component as directly available by download at Microsoft web sites:
https://www.microsoft.com/en-us/download/details.aspx?id=42642.
Alternatively, you may let the Automation Server installer install it automatically.

The following OS versions are supported (bound to the IIS version they feature/support):

OS IIS VERSION

Windows Server 2019

10
Windows Server 2016

Windows Server 2012 R2 8.5

Windows Server 2008 R2 7.5

Required Bizagi configuration

Once you have the .NET framework, make sure you consider these two tasks:

1. Enable Internet Information Services and its required features.

Turn on the IIS roles and features, as described at Enabling the IIS and its features.

2. Install the Oracle's connectivity client at the Bizagi server.

This is applicable only if you are connecting to an Oracle database.
Whether using Oracle as the processes repository (Bizagi's database) or when integrating an external Oracle
database in the processes.
To install the connectivity client, refer to Installing the Oracle's connectivity client.

Enabling IIS and its features

Overview
Automation Server provides a Work Portal as a web-based application through which end users log in to access
Bizagi process applications and work on their daily activities.
In Bizagi projects running on a .NET platform, this Work Portal is set in IIS (Microsoft's Internet Information Services),
and it requires specific features to be enabled.

Required configuration
To configure IIS to work with Bizagi, you need to enable it in your Windows operating system, and make sure you
explicitly activate the following features of IIS:

Page 28 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 IIS FEATURE GROUP IIS FEATURE APPLIES FOR...

Web Management Tools IIS 6 Metabase compatibility IIS versions 7.5 or above.

IIS Metabase and IIS 6 IIS versions 7.5 or above.

configuration compatibility

IIS Management Console IIS versions 7.5 or above.

World Wide Web Services .NET Extensibility IIS versions 7.5.

.NET Extensibility 4.5 IIS versions 8.5 or above.

ASP.NET IIS versions 7.5.

ASP.NET 4.5 IIS versions 8.5 or above.

Common HTTP Features Static Content IIS versions 7.5 or above.

Performance Features Static Content Compression IIS versions 7.5 or above, for performance
enhancements.

Dynamic Content Compression IIS versions 7.5 or above, for performance

enhancements.

Basic authentication IIS versions 7.5 or above, recommended

Security especially for an enhanced security setup
of Bizagi's SOA web services.

Windows authentication IIS versions 7.5 or above, when using

Windows authentication.

IP and Domain restrictions IIS versions 7.5 or above, recommended

especially for an enhanced security setup
of Bizagi's SOA web services.

IIS configuration
Carry out the steps described next, to make sure that your IIS is set to work with Bizagi.
Refer to the specific section according to your Windows operating system:
· IIS 10 / Windows Server 2016 and 2019
· IIS 8.5 / Windows Server 2012 R2
· IIS 7.5 / Windows Server 2008 R2

IIS configuration mentioned in this section and the links above, refers to an Automation Server production
environment setup.
Windows Server OS are detailed and strongly recommended.

IIS version 10 (Win 2016 and 2019)

Overview
This section illustrates how to configure IIS (Internet Information Services) as a prerequisite of a production
environment when running Automation Server on a .NET platform and in a Windows Server 2016 and 2019 (using IIS
version 10).
In such OS, the IIS installation is performed as a server role.

For more information about this prerequisite, refer to Enabling IIS and its features.

Page 29 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
IIS installation
To install or review that you have properly installed the IIS server (with all its components required by Bizagi), follow
these steps:

1. Locate the Server Manager panel.

This administrative option is available by right-clicking on Computer and selecting Manage or also directly from the
quick-access icons:

Notice you require administrator's privileges for IIS installation.

2. In the Server Manager window, locate the Dashboard quick start options and use Add Roles and features.
This will launch a wizard that will guide you to setting up your IIS by checking a few things and clicking Next for each
window.

Notice that when you initially use this wizard to install IIS, it will show you a Before-You-Begin page. At this point,
verification of the following should be done:
· The administrator account has a strong password.
· The network settings, such as IP addresses, are configured.
· The latest security updates from Windows Update are installed.

You may also choose to skip this page the next time you install IIS.

3. Select Role-based or feature-based installation and click Next.

Page 30 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
4. Select the Web Server from the server pool, so that you select the local host for the installation and addition of
the roles required.

Page 31 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Next.

5. Select Web Server (IIS) as the server roles you will install.

Page 32 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Click Next.

When asked for required features, make sure you click Add features to meet those required by the IIS server.

Page 33 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Mark the required features as shown:

Page 34 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 buscar

Click Next and review the general information presented about the Web server role. Click Next.

6. Confirm the installation selections made through the wizard and click Finish to start the installation:

Page 35 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Finally, a window will show you the installed Web Server IIS and summary for its role services.
Notice there is an export configuration settings option to reuse this configuration into an XML for PowerShell use in
another machine.

Page 36 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click on Close when done.

Verifying IIS and the default web site

Once the IIS is installed and in order to make sure that you can create projects, open the IIS Manager by using the
inet command or by locating the Internet Information Services (IIS) Manager access from the Administrative tools
folder (Control Panel -> System and Security).

Page 37 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Then, make sure that you have the Default Web site under the listed Sites of your server, and see it enabled and in
a started status:

At this point, you are set to create new Bizagi projects.

Page 38 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
IIS version 8.5 (Win 2012 R2)

Overview
This section illustrates how to configure IIS (Internet Information Services) as a prerequisite of a production
environment when running Automation Server on a .NET platform and in a Windows Server 2012 R2 (using IIS
version 8.5).
The IIS is installed as a server role.

For more information about this prerequisite, refer to Enabling IIS and its features.

IIS installation
To install or review that you have properly installed the IIS server (with all its components required by Bizagi), follow
these steps:

1. Locate the Server Manager panel.

This administrative option is available by right-clicking on Computer and selecting Manage, or directly from the
quick-access icons:

You require administrator's privileges for IIS installation.

2. In the Server Manager window, locate the Dashboard quick start options and use Add Roles and features.
This will launch a wizard to guide you through setting up your IIS.

When you initially use this wizard to install IIS, it will show you a Before-You-Begin page. At this point, verify the
following:

Page 39 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· The administrator account has a strong password.
· The network settings, such as IP addresses, are configured.
· The latest security updates from Windows Update are installed.

You may skip this page the next time you install IIS.

3. Select Role-based or feature-based installation and click Next.

4. Select the Web Server from the server pool, to select the local host for the installation and addition of the roles
required.

Page 40 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Next.

5. Select Web Server (IIS) as the server roles you will install.

Page 41 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Next.

When asked for required features, select Add features to activate those required by the IIS server.

Page 42 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Mark the required features as shown:

Page 43 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Page 44 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Next and review the general information presented about the Web server role. Click Next.

6. Confirm the installation selections made through the wizard and click Finish to start the installation:

Finally, a window will show you the installed Web Server IIS and summary for its role's services.
There is an "Export configuration settings" option. This lets you download this configuration as an XML file for
PowerShell use in another machine.

Page 45 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Close when you are done.

Verifying IIS configuration

Once IIS is installed and to make sure that you can create projects, open IIS Manager by using the inet command or
by locating Internet Information Services (IIS) Manager access from the Administrative tools folder (Control Panel
-> System and Security).

Page 46 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Make sure that you have you Web site under the listed Sites of your server, and that it is enabled and in a tunning
status (you may rely on the default site named Default Web Site or a different one of your choice):

Page 47 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
IIS version 7.5 (Win 2008 R2)

Overview
This section illustrates how to configure IIS (Internet Information Services) as a prerequisite of a production
environment when running Automation Server on a .NET platform and in a Windows Server 2008 R2 (using IIS
version 7.5).
In such OS, the IIS installation is performed as a server role.

For more information about this prerequisite, refer to Enabling IIS and its features.

IIS installation
To install or review that you have properly installed the IIS server (with all its components required by Bizagi), follow
these steps:

1. Go to Start\All Programs\Administrative Tools\Server Manager.

You can also right-click Computer and select Manage. You must have administrator privileges for IIS installation.

2. In the Server Manager window, locate the Roles option, right-click it, and select Add Roles.

Page 48 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This will launch a wizard to guide you through setting up your IIS.

When you initially use this wizard to install IIS, it shows you a Before-You-Begin page. At this point, verify the
following:

Page 49 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· The administrator account has a strong password.
· The network settings, such as IP addresses, are configured.
· The latest security updates from Windows Update are installed.

You can skip this page the next time you install IIS.

3. Check Web Server (IIS) so that it is selected for the installation and addition of roles required.

Click Next.

The following window shows you general information about the IIS web server.
No action is required in this window. Click Next when done viewing the information.

Page 50 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
4. Select the role services required by Bizagi for the Web Server component (IIS).

Page 51 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Next after double-checking that all required components are marked for.

While marking some components, addition of some required roles may be prompted.
Allow the addition of the role services requirements (click Add Required Role Services).

5. A confirmation window wil appear, showing you a summary of the role services that will be installed.
Once you proceed, the installation will begin.

Page 52 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
6. Finally, a window shows you the installed Web Server IIS and a summary of its role services.
Rebooting your server may be needed so you can use of IIS and its features.

Verifying IIS configuration

Once IIS is installed, to make sure that you can create projects, open the IIS Manager by using the inet command or
by locating the Internet Information Services (IIS) Manager access from the Administrative tools folder (Control
Panel -> System and Security).

Make sure that you have your Web site under the listed Sites of your server, and that it is enabled and in running
status (you may rely on the default site named precisely Default Web Site or a different one of your choice):

Page 53 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Installing the Oracle's connectivity client

Overview
Automation Server requires a database server for your processes repository.
Oracle databases are supported for the database server configuration, as described at Oracle prerequisites.
Once you install and set up an Oracle instance, you need to carry out the following tasks:

1. Create a specific admin user to be used by Bizagi.

2. Install Oracle's connectivity client on the Bizagi server.

This section details how to perform the second configuration task.

Oracle's connectivity client

Automation Server relies on the Oracle Data Provider for the .NET connector to access an Oracle database, while
running in a .NET platform.
This connector is needed only when any of the following are met:
· The process repository is hosted in Oracle.
· Your processes integrate one or more external Oracle data sources (by relying on the Data Virtualization or Data
Replication Bizagi features).

The connector is not needed at the database server but at the Bizagi server (where Automation Server is installed,
both for its Work portal and Scheduler).
The following table describes where this component is needed according to the features involved:

Installing Oracle Data Provider required... On the Bizagi Server On the server running the
(running the Work Scheduler service (usually the same
portal) Bizagi Server)

When using Oracle for Bizagi Processes Yes Yes

repository

Page 54 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 When using Virtualization to integrate Yes No
Oracle

When using Replication to integrate Oracle No Yes

Procedure
To install this client, follow these instructions:

1. Download the installer

The Oracle Data Provider for .NET is installed through Oracle Data Access Components (ODAC).
Bizagi requires the ODAC 11g release which ypu can download directly from Oracle's website.

For a 64-bit Bizagi setup, download the 11.2.0.3.0 x64 release for .NET 4.0 at:
http://www.oracle.com/technetwork/database/windows/downloads/index-090165.html

2. Install ODAC and its ODP.NET component

Run the installer on the Bizagi Server (where Automation Server is running), and select the Oracle Data Access
Components for Oracle Client option:

Then select the Oracle-Data-Provider for .NET component:

Page 55 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Install to complete the procedure.
After you see a message that the installation is complete, you may close the installer.
Further information about the Oracle Data Provider for .NET, any requirements or its detailed instructions, are found
at Oracle's website:
http://www.oracle.com/technology/software/tech/windows/odpnet/install1110720.html.

3. Do this for additional servers if necessary

If you are using a Bizagi cluster or have the Scheduler service running on a different server, install this component
on each server.

Note that:
· The database server does not require this component.
· End users do not need to install this component on their workstations, as they access Bizagi Work Portal, which
only requires a browser.

Page 56 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Other assets and prerequisites
Overview
Your corporate Bizagi system architecture, may involve the use of other assets, which you need to have set up, as
described at System prerequisites.

This section presents clarifications and guidelines about installing other assets that you choose to use in your Bizagi
system architecture.

Guidelines
Consider the following:

1. Load balancer
For the load balancing for Bizagi servers (a Bizagi cluster), using a high availability setup, you may use either a
software or hardware load balancer.
Bizagi does not provide the load balancer.
We recommend using of a hardware-appliance load balancer such as f5.

2. File server
Files and documents uploaded through your processes, are not stored in the database.
You may choose to integrate your corporate ECM/DMS system as a documents repository to store files and
documents; or you may rely on a file server (i.e., a shared network drive). Bizagi does not provide the file server or
ECM/DMS system.
It is important that all nodes of your Bizagi server cluster have access the to file server.
The file server has no specific requirements, beyond having sufficient hard disk capacity to store your documents
and files.

3. Reverse proxy server

If you choose to set up secure access to your processes via Internet, we recommend that you use two nodes for a
reverse proxy server in a high availability system architecture (configuring a load balance cluster at this layer).
Bizagi does not provide the reverse proxy server.

Installation
Overview
Automation Server is the runtime platform where your designed business processes and applications operate and
are made available to your corporate end users.
This section describes how to install Automation Server for a testing or production environment.

Make sure that you have met the prerequisites as described at System prerequisites.

Further information
Refer to the following topics to view the detailed procedure:
· Downloading the installer.
· Verifying the installer.
· Running the installer.

Downloading the installer

Overview
When planning to install Automation Server, you may download the installer directly from Bizagi's official web site.
This section illustrates how to download the latest version of Automation Server.

Before you start

Page 57 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Make sure you have purchased the appropriate license for your production environment.

Procedure
To download the installer, follow these simple steps:

1. Go to our official page, Bizagi.com, and click Login.

2. Sign up or log into Bizagi to access your portal page.

When the accounts service screen appears, provide authorized client or partner credentials.

Page 58 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
3. In the upper part of the portal page click Downloads.

4. A list of available software appears.

Page 59 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Select the Automation Server .NET download option.

The download should start automatically and may take a few minutes.
Once the download is complete and saved into your local computer, proceed to Verifying the installer.

Verifying the installer

Overview
This section describes what you do after Downloading the installer.
When planning to install Automation Server, you may verify that the installer file has been downloaded successfully
(completely and without corruption), and make sure as well that it is a legitimate Bizagi installer (and has not been
tampered with).
This section illustrates what to look for when verifying a Bizagi installer's integrity and authenticity.

Procedure
Follow these steps to conduct a verification:

1. Locate and navigate to the folder where the Bizagi installer file is stored on your machine.

Page 60 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. Right-click the installer and select the Properties option.

Page 61 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
3. A window displaying the file's properties appears.
On the ribbon, select the Digital Signatures tab.

4. There, you will find a list of all the signatures that have been added to the file.
Locate and click the Bizagi Limited signature and then click Details.

Page 62 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
5. On the details window select the General tab.
There, review two aspects to make sure that the file has not been tampered with.

Page 63 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 a. Under the text Digital Signature Information make sure that the message "This digital signature is OK."
appears.

Page 64 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 b. At the bottom of the window, make sure that "Symantec Time Stamping Services Signer" is featured as the
file signer's name.

Page 65 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
6. Additionally, you may inspect closely and verify one by one, the certificates employed to sign the installers.
To do so, click View Certificate.

Page 66 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
If doing so, keep in mind the following:

a. That the Bizagi certificate details display: Bizagi Limited as the Issued To information and "Symantec..." as the
Issued By information.
The Valid From... to date range should be valid as well.

Page 67 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 b. That you can view the full path of certificates employed, up to the root, by in the Certification Path tab.
You may click the Symantec certificate and the VeriSign one (root) to check for their details.

Page 68 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Details regarding the Symantec certificate should include: Symantec as the Issued To and VeriSign as the
Issued By information, and a Valid From... to date range.

Page 69 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Details regarding the VeriSign certificate should include: VeriSign as the Issued To and Issued By information,
and a Valid From... to date range.

Page 70 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
If any of the information is not as expected, then double check that the installer was downloaded from our official
site www.bizagi.com.
If you are still not sure the installation file has not been tampered with, contact our Support Team.
Otherwise, proceed to Running the installer.

Running the installer

Overview
Run the Automation Server installer on the Bizagi server for your testing or production environments.
This step is applicable to every Bizagi servers you use, if you are opting for a high availability scheme (a Bizagi
cluster).

This section describes what you do after ensuring that the installer is valid and complete, as described at Verifying
the installer.

Before you start

Make sure your machine meets the prerequisites presented in the System prerequisites chapter.
To install Bizagi, you need to have a 64-bit operating system installed.

Page 71 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The installer includes the .NET required components, such as the Microsoft's .NET Framework version 4.6.1 (which
includes, other components such as Visual C++ 2010, 2008 Redistributable) if not already installed.

Procedure
Follow these steps:

1. Run the installer with administration rights.

2. Select the language for your installation.

3. At the Welcome window of the installation, click next.

Page 72 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
4. Review the terms of Automation Server license agreement and click Next.

Page 73 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
5. Select the database to use
You may skip this step in the installation itself (for instance, if you will use an Oracle database).
However, you will need proper database configuration later on to create a project in Bizagi.

Page 74 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
6. Click Next if you wish to install Bizagi in its default path ("C:\Program Files\...").
To select a different folder location, click Browse, and choose a file directory.

Page 75 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
7. Start the installation Process
In the following window click Install to proceed with the installation.

Page 76 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The following window appears when the installation is complete.

Page 77 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Finish.
Note that this installation requires a reboot.

Initial project configuration

Overview
Automation Server is the runtime platform where your designed business processes and applications operate and
are made available to your corporate end users.
This section describes how to configure Automation Server for a testing or production environment, and how to set
up your Bizagi project.

Make sure that you have already installed Automation Server as described at Installation.

Before you start

Make sure that you have the appropriate licensing to support your production environment operations.

Configuration alternatives
Configuring the Bizagi project in a testing or production environment can be done in different ways:

1. Use on Bizagi's One-click deployment feature.

This alternative automatically deploys the Processes and configuration from the Development environment to set up
the Testing or Production environment.
You must have online connectivity between your development environment and your target environment (testing or
production).
For more information about this option, refer to One-click Deployment.

Page 78 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. Manually setting up the Bizagi components.
In this alternative, you set up the environment prior to a deployment of processes (you can leave the environment
ready for use, and later deploy processes through the Advanced deployment feature).
For more information about how to do this, refer to Advanced Deployment.

You may combine both approaches, using the One-click deployment feature for an initial deployment (without
having online connectivity between your development and production environments), and then using Advanced
deployment for incremental deployments.

Deployment of processes and new versions

Overview
Once the process automation cycle has been completed, Bizagi lets you publish processes for use.
Deployment of Bizagi processes involve promoting the processes into a Test or Production environment.

Deployment should be done first to a Test environment, then optionally into a Staging environment, before moving
into a Production environment.

Bizagi promotes agile management of continuous improvement.

New process versions can be released easily to respond to business needs.

Bizagi Environments
An environment in Bizagi is an independent application of a Bizagi project (it has its own Work portal, Database, and
Scheduler service).

By default Bizagi presents three different environments, each with its own major objective: a Development, Test and
Production environment for a same project.
When using the Deployment feature it is strongly recommended to use these three environments.

Page 79 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Development: The Authoring environment. This is the only environment in which processes are modeled and their
implementation details are specified. Design and construction stages take part in this environment, in which the
data model, the forms and the business rules are created, along with the performers, interfaces definitions and
others specifications. Work in this environment takes place through Bizagi Studio.

· Test: This environment simulates the Production environment. The development team carries carry out user
acceptance tests for the functionality and certification of processes. Processes in the Test environment can be
marked as "Release Candidate" and locked to avoid modifications in the Development environment until the
release candidate version has been promoted to Production. The target enviroment is administered through the
Bizagi Management Console.

· Production: This is the actual operating environment in which the client's processes are available to end users.
Through the Bizagi Management Console, management tasks and configurations can be carried out in the
Production Work Portal such as editing business policies, user administration and authorization configuration, and
administration for the SMTP server or ECM systems.

Process Deployment options

For assisted process deployment, Bizagi provides One-Click Deployment.
Through One-Click Deployment Bizagi automatically publishes processes into an environment different than the
Development environment, and configures that environment.
Through this procedure, Bizagi automatically creates or updates that environment (i.e., sets up a production
environment).
For more information about this option, refer to One-Click Deployment.

For more sophisticated scenarios, Bizagi provides an Advanced Deployment Tool. This option is useful for the
following scenarios:
1. Projects requiring offline deployment.
2. Projects with many developers performing specific modifications in parallel.
3. Projects with more than three environments.
4. Projects relying on deployment software or policies in which deployment must be done manually (applying
packages).
For more information about this tool, refer to the Advanced Deployment.
Before actually performing a deployment, it is important that you review Preconditions and requirements.

Previous considerations and requirements

Overview
Before carrying out a process deployment in Bizagi, , using either the One-Click feature or Advanced Deployment,
review the following.
Consider as well the technical requirements which apply only to One-Click Deployment.
For more information about Deployment in Bizagi refer to Deployment of processes and new versions.

Before you start

If you will be running your processes in a .NET platform, the use of IIS Express is not supported.
The bundled IIS Express server in Bizagi Studio enables quick prototyping capabilities and allows you to use a
simpler server to verify, demo/present, or do unit tests on your process implementations.
This server was not designed to be used in a production environment, since such an environment demands a more
robust server. Instead, we strongly recommended that you use IIS assupported by the Windows operating system,
even in a development environment.

1. General requirements regarding processes implementation

Consider the following regardless of the type of deployment want toyou use.

Page 80 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
1.1 Processes check-in
Make sure that the process versions planned for deployment are all checked-in in the Development environment.
To do so, in Bizagi Studio select Expert View, and click the Processes module.
Processes to be deployed should be all checked-in. Verify that no one else is working on the model, and that the
processes can be checked-out:

Coordinate the deployment with other team members of your project, so they are aware of the timing of this
procedure and can agree which Bizagi process versions will be deployed.

1.2. Acknowledging how and which objects are deployed

Bizagi handles deployment differently according to what is, or is not, taken to the Production environment.
Furthermore, some objects might require special attention when required for deployment.
It is important to understand deployment behavior and features as they vary according to the selected module
(Entities, Security, Systems, etc.).

For instance, Parameter Entities have a special configuration in which you can select individually each attribute to be
deployed.
Click for more information about how Bizagi deploys objects and modules.

1.3. Deciding if your development data should be taken into the environment
Bear in mind that when moving a project from a Development environment to another environment you need to
consider whether you need the data that you have been using in the development environment: User's data and
parameter entities managed in production. If that is the case, additionally from performing a deployment, a Data
Synchronization must be performed.

Page 81 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. Technical requirements

If you plan on using an authentication method different than Bizagi and you are performing a deployment to an
environment with no users on it (normally this would only be the case for a project's first deployment), follow
these steps so that you can correctly configure your users and authentication without getting locked out of the
Work Portal:
1. Perform the deployment with the authentication method set to Bizagi. This lets you access the Work Portal as
the Admon user without providing any credentials.
2. Once in the Work Portal you can manually enter your users, or alternatively you can rely on the method of
your choice to synchronize your users' information into the WFUser table (SOAP, Excel file, LDAP
Synchronization, or performing a Data Synchronization procedure).
3. Perform an IISRESET so that the Admon user can no longer access the Work Portal.
4. After having your users registered in the Work Portal, use the Management Console to set the authentication
method to your preferred one.

If you plan on using LDAP authentication with periodic users synchronization, you may ignore the previous steps
since you will only need to wait until the next synchronization happens for your users to be able to log into the
Work Portal.

Consider the information below regardless of the type of deployment chosen.

2.1 Environments upgraded to the same Bizagi version

When this is not the first deployment to the same environment (Test or Production already exist), the Development
and the target (Test, Staging or Production) environment projects are updated to the same Bizagi release.

To ascertain the version of a project, use the Management Console options to see the project's information:

Page 82 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2.2 Database servers having the same database version.
The database instance of the Test or Production environment needs to have the same version as that of the
Database Server in Development.

For Microsoft SQL Server, it means applying the same major version and service packs:

For Oracle, the servers must have the same version and the same release number:

Page 83 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2.3 Database servers having the same character settings
The Database instance of a Test or Production environment needs to have the same character settings as that
defined for Development.

If using Microsoft SQL Server, the server collation must match:

For Oracle, the database servers must have the same character set configuration:

Page 84 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
3. Specific technical requirements of One-Click Deployment
The following are technical requirements for using the One-Click Deployment feature in Bizagi Studio, given that this
Deployment is carried out in an online manner and with the assistance of Bizagi.

3.1 Automation Server must be installed in the target environments

To perform a deployment to a test or production environment, Automation Server must be installed in that target
server.
The installed Automation Server version must match the version installed in the Development environment.

3.2 Development server must have network access to the target server
Since One-Click Deployment is done online, the Development Server must be able to access the Test or Production
environment servers (both the server having Bizagi and the database server).
Verify that there are no firewall configuration blocking the ports involved in Bizagi's deployment.

For the connection from the Development server to the Test or Production Bizagi server:
· TCP port number 5679.
· UDP 50051, 50052, 50053.
· The TCP port defined to be used in the response communication (from the test or production Bizagi server back
to the Development server).
This port is specified within the BizagiStudio.exe.config file located in the Bizagi Studio installation folder of your
Development environment (which is by default located at: C:\Program Files\Bizagi\Studio\BizagiStudio).
The TCP response port is by default 0, which means that it will be a random port.

You can edit this port's value by setting a port number allowed in your infrastructure configuration, in the defined
value of the channel element of this configuration file.

Page 85 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
For connection to the Test or Production database derver, make sure that the port defined for the database service
connection is allowed from the test or production Bizagi server.
The default port for SQL Server instances is 1433, while the default port for Oracle is 1521.

3.3 Authorized credentials for the target server

When deploying processes to either Test or Production, Bizagi will create a new project in the target server.
The Windows user performing the deployment needs to be authorized to access the virtual machine..

This means having an account which belongs to the Administrators and Bizagi group at that server, or using the
credentials of an account that meets these conditions.

Deployed Objects
Deployment in Bizagi publishes process versions and other metadata for the project.
For deployments, it is critical to consider the following:

1. Dependencies Engine validations

Bizagi has a dependencies engine which will detect entities, forms, rules, etc. which are being used by the Processes
to be deployed, so that they are taken into the target environment automatically.

Page 86 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Similarly, Bizagi identifies those entities, forms, rules, etc, in the Development environment which are not being used
by the Processes to be deployed. These will not be taken into the target environment by default.
It is also possible to decide manually to include additional objects in the deployment.

· Elements which are defined as global elements (e.g, scripting functions or business rules at the Application
level) do not belong to a specific process and therefore are not automatically detected by the Dependency
engine. To deploy such elements along with processes that use them, you need to manually relate them by
using the Relate objects option.
· Do not delete elements that have already been deployed. Doing so might cause undesired effects at runtime.

2. Attribute features which cannot be activated/deactivated

There are certain features for attributes (or entities), which you may not activate once these attributes (or entities)
are published in a production environment with that feature deactivated.
Similarly, you may not deactivate such features if these attributes (or entities) have been published in a production
environment with that feature activated.

Attribute features whose activation/deactivation cannot be changed after deployment are:

· Database level encryption.
· Data Virtualization and Data Replication.

This means that if your production environment attribute is already using database level encryption or being
replicated/virtualized from an external database, you may not change the definition of that attribute to stop using
that feature.
Instead, if you do need to change the definition, stop using that attribute (and disable the replication scheme when
using replication), and create a new process version that uses a new attribute in its place.

3. Parameter Entities Administration

Each parameter entity has in its advanced properties, a definition that states whether the entity is designed to be
managed in the Production environment or the Development environment.

Therefore, we recommend that you review in depth which parameter entities's values require being deployed into
Production.

Note that a parameter entity cannot be managed in both Development and Production environment. Select one
environment to manage (insert, edit or disable) the entity values.

Page 87 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
For the first deployment, all the values for the parameter entities can be taken from the Development environment
into the Production environment (regardless of this definition).
In further deployments (when Production already exists), only the values of parameter entities which are managed in
the Development environment are updated and taken into the Production environment.

For more information about defining or reviewing parameter entities managed in Production, refer to Where to
Manage parameter entities.

· For replicated entities, deployment will only copy the replication schema. Data will be copied into the entity
according to your synchronization settings.
· As soon as a project is deployed, users must add records to parameter entities via the Work Portal, but only if
the entity is manageable in production. Otherwise, values can be added using Bizagi Studio, and thereafter the
entities can be deployed to production.
· When a parameter entity contains images or files, these will not be deployed, and will have to be included
manually in the Production environment. If you require help please contact Bizagi Support.

4. Production settings
There are several modules in a Bizagi project.
For each module, there are different settings and their configuration may have different values for each environment
in a project (Development, Test, and Production).

The environment values presented in Bizagi Studio for the Test environments, are always set for deployment.
Consequently, these values are automatically applied to the Test environment when executing a deployment.

The environment values presented in Bizagi Studio for the Production environments, may have their values initially
set for the first deployment to those environments (so that these values are automatically applied to the target
environment).
However, after the first deployment, administration for these values has to be done directly in the target
environment, using Bizagi Management Console.

4.1 Environment options

Page 88 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
In the Development environment, you may initially set the values for the Environment options that apply for the Test
and Production environment.
For the Production environment, you can set the values to be used in the first deployment to that environment.

Once this configuration is applied to Production, you cannot edit the Production environment parameters and
definitions using Bizagi Studio in the Development environment.

You will need to edit the values using the Management Console in the Production environment.

Click for more information about Environment configuration.

4.2 Interface Properties (Systems)

When defining an Interface for a web service invocation, you may set and define its initial property values (URL,
method, authorization credentials, logging threshold) for each environment.

Page 89 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Once the interface has been deployed to the Production environment, you cannot edit its property values in the
Development environment.
For the Test environment, values can be redefined in the Development environment (through Bizagi Studio), so that
a new deployment overwrites the existing values.

In brief, for Interfaces already deployed to Production, any changes to their property values need to be made using
the Management Console in that environment.

4.3 Provider Properties (Systems)

When creating a new Provider for the Virtualization or Replication features, you may set and define its initial
property values for each environment.
Once that Provider has been deployed to the Production environment, the values for that Provider may no longer
be edited directly in the Development environment.
For the Test environment, values can be redefined in the Development environment (through Bizagi Studio), so that
a new deployment overwrites the existinge values.

Page 90 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
In brief, for Providers (used in Virtualization and Replication features) already deployed to Production, you need to
edit their property values using Management Console in that environment.

4.4 ECM Properties (Systems)

When creating a new repository, you may set and define its property values for each environment (this includes the
folders of the repository).
Once the ECM configuration has been deployed to the Production environment, its values may no longer be edited
directly in the Development environment.
For the Test environment, values can be redefined in the Development environment (through Bizagi Studio), so that
a new deployment overwrites existing values.

In brief, for ECM system-configurations which are already deployed to Production, any edition to their property
values needs to be done using the Management Console in that environment).
This same concept applies to the folder definitions in the ECM integration.

4.5 Authentication and LDAP settings

You can initially define the options in the Security module for Authentication and LDAP synchronization in your Bizagi
project in the Development environment for the Production environment (if you are using LDAP or any other
configuration related to the Work Portal's authentication method).

Once your project has been deployed to Production, you can edit the settings for that environment using its
Management Console (you can no longer edited them from the Development environment).
For the Test environment and only for Authentication type and Authorization settings, values can be redefined in the
Development environment through Bizagi Studio, so that a new deployment overwrites existing values.

Page 91 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
In brief, you need to make edits in existing Authentication, LDAP and Authorization in the Production environment
using that environment’s Management Console. Changes in Authentication and Authorization made in the
Development environment are automatically deployed to the Test environment.

4.6 Users (WFUser values)

The first deployment to the Production environment does not include users. The Admon user remains as the only
user. For further information about the Admon user click here.

Page 92 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 New users must be added manually, by synchronization, or importing them from the development or test
environment.

When you perform your first deployment to any environment, the Admon user will be able to log in without
inputting credentials until users are loaded into your target environment.

4.7 User groups (Organization definition)

Definition of the elements in your Organization, which will be involved in the project (such as areas, positions, skills,
roles, user groups, etc.), is managed only in the Development environment.

Although this includes defining user groups, these in particular can also be edited directly in the Production
environment.
Editing User groups implies including or removing users for that particular User group, it is not be possible to
create new user groups or delete existing ones in the Production environment.

4.8 Alerts and Sensors

When you create a new process version, and you deploy it to test or production environments, existing Alerts and
Sensors of the previous active version are cloned and deployed automatically. Refer to Alerts in New Versions and
Sensors in New Versions.

5 Experience Objects
Since Digital Transformation allows multiple non-related objects to interact, they are highly uncoupled. Thus, when
deploying these unrelated objects it is necessary to explicitly select every related experience object you want to
deploy.

Stakeholders
A Stakeholder is included in a deployment package as long as any of its attributes is used in an element of the
process, for example a form or a rule. On the other hand, if it is not used in a process, and the stakeholder entity is
not selected manually as part of the package by selecting an object, and has no dependencies with any deployed
process, the stakeholder is not deployed. To sum up a stakeholder is deployed when:

· An attribute of the stakeholder entity is used in a process being deployed.

· When is selected manually in the deployment options.

Each Stakeholder is deployed independently, as long as it meets any of the conditions previously mentioned.

Page 93 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Users are not associated with stakeholders in deployments. Even if the user already exists in the target
environment.

Objects
Any experience related objects will be taken for deployment automatically as long as they are being used by any
process (such as an Actions). Nonetheless, we strongly advise you to manually select all objects you want to deploy.

The next table lists experience objects and suggests those that should be individually selected to be included in a
deployment.

Object Variant Related objects

Collections (Shown Indirect Collection · Every related context.
in My Stuff)
Direct Collection · Related entity.
· Their context.
· The process related if an Add button is configured.
· The stakeholders and their related contexts if an Add
button is configured.
· Every entity used within the visibility expression (If used
in an Add Button configuration).

Actions Process · The related process.

· Every related context.
· Every entity used within the visibility expression (If used).
· The entity where the action is defined.
· The processes where the action can be launched from.

Form · The entity where the action is defined..

· Every related context.
· Every entity used within the visibility expression (If used).
· The processes where the action can be launched from.

Expression · The related expression.

· The entity where the action is defined.
· Every related context.
· Every entity used within the visibility expression (If used).
· The processes where the action can be launched from.

Contexts Besides from the "Always · The related Stakeholder

available" context

Searches · The related Stakeholder.

· The entity to search (This will deploy the search form as
well).
· The related contexts.

Relevant to me · The related Stakeholder.

· The related process.
· The related context.

Triggers Process · The entity where the trigger has been defined.
· Every entity needed to correctly run the condition
expression.
· The related process, to be launched.

Page 94 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Expression · The entity where the trigger has been defined.
· Every entity needed to correctly run the condition
expression and the trigger expression.

Constructors Process · The entity where the constructor has been defined.
· The process related.
· Every related context.
· Every entity used within the visibility expression (If used).

Form · The entity where the constructor has been defined.

· The expression related.
· Every related context.
· Every entity used within the visibility expression (If used).

Please be aware that the use of the sentences getValueAsCollection and getXPath within an expression
does not make sure that the attribute will be taken in account when deploying. It is, therefore, necessary to add
the following line in your expression in case any attribute of an entity is not being taken into your deployed
environment.

CHelper.usingXPath("Entity Name","Attribute Name");

Relate Objects

Overview
When you deploy Processes to a Test or Production environment, Bizagi runs validations within its dependencies
engine to detect objects which are being used by the Processes to be deployed.

Through these validations, objects like entity attributes, forms, rules, etc., are published automatically into the target
environment.

Similarly, Bizagi identifies objects in the Development environment which are not being used by the Processes to be
deployed.
These will not be taken into the target environment by default.

However, it is possible to decide manually which additional objects should be included when you deploy processes.
This option is especially useful to include objects such as entity queries, which are not necessarily related to a
Process itself.

Defining Related Objects

When you plan and launch a deployment, it is possible for technical profiles executing the deployment to detect
objects that are not explicitly used by a Process; and to manually include these objects through the same option
(present in a deployment's configuration).

Page 95 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
For example, when you deploy a process, you may want to specify that this deployment deploys a specific query
form (or entity query) into your target environment (Test, Production).
You may do so by using the Relate Object option to mark that the particular query form relates to a Process.

Objects to relate
To relate objects, click the Related Objects option from the Deployment Wizard.
Within the configuration window, you may relate: Attributes, Query forms, and Business Rules (including functions)
or Custom jobs.

Attributes
Click the first Attributes tab to select the attributes of the entities (Master or Parameter type) which you want to
relate to the given process. You can select the entity if you want to select all its attributes.

Page 96 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Query forms
Click the Query forms tab to select the Application or Entity level queries which you want to relate to include in the
deployment.

Page 97 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
In the image above, the Entity query Purchase Request Query is marked as a related object.

Business Rules
Click the Business Rules tab to select the scripting or Boolean type rules and function you want to include in the
deployment.

Page 98 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
In the image above, the Business rule Find Cases (at the level of Business Rules) is selected as a related object. Bear
in mind that any defined Library rule is automatically included in the deployment.

Custom jobs
Click the Custom jobs tab to check the custom jobs you want to relate to the given Process.

Page 99 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
In the image above, the Custom job called CancelCases is marked as a related object.

Entity Components
Click the Add deployment components link to display the entities whose components can be deployed.

Page 100 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Select the components you want to be part of the deployment. Only entities with valid components are listed. The
valid elements are:
· Relevant
· Triggers
· Constructors
· Contexts
· Actions
· Searches

In the image below, the Entity query Customer has multiple objects eligible for deployment.

Page 101 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Using of the statement getValueAsCollection within an expression does not assure that the attribute will be
included when deploying experience components. Add the following line to your expression for attribute of an
entity that is not being taken into your deployed environment:

CHelper.usingXPath("Entity Name","Attribute Name");

One-click Deployment

Overview
Bizagi Studio presents a friendly Deployment Wizard to publish the project's processes in a quick online procedure.
This procedure is assisted by the Process Wizard, in which one-click configurations are carried out.

A deployment's configuration involves: selecting which versions of which processes are to be deployed, and then,
choosing the target environment (Test or Production), along with other specific options for each environment.

One-Click Deployment automatically creates (in the first deployment) the target environment's components (Work
Portal, database and Scheduler service).
For further deployments, One-Click Deployment updates the target environment with new information.

This feature is not eligible for Automation Service.

For Automation Service or any other scenarios, in which there is no online connectivity between the development
environment and a production environment, Bizagi provides:
· The Advanced Deployment Tool.
For more information about this tool, refer to the Advanced Deployment.
· The option to export and import processes directly in the cloud, under a similar UI and approach as the one
presented by the Advanced Deployment Tool.

Page 102 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 The options related to objects involved in process deployment in One-Click Deployment are also available when
either exporting to Automation Service or using the Advanced Deployment Tool.

Executing the Deployment

Execute One-Click Deployment is through Bizagi Studio. Launch it from Step 7 of the Process Wizard (the Execute
option) by selecting the Deploy Process option.

This option becomes available once there is at least one Process for which you have clicked the Next option in Step
6.

Alternatively, the deployment window and procedure can be also launched from the Process module (in the Expert
View) by right-clicking on a specific Process version.

What happens with the existing cases?

When a deployment is executed by Bizagi, existing cases of Processes in the Development environment are not
taken to the Production or Test environment. Bizagi does not deploy values stored in master entities.

When a deployment is carried out to an already-existing Production environment, existing cases in the Production
environment will be kept consistently in that environment:

· If a new Process version is deployed to Production, the existing cases will continue to work with the version they
were created with.
· New cases created in Production on will be created under the latest deployed Process version.

You may also make minor changes to a Process which is already in Production (and have the existing cases adopt
those changes). For this scenario (e.g adding a new attribute, modifying a business rule or a performer assignment),
you must modify the current Process version and publish this version again to the Production.

How to do a deployment?
Deployment of Bizagi Processes should be done after making sure all prerequisites have been satisfied, and by
following the recommended deployment cycle.

Page 103 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Prerequisites
To review the prerequisites for a deployment of your Bizagi project, refer to Previous considerations and
requirements.

Recommended deployment cycle

The following steps illustrate the recommended deployment cycle of Processes versions:

1. First, deployments to the Test environment are made in an iterative way so that required additions and
modifications are detected in the Test environment and the code can be adjusted in the Development environment.
In the Development environment you can also perform quick prototyping, workflow verification and unit tests.

Perform these iterations without marking the version as a Release Candidate until it passes all unit tests in the Test
environment.

2. When there are no more adjustments to be made to what was observed in the tests carried out in the Test
environment, you can deploy to the Test environment by specifying the process versions that are to be marked as
Release Candidate.
If adjustments are required, you have to cancel the Release Candidate, perform the adjustments in the Development
environment, and start again.

Page 104 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
3. Once the Release Candidate Process versions have satisfactory test results and are approved you can apply the
Release Candidate to the Production environment.

4. Subsequent deployments for continuous improvement of the existing Processes, or to publish new Processes,
should follow the same process.
Click for more information about Continuous improvement and development after a deployment.

Deployment to the Test environment

We strongly recommend that you perform deployments to a Test environment prior to deployments to the
Production environment.

Use a Test environment with similar characteristics of the Production environment, so that user acceptance tests can
certify that the Processes are ready (their behavior, integration points and Workflows are as expected) to be taken
to a Production environment.

Click for more information about the Deployment to the Test environment and detailed explanation about the
Release Candidate option.

Deployment to the Production environment

Once process versions in the Development environment do not need further additions or modifications, you may
deploy your Processes to the Production environment.

Click for more information about the Deployment to the Production environment.

Page 105 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Test environment deployment

Overview
Deploying processes to a Test environment is strongly recommended so you can perform user-acceptance tests
and certify that the Processes behave as expected.
In this section we will illustrate how to perform a deployment to the Test environment using the One-Click
Deployment feature in Bizagi.

Prerequisites
Before reading this section and launching a deployment to the Test environment, make sure you have read the
prerequisites for a deployment.
Click for more information about the Previous considerations and requirements for a deployment.

Deployment to Test
The steps and options for a deployment to Test differ if the deployment is the first deployment of the project to the
Test environment or not.
The options for a deployment to Test are also slightly different from those presented for a deployment to
Production.

First deployment to Test (initial deployment)

In a first deployment of a project to any environment, Bizagi automatically creates the project's environment on the
target servers (creating the Work Portal and Scheduler at the Bizagi server, and the Bizagi database on the
database server).

Page 106 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This means that to create a project, you should make sure that your servers for the test environment are configured
properly to allow a new project.
For the first deployment of a project to the test environment, the procedure is described below.

1. Launch the One-Click Deployment Wizard.

Go to the seventh step of the Wizard (Execute) and click Deploy Process.

2. Select the target environment.

In the window that appears, mark the environment to which you want to deploy your Processes.

When the chosen environment is Test, you can mark the Release Candidate option to lock the processe versions in
the Development environment (so that changes are not allowed to them).
Click for more information about the Release Candidate option.

Page 107 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Select the Test environment option and click Next.

3. Select the target server

Available servers with Bizagi Server Components installed (which are visible to the Development server's network)
appear as icons.

Select the target server for the Test environment and click Next.
You may choose to input directly the name of the server in the first server icon if the Server's name does not appear
with the listed icons.

Page 108 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You may also choose the path where the Test environment project files will be stored.

You may choose for the test server, the same server you have set for the Development environment (although for
proper user acceptance tests it is usually recommended to have different servers).

Inputting IP addresses instead of a Server name is supported, but take into account that while using IP addresses
it is necessary to make sure that the IP addresses are not dynamic.
In other words, IP address for servers involved in the configuration of the deployment must not change.

If the selected test server differs from the development server (the local one), make sure that you have authorized
credentials to create a new environment in the target server.

Page 109 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This means that: either the Windows user performing the deployment must be a member of the Administrators and
Bizagi groups of the selected server, or you have at hand an authorized account for that server (belonging to those
groups, as described at Deployment's previous considerations and requirements).

4. Select the Database Server.

After choosing the server, Bizagi will search for installed databases instances.
Select the target Database Server that will be used for your Test project's database.

You may select it from the drop-down list, or type directly the database instance's name.
For the Test environment, the project's database name is defaulted as "Test_[myProject]", but you may edit this
name as well.

Input the database login information and click Next.

5. Configure advanced options.

In the next window, you may define deployment options for the following advanced configuration:

Page 110 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Related objects: You may mark additional objects (such as entity query forms) to be explicitly included in the
deployment.
If the entities marked do not have attributes, they will not be included in the deployment.

Page 111 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click for more information about Relating objects.

· Add more Processes: You may choose to include more than one version of the Processes in this same
deployment.

Page 112 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 · Only the domain\admon user will be automatically created in the Test environment.
o It is necessary to make sure that the domain\admon user has proper privileges to create other users.
· Processes that are not explicitly selected will not be deployed, even when they are related anywhere else in the
code.

6. Confirm your deployment configuration.

A summary window shows the configured information related to this deployment.
You can review the selection of your Processes versions to include in the deployment, as well as their related objects
(as described in the step above).

Page 113 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
To start the deployment click Finish.
The wizard will prompt you to close any Bizagi Studio or Management Console instances that have this same project
loaded before you begin the deployment.

7. Finish the Deployment.

One-Click Deployment will automatically run validations and create the target environment's project.

Page 114 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
It will notify you once the deployment procedure is completed.

Page 115 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
When the deployment finished window appears, click Close.

Page 116 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Once the deployment is completed, you can run the Test Work Portal by using the Execute option in the Process
Wizard, in which a published URL will be available.

Click the published environment's label to launch the Work Portal:

Page 117 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Subsequent deployments to Test (incremental deployments)
Subsequent deployments to the Test environment, are done after the first one to that same environment.
Options presented for a Test deployment which is not the first one will slightly vary.

During subsequent deployments and by default, the existing test servers (as configured in the first deployment) are
basically just updated with the selected process versions, and no new project is created.
However, this setting can be edited so that a new test environment is created by specifying a change in the target
servers, whether for its Automation Server or for the database server.

This procedure is as follows:

1. Launch the One-click Deployment Wizard.

Go to the seventh step of the Wizard (Execute) and click Deploy Process.

Page 118 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Remember that if your latest deployment was made to the test environment and the deployed Processes versions
were marked Release Candidate, you will be prompted to either Apply the Release Candidate or to cancel it.
To review information about this feature, refer to Using Release Candidate for a deployment to Test.

2. Select the target environment.

When the chosen environment is Test, you can mark the Release Candidate option to lock the process versions in
the Development environment so changes to them are not allowed.

Page 119 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Select the Test environment checkbox and click Next.

3. Define options from Production environment.

At this point, when there is already a running Production environment, Bizagi shows an additional option.

You can choose to either deploy the process versions to the Test environment in an isolated manner, or to initially
include in the Test environment existing processes from Production and then add the rest of the processes from
Development.

Page 120 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Without production processes: The Test environment will be created with only the process versions selected for
this deployment (from the Development environment).
· Include production processes: The Test environment will be created with process versions selected for this
deployment, added to those which already exist in the Production environment.
When you include production processes, the option Overwrite test settings with production changes is available.
Select this option if you want to use Production environment settings in your Test environment.

With any of the above options, there must be no existing cases in the Test environment.

4. Configure advanced options.

In the next window, you can define advanced deployment options:

Page 121 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Relate objects: You may mark additional objects (such as entity query forms) to be explicitly included in the
deployment.
Click for more information about Relating objects.

· Add more processes: You may choose to include additional process versions in the deployment.

Page 122 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Only the domain\admon user will be automatically created in the Test environment.
Make sure that the domain\admon user has proper privileges to create other users.

5. Confirm your deployment configuration.

A summary window shows the configured information related to this deployment.
You can review the selection of your process versions to include in the deployment, as well as their related objects
(as described in the step above).
You can also select to use a different Test server by using the Change Server option.

Changing the Test environment server will set the project to continue working with the new specified server. The
old Test environment will not be deleted from the previous server.
When you use this option, a new project will be created on the new Test server (Bizagi will present the same
configuration steps as presented when selecting the servers for a first deployment).
If you choose this option, refer to the First deployment section above.

Page 123 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
To start the deployment click Finish.
The wizard will prompt you to close any Bizagi Studio or Management Console instances that have this same project
loaded before you begin the deployment.

6. Finish the deployment.

One-Click Deployment automatically runs validations, creates a backup of the current environment's database, and
updates the target environment's project.

Page 124 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The backup is stored at the Database's backup path.

For Oracle databases, this path is defined by the Store database backups path set when configuring an Oracle
instance to work with Bizagi.

For SQL Server and in a local setup, the backup location would be: "C:\Bizagi\Projects\[your_project]\Backups").
For SQL Server and when using a remote database, this path will be usually set as: "C:\Program Files (x86)\Microsoft
SQL Server\[MSSQL_instance]\MSSQL\Backup\"

One-Click Deployment notifies you when the deployment procedure is completed.

Page 125 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
When this Deployment finished message appears, click Close.

What happens with existing cases in the Test environment ?

Whenever a deployment to the Test environment is carried out, previous Test cases are deleted (this does not
happen in the Production environment).
For user acceptance testing in the Test environment, we recommend testing the deployed processes with new cases.

Using Release Candidate for a deployment to Test

Deployment to the Test environment presents an option to mark your process versions as Release Candidates.

Using this option flags these Processes as Release Candidate for the Production environment, and Bizagi gives
special treatment to them in the Development environment.

Page 126 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
When to mark your Processes as Release Candidate
Process versions deployed to Test without being marked as Release Candidate are useful for:

1. Running unit tests

2. Detecting the need for adjustments and fine tuning.
3. Running a demo (presentation purposes).

When process versions deployed to Test are marked as Release Candidate, Bizagi:

1. Locks them in the Development environment to avoid further edits.

In other words, the workflow, and other objects such as attributes and forms used by those process versions will
not be allowed to make changes until the given Release Candidate cycle has finished).
2. Keeps the Release Candidate Processes "on hold", with all the necessary information of their related objects to be
deployed to Production.

if you need to make any adjustments in these process, canceling the Release Candidate status is required.
Update the Process version, restart the Test deployment with the Release Candidate status selected, and repeat
as necessary until the Processes are certified.

How does Release Candidate status work?

Process versions marked as Release Candidate have their objects locked in the Development environment as
detailed at Continuous improvement and development after a deployment.

Once the deployment to the Test environment is completed with the process versions marked as Release Candidate,
users involved in the Test environment should carry out their tests to verify that those process versions can be
deployed to the Production environment.

Within the user acceptance tests, any flaws detected in the Processes version or any additional requirements asked
for them, will need to be addressed in the Development environment.
To carry out modifications it will be necessary to use Bizagi Studio's Deploy Process option and to cancel the current
Release Candidate.

Page 127 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
When you click Next, Bizagi will prompt for confirmation:

Once the Realese Candidate is canceled, you can make necessary modifications in the Development environment.
You can then start a new deployment to the Test environment of the revised Release Candidate.
This procedure should be repeated until the user acceptance tests are completed and no further modifications or
adjustments are required for these process versions.

Returning to Bizagi Studio's deployment option, you can choose to apply the current Release Candidate to the
Production environment.
Doing this, launches a deployment to the Production environment with those process versions already approved
and certified.

Page 128 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Summarizing this concept, when there is a current Release Candidate in the Test environment, the Deploy Process
option of the Process Wizard's step 7 (Execute) will prompt you to either: Apply the Release Candidate (that is, to
deploy those Process versions to Production) or to Cancel it (so you can make changes in the Development
environment for those Processes, followed by a new deployment to Test).

Production environment deployment

Overview
Bizagi presents a user-friendly Deployment Wizard to publish process versions to the Production environment,
through a quick online procedure.
In this section we explain how to perform a deployment to the Production environment by using the One-Click
Deployment feature in Bizagi.

Prerequisites
Before reading this section and launching a deployment to the Production environment, make sure you have read
both:

1. The prerequisites for a deployment.

Click for more information about the Previous considerations and requirements of a deployment.

2. About Deploying to Test and its Release Candidate option specification.

Click for more information about Deploying to Test.

In addition to this, make sure you:

1. Have available the proper license for your production server and the number of supported end users.
Click for more information about Licensing.

2. Make backups of both your Development and Production environments before launching Deployment.
This is important because Deployment to Production is a procedure that cannot be undone from Bizagi.

Page 129 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 We also strongly recommend that you to schedule the Deployment and make your team aware of it.
Bizagi's One-Click Deployment will temporarily stop Bizagi services, and therefore it should be done during non-
working or off-peak hours.

Deployment to Production
Deploying process versions to Production should only be done after you have deployed them to and tested them in
the Test environment, using of the Release Candidate feature.

You can deploy directly from Development to the Production environment (without having a Test environment) in the
same manner as performing deployments to Test (with some slight differences in the configuration); however this is
not the recommended procedure.

First deployment to Production (initial deployment)

As discussed in the previous section, a deployment to Production is done through the Release Candidate option.
Here are the steps:

1. Launch the One-Click Deployment Wizard

Once you have done a deployment to the Test environment and had the Release Candidate tested and approved,
go to the seventh step of the Wizard (Execute) and click Deploy Process.

Page 130 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 .

2. Use the Apply Release Candidate option

Since the most recent deployment was made to Test with process versions marked as Release Candidate, Bizagi
promts you to select an action for that Release Candidate.

Page 131 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Select the Apply option for the Release Candidate.

3. Select the target server

If you are performing a first deployment to the Production environment, Bizagi lets you select and define which
servers to use for your production environment (for the Bizagi server and for the database server).
The list of available servers (visible to the Development server's network) with Automation Server installed appears
as icons.

Select a target server for the production environment and click Next.

You can provide the name of the server you want in the first server icon if it does not appear in the list.

Page 132 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You can also choose the path to where the production environment project files will be stored.

Inputting an IP address instead of a server name is supported, but make sure the IP address is not dynamic.
IP addresses for servers involved in the configuration of a deployment must not change.

Make sure that you have authorized credentials to create a new environment in that server.
Either the Windows user performing the deployment must be a member of the Bizagi and Administrators group of
the selected server, or you have at hand an authorized account for that server (belonging to those groups, as
described at Deployment's previous considerations and requirements).

4. Select the Database Server.

Page 133 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
If this is the first deployment, you choose the server, Bizagi will search for installed database instances.
Select the target Database Server for your Production project's database.

You may select the Database instance from the drop-down list, or provide database instance's name.
For the Production environment, the project's database name is "[myProject]" by default, but you can edit this name.
We do not recommend that you use the name of the development environment's project.

Provide the database login information and click Next.

5. Configure advanced options.

Page 134 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Only the domain\admon user will be automatically created in the Production environment.
Make sure that the domain\admon user has the proper privileges to create other users.

· Add deployment components:

When using Experience components (such as Stakeholders, Contexts, Actions, Searches, Relevant to me, Triggers
and My Stuff), select the items you need to be included in the deployment. Experience components are independent
from the process items, and need to be selected individually.
As an example, the Help Desk process in this deployment uses Experience items that are shown when you select
Add deployment components:

Page 135 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The following window displays a list of all the experience components defined in the project, grouped by entities.
In this case, we only want to deploy experience components for the Stakeholder called Call Center Agent and the
actions associated to the Ticket Activities entity.

Page 136 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
As we have explained, each item listed will require the following components to be deployed:
· Relevant to me options: Update Customer information and Register New Ticket.

Relevant to me options are process shortcuts. Therefore the process it launches must be related individually in the
deployment.

Page 137 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 .

Processes that are not explicitly selected will not be deployed, even when they are related to elements that are
deployed.

Since the shortcut depends on a context, make sure it is selected for deployment as well.

Page 138 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Search: Cases

This is a search, so we need to take into account the stakeholder entity from which the search is available, the entity
to perform the search and the contexts where it is available.
If the entity marked does not have attributes, it will not be included in the deployment.

Page 139 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 o The search form is automatically deployed along with the searched entity.
o The stakeholder from which the search is available is automatically included when the search is selected.
o The context related had been selected previously.

Page 140 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Actions: Register Activity / Solve ticket and Escalate Ticket

Depending on the sort of action, different components and objects are related, in this case Register Activity / Solve
ticket and Escalate Ticket are form actions. Therefore, the related objects are:

Page 141 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 o The entity where the action is defined. This will also deploy the related form. Since we are selecting the action,
this will automatically deploy the associated entity.

o Every related context. In this case, the action Register Activity / Solve ticket is always available for the Help
Desk Agent stakeholder, under the Not Last Service Level context.

Page 142 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 o Any of the actions use a visibility expression, thus it does not relate any entity nor attribute through an
expression.
o The processes from which the action can be launched.

All experience components of the Call Center Agent are now ready to be deployed. For further information about
relating objects and experience components, please review Related Objects.

6. Confirm your deployment configuration.

A summary window shows the configured information related to this deployment.

You may not: add more Process versions at this point, since the deployment is applying an already tested/accepted
Release Candidate, or change the Production environment server while in the deployment procedure.

Page 143 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
To start the deployment click Finish.
The wizard prompts you to close any Bizagi Studio or Management Console that has this same project loaded
before you begin the deployment.

7. Finish the deployment.

The One-Click Deployment automatically runs validations and creates the target environment's project (if you are
deploying to Production for the first time).

Page 144 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
It will notify you once the deployment procedure is completed.

Page 145 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
When this Deployment finished window appears, click Close.

Once the Deployment has been completed, you can to run the Production environment Work Portal by using the
Run Process option of the Process Wizard´s step 7 (Execute), in which a published URL will be available:

Click the published environment's label to launch the Work Portal:

Page 146 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Subsequent (incremental) deployments to Production
The concept of subsequent deployments to the Production environment applies to all deployments after the first
one to that same environment.
Options to deploy a Release Candidate as a subsequent deployment to an existing Production environment will
slightly vary from what you saw in the first deployment.

During subsequent deployments, the existing Production servers (as configured in the first deployment) are updated
with the selected Process versions, and no new project is created (so you do not need to provide information
regarding the location of your production servers).
The main differences in a subsequent deployment to Production involve:

· Backups of the current Production environment database are created.

Before Bizagi starts the deployment, it creates a backup and store it at the database's backup path.

For Oracle databases, this path is defined by the Store database backups property set when configuring an Oracle
instance to work with Bizagi.

For SQL Server and in a local setup, this would be at C:\Bizagi\Projects\[your_project]\Backups).

For SQL Server and when using a remote database, this path will usually be C:\Program Files\Microsoft SQL
Server\[MSSQL_instance]\MSSQL\Backup\.

· While you execute a subsequent deployment, there is no direct option to change the current production server or
the database server.
You can move an existing Bizagi server to a new one through the Server Management options in the Management
Console.
If the database server needs to be moved to a different location, this has to be done manually.

Page 147 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Whenever One-Click Deployment is not able to locate your existing production environment's database, it will offers
you the option to specify the location of the current production database location. This is useful if the environment
was moved.

The entered location for the database must correspond to the actual Production database location (Bizagi will
validate that this target database is consistent to the expected environment and current state).

· Existing cases in the Production environment are kept consistently in that environment, and take changes as
defined in the Development version, either through new Process versions or changes in the current Process
version.
For further information about handling Process versions for major and minor changes, refer to Continuous
improvement and development after a deployment.

· There is no option to include users (as an initial load of users from the Development environment).
For further information about subsequent deployments, refer to Continuous improvement and development after a
deployment.

Setting up a Bizagi cluster

Overview
The Management Console is the application in Automation Server whetre you administer production or test
environments (to perform maintenance activities such as managing licenses and clustering in your Production
environment).
To set up clusters in your Production environment through the Management Console, you must have employed
One-Click Deployment for this environment.
The Management Console is installed with Automation Server in order to manage projects in Production
environments, but, is also installed with Bizagi Studio in order to manage projects in the Development and Test
environments.

To open the Management Console, launch it from the shortcut access or from its installation path (by default at C:
\Program Files\BizAgi\BizAgi Studio\MC\BizAgiMC.exe).

Page 148 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Servers Management
Among the administrative tools available in the Management Console is a Server Management module that lets you
manage your Production environment's infrastructure (including setting up a Bizagi cluster if you used the One-Click
Deployment feature).
Management options oriented to the infrastructure let you to configure a Bizagi server cluster, add or remove any
number of nodes, or move your server to another location.

Your production environment will have a main node (initially listed among the Servers), referred to as the Master
Node.

Page 149 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Before you start
By default, Bizagi relies on the load balancing capabilities of the operating system (such as Network Load Balancing
for Windows Servers), but using a specific Hardware Load balancer such as f5 is also supported and recommended
for mission-critical applications.

To set a cluster in Bizagi, you need to:

1. Carry out the steps described in this section, using the Management Console.
Through this step you define in Bizagi which nodes are part of the cluster, and allow them to share an active license.

2. Make sure you have a load balancer and configure it to consider the nodes of the cluster.
Through this step you configure the load balancing for your nodes.
This step varies according to the Load balancer employed (this section will not get into this detail).

Prerequisites
To carry out any options described in the sections belowin the Management Console, make sure:

1. You have an authorized account for both the current and target servers involved in the procedure.
This means having an account which belongs to both the Bizagi and Administrators groups in the current and
target servers.

Page 150 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. Moving licenses can be involved in some of the procedures below.
You should have at hand information related to your licenses to make sure they are correct (applies when moving a
production server).

Additional considerations when involving licenses are:

· The new server must not already have an existing Bizagi license.
· The server where the operation is performed must have Internet connectivity (access to www.bizagi.com).
· The new server must comply with Bizagi technical requirements for a production environment.

3. Set your documents upload path properly.

If you are setting up a cluster, you make sure that your Bizagi upload path (where attached documents are stored) is
set in a shared file server (if you are not using ECM integration).
All your nodes need to access a single repository of uploaded documents (with proper access rights for the identity
starting up Bizagi services).

Page 151 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
If you are moving a server, make sure that this path is accessible from the new server, and that this folder is the one
with the documents previously uploaded.

Clustering options
For Bizagi projects with an expectation of a large number of concurrent users, and a high volume of requests in the
Work Portal, Bizagi lets you configure a clustered environment.
This is a scaled-out measure which improves both availability and reliability for the complete system, while letting
you set up any number of additional nodes in the cluster for load balancing and performance purposes.

The Server Management option is visible only for production environments through the Management Console.
This module presents clustering options, some of which are available only if the current production environment
was set up with the One-Click Deployment (in .NET platform projects).

For other scenarios (those using Advanced deployment), you can set up a clustered environment through another
procedure, not with the assisted Management Console options.

Bizagi automatically manage your active licenses.

To configure a cluster, you register additional nodes, while considering these ponts:

Page 152 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
1. You have done a deployment to a production environment.
This means the target production server is already marked as the Master Node.
To view more information about a performing Bizagi deployments, refer to Deploying your Processes.

2. Add servers as nodes to the current production configuration.

Doing this per each cluster node is required.

At any time, you may also choose to remove a registered node in the clustered configuration.

Adding a Server
To add a new server, first make sure you have installed Automation Server in a machine which has network access to
both the server that will be added as a cluster node, and the Master Node.

You need to have installed Automation Server with the matching Bizagi version under which your production
environment is running.

Open the Bizagi Management Console and select Open Existing Project in the Welcome to Bizagi window.
Select the local server from the first drop-down list, and then select the project's name in the second drop-down
list.
Click Finish to open the project.

For each node you want to add to the cluster configuration, follow these steps:

Page 153 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
1. Use the Add New Server option.
Click the Add New Server button in the Servers Management module. You can also do this by right-clicking the
Servers item and selecting the Add New Server option..

A window displays the list of available servers in the network that have Bizagi installed.

2. Define the location of your additional server.

Select the new server to be included as a node in the cluster and click Next.
It may be possible that a server that can be accessed does not appear on the list.
If this is the case, select Click to type a new server, and enter the server's name.

Inputting an IP address instead of a server name is supported, but make sure that the IP addresses is not
dynamic.
IP addresses for servers involved in the configuration of a cluster must remain static and not change.

Page 154 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
To register a new server, you must have an authorized account which is member of the Bizagi and Administrators
groups at that server (as described in the Prerequisites section).

Acknowledge and agree to the concepts involved in adding a server.

Page 155 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
3. Specify if you wish to have an additional Scheduler service in the added node.
This is optional: you may choose to load balance the workload for your project's Scheduler if your Processes use a
lot of background tasks such as jobs, batch processing, or other offline-scheduled tasks which can take a long time
to execute.
We recommend you to install the Scheduler service to avoid single points of failure in your clustered environment.
When installing an additional Scheduler service you need to follow the configuration described at Multiple Scheduler
services configuration.

Background tasks performed by the Scheduler mainly include executions for Asynchronous Activities, Replication
synchronization, Custom Jobs, and LDAP synchronization.

Page 156 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Next to continue.

4. Confirm your configuration

Finally, you will be shown with the summary of the Add New Server completion ("The Finally, you see a summary of
the Add New Server completion ("The operation was completed successfully"). If any error occurred during the
procedure, error message details appear.

Page 157 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Finish to close the window.
A refreshed list of the registered servers (the Master Node, and any additional ones) appears.

Removing a server

Page 158 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This option lets you to unregister a node server from the cluster configuration.
This is a useful option:
1. To stop using a server as a load-balanced node.
2. To move a server to a new location. In this case, you would need to use this option, move the server and then
register the server at its new location, using the Add New Server option as specified in the previous section.

To move your main server (Master Node) to a new location, use the Moving a Master Node option.
This option works similarly to the Moving a Server option described below.

Before removing a registered server from your cluster configuration, make sure you have installed Automation
Server on a machine which has network access to both: the server that will be removed, and the Master Node.
You need to install Automation Server with the matching Bizagi version under which your production environment
is running.

Open the Bizagi Management Console and select Open Existing Project from the Welcome to Bizagi window.
Select the local server from the first drop-down list, and the project's name in the second drop-down list.
Click Finish to open the project.

For each node you want to remove from your cluster configuration, follow these steps:

1. Use the Remove Server option.

In the Server Management module, right-click the server you want to remove and choose the Remove Server
option.

Page 159 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You can also do this by selecting Servers and then clicking the corresponding button on the ribbon.
Notice that this option deletes a Work Portal or Scheduler in a node. Therefore, if you want to remove both
components (the Work Portal and the Scheduler), you need to do this for each component.

2. Double check you are doing what you intend, and confirm.
Confirm this action to remove the chosen node.

This option will not delete files from the server.

Therefore, if this server is no longer part of the cluster, note that it will still have local files and prior configuration
for the project.

Moving a Server (or Moving a Master Node)

This option allows you to move your current production environment to a new server.
Bizagi automatically creates your project's environment Work Portal and Scheduler in a different server, along with
your activated license.

This option will not move your project's database.

If you need to move your database to a new Database Server, to do this manually using a backup and restore
approach.
To view more information about Moving a database, refer to the following sections, according to your project's
Database engine: SQL Server's backup and restore, or Oracle's Export and Import.

When you have a Bizagi cluster, this option is referred to as Move Master Node.
We recommend that you perform this procedure during non-working hours, because the services of the current
environment are temporarily stopped.
To move your production environment to a new server, perform the following steps:

1. Install Automation Server on a machine having network access.

Page 160 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Install Automation Server on a machine which has network access to the involved servers (both to the current
production server and the new server to which this environment will be moved).
If you are using a cluster, this would include access to the current cluster nodes.

You need to install a version of the Automation Server that matches the Bizagi version under which your
production environment is running.

2. Open the project from the Management Console.

Open the Bizagi Management Console in the recently installed machine. In the Welcome to Bizagi window, select
Open Existing Project.

Select the project's current server from the first drop-down list. This displays the existing projects in that server, in
the second drop-down list.
Select the project's name in the second drop-down list, and click Finish to open the project.

3. Use the Move Server option.

When the project is open, go to the Server Management module. Click the Move Server button, or right-click
directly in the Servers item and choose this option.

Page 161 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This procedure also moves your current production's activated license, and therefore Bizagi will show you the
current activated license for the new server.

Click Next to continue.

In the next window, Bizagi reminds you to move the license information as well.

Page 162 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Select the I Agree checkbox and click Next.

4. Select the target server.

Select the target server from the list of available servers in the network having Bizagi installed.
Select the new server and click Next (similarly to the configuration presented when performing a first deployment).

It may be possible that even though the new server can be accessed, it does not appear under this list.
If this is the case, select the Click to type a new server, and enter the server's name.

Providing an IP address instead of a server name is supported, but make sure that the IP address is not dynamic.
IP addresses for servers involved in the configuration of a deployment must not change.

Page 163 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Remember that you need to have an authorized account which is a member of the Bizagi and Administrators
groups at the target server (as described in the Prerequisites section).

Once the procedure has finished: the activated license, the Work Portal, the Scheduler service, and the attachments
of existing cases (files at the file server), will be removed from the original server.
They will be moved into the new server.
A summary of the license information is shown in the last window.

Close the summary by clicking Close.

Notifications using case links

When setting up a cluster or modifying your system's entry point for high availability (the load balancer's URL),
consider the following configuration aspect for your process notifications.

To use case links from within e-mail notifications (hyperlinks that directly take end users to a given case's activity),
make sure you specify your system's entry URL (corresponding to your load balancer).

Page 164 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
To do this, edit the configuration files of all the Bizagi Work portal instances of your cluster, and the Scheduler
services in your project so that each can build the appropriate URL.
By default, each Work portal instance in Bizagi (or Scheduler service) will use its local URL instead of going through
a load balancer.

To edit this configuration, modify each Work portal's web.config file (located by default at C:
\Bizagi\Projects\[your_project]\WebApplication\) and each Scheduler's BizAgi.Scheduler.Services.exe.config file
(located by default at C:\Bizagi\Projects\[your_project]\Scheduler\).

When editing each file, include the following lines inside of the <appSettings> element:
<add key="SERVER_NAME" value="YOUR_VALUE_HERE"/>
<add key="APP_NAME" value="YOUR_VALUE_HERE"/>
<add key="PROTOCOL" value="HTTPS"/>

Consider setting the value for Protocol as HTTPS, instead of HTTP, only when using SSL over HTTPS.
For value in SERVER_NAME, specify the load balancer's virtual name (or IP address), and for the value in
APP_NAME specify the load balancer's virtual web site.

In the end, confirm that your case links will be built as:
[PROTOCOL]://[SERVER_NAME]/[APP_NAME]/[FURTHER_CASE_LINK_PARAMETERS]

When using a high availability Bizagi solution, it is also important to make sure that the UDP port number 11000 is
allowed in all nodes of your cluster.
This UDP port is involved in the cache communication and synchronization used by Bizagi's components.

Advanced Deployment

Overview
Bizagi presents an Advanced Deployment as an alternative to the One-click Deployment in Bizagi Studio, to perform
Deployments of Processes in specific scenarios having sophisticated requirements.
For more information about the One-click Deployment which assists this process (automatically deploying process
packages in an online manner), refer to Deploying your processes.

When to use the Advanced Deployment?

Deployments of Processes is done once the automation stage is completed and when you wish to publish your
processes into a Test or Production environment.
The Advanced Deployment will offer further possibilities for the following specific scenarios:

1. Projects requiring an Offline Deployment.

Page 165 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Offline Deployment is needed when there is no network connectivity between the development environment (where
the Studio is) and the final production environment (i.e, located in the cloud, a data center on a different network,
etc).

2. Projects having automation of processes in a parallel schedule.

Applies for large scale projects in which a large number of users are working in a collaborative environment, and
some processes are ready to go live, but others are still being automated.
In that case, you may choose to use the Advanced Deployment if you want to quickly publish those ready processes
without holding the progress of the other processes (in other words, you can publish processes while others are
being worked on).

3. Projects with more than the 3 default environments.

Some mission-critical processes or some corporate policies may demand the use of additional environments to
those 3 default ones presented in the One-click Deployment in Bizagi.
The One-click Deployment will consider its main Development environment, alongside a Test and Production
environment.
When using additional environments such as a Staging or Production replica environment, you will need to use the
Advanced Deployment.

4. Projects in which you want to keep certain previous information

The Advanced Deployment offers a more flexible procedure than the traditional deployment, mainly because it
enables revision and modification of each change in the Development environment which will be published into the
Test or Production environment.
This comes in handy for advanced users which are certain of changes they don't want to publish.
In this way, all of the objects in Bizagi (Entities, rules, forms, etc) from one or more processes, can be explicitly
selected or unselected (to disregard them) for the deployment to the target environment.
This includes the possibility of preserving cases in the Test environment as well.

How does the Advanced Deployment work?

Briefly, the Advanced Deployment will allow you to select the Processes and Sub-Processes (their versions) which will
be published to Test or Production, through a set of 4 executable files. This procedure ensures that the metadata
from the development environment gets deployed into the target environment. This means that the Advanced
Deployment sets up your target environment with everything it needs to execute your application, but it does not
introduce any data into that environment.

You can optionally:

· Include objects which are not necessarily attached to the selected Processes, in order to force-include them in the
deployment.
· Exclude objects which you do not want to deploy because your are certain you don't want/need them in your
production environment.

This information is exported into a Deployment package file (in Bizagi, this file will be using the .bex extension).

The .bex file is taken to the Production server, and this file becomes an input to analyze and preview the importing
actions (those carried when publishing into an existing Test or Production environment), in order to make sure that
the objects will be taken as planned.
The analysis in this point, launches a comparison against the target environment involved in the Deployment
applying.

In order to move data from one environment to another, Bizagi features the Export and Import data procedures
that can be launched from the management console. For more information regarding the deployment of data refer
to Data Synchronization.

Important
Before you continue, make sure you acknowledge the following considerations.

Page 166 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
1. Initial deployment through the One-click Deployment recommended
When running your Processes in a .NET platform, it is recommended to perform an initial deployment (the first
deployment) through the One-click Deployment.
This will assist the creation of the target environment (Work portal, database and Scheduler service) and allow
Bizagi to validate objects which should not be deleted or modified from that point on, in the Development
environment.
If using the One-click Deployment for this purpose is not suitable, then you will need to create the initial database
with Bizagi's blank model through the Advanced Deployment executable files.

2. Once through Advanced Deployment, there's no turning back.

It is OK, if you choose to switch to the Advanced Deployment if you had already used the One-click Deployment (but
not vice versa).
This means that once you choose to use the Advanced Deployment to perform your Deployments, it will not be
possible to go back and attempt to use the traditional One-click Deployment available in Bizagi Studio.

In other words, for any project which has already used the Advanced Deployment, any Deployments will need to be
done using the same Advanced Deployment.

3. Always create backups.

The Advanced Deployment does not create backups of any database.
Remember that as a contingency measure, it is always recommended to take backups of all your existing
environments before doing major changes to any environment. Major changes include a Deployment by either the
advanced or traditional One-click procedure.

This means that when using the Advanced Deployment, a backup snapshot of your target environment (Test or
Production) should always be taken at least before applying any Import files.

4. Do not delete objects in development unless unused in production

It is really important that you acknowledge the following: when using the Advanced Deployment, Bizagi Studio won't
be performing any validations for dependencies. This means being able to tell if an object has been already
deployed to Production.
Due to this, it is strictly required that objects in the Development environment are not deleted (when being used in
Production already), and that you always create new versions of Processes whenever you need to perform
adjustments over Processes.

5. Plan and coordinate your deployment

Similarly to the One-click Deployment, it is recommended to schedule and perform the Advanced Deployment at
non-working hours.
This also promotes any contingency measure towards restoring a backup (previous snapshot of the solution),
should the Deployment results not be as expected.

6. Consider additional environments if needed

When Processes instances are critical, and depending on the nature of the changes incoming from Development (i.e
it is strictly needed to test existing instances), you may choose to use an alternative environment (Staging or
Production Replica), used to perform rigorous testing and user acceptance tests, especially focused on the existing
Production cases (live Process instances).
This means that beforehand, you should create a temporary environment for the sole purpose of testing the final
Deployment into Production.
By doing this, and through a backup and restore approach, you would have a way to review if any changes or
additional information are required for the Deployment.
When using such environment, make sure that the SMTP Server, any configured interfaces, ECMs or data providers,
the set e-mails for your users or any other setting, does not trigger your actual Production settings.

Page 167 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Required profile
The profile of the user working with the Advanced Deployment needs to:
1. Have a basic understanding of XML structure (in order to configure the config files).
2. Have access to the project environments' Databases (with the superuser credentials).
3. Have expertise or important know-how, about the concepts involved in a Deployment of a project in Bizagi.
For more information about the treatment for deploying objects in Bizagi, refer to deployed objects.
4. Have an understanding of the implemented Processes in the project.
This means knowing about these processes' purposes, data model, versions, integrations, security settings,
environment settings management (i.e policy, alarms, parameter entity values), and general workings.

Take into account that for proper testing (carrying our user acceptance tests), this will include being able to tell
which is the expected behavior of the Processes in the Work Portal (under the different business scenarios).

Performing an Advanced Deployment

There are several ways to conduct the Advanced Deployment procedure:

· By relying on the dedicated user interface.

Bizagi comes out of the box with a set of tools to deploy a project. Those tools are specific programs that guide
you step by step through a user interface where you provide all the required information and options to tailor your
deployment.
For detailed information on how to deploy a project by relying on the user interface refer to Advanced Deployment
executables.
· By using the Command Line utilities.
Bizagi provides a set of Command Line tools to fully deploy a project from a command prompt. This is especially
useful if you don't have access to the machine hosting the target environment and you will remotely perform a
deployment, and this also allows the creation of scripts to automate your deployment workflow.
For detailed information about deploying your projects through the Command Line deployment, refer to Command
Line for Advanced Deployment.

Advanced Deployment executables

Overview
This article explains the set of executable files or utilities that are needed to perform an Advanced Deployment by
using the user interface dedicated to it.
The general outline of steps required is:
1. Use the CreateDatabase utility to create an empty database in the target environment.
2. Create a .bex file with the Export utility.
3. Import the previously exported .bex file into the target environment by using the CreateImport environment.

Optionally, if you need to update specific elements in your processes, use the Microdeployment utility. For more
information, refer to Microdeployment.

Advanced Deployment executable files

The Advanced Deployment consists of an Export tool that helps you create a Deployment Package, and it also
includes two executable files, each having its own configuration file, that are meant to be executed in the target
environment. Furthermore, an additional tool to deploy specific components.
These executable files come in by default installed where the Management Console is installed (at C:\Program
Files\Bizagi\Bizagi Studio\MC\).

Page 168 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The purpose of each executable file and where it should be used is described in the following table (the file is
located having this same name with the .exe file extension).

Executable Purpose Where should it be used?

CreateDatabase.exe Creates a blank database of Bizagi's On a machine with access to the

model, just like a database is Production environment's database
created initially when you create a server.
project through Bizagi Studio or the
Management Console options.
It is especially needed because the
Advanced Deployment does not
create that blank database, but
parts from an existing one to apply
project-specific objects (entities,
forms, rules, etc).

CreateImport.exe Applies the changes into your On a machine with access to the
Production environment. This is Production environment's database
done after analysis of the .bex server.
export file against the Production
environment, and considering how
any existing information should be
handled (i.e merge of records).

Export.exe Creates a .bex export file where you

will have a package of objects from On a machine with access to the
your Development environment of Development environment's
selected process versions. database.

Page 169 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 MicroDeployment.exe Creates a .bex export file where you
will have a package of updated It can be accessed directly in the
objects from your Development seventh step of Studio's Process
environment. For more information, Wizard.
refer to Microdeployment.

Configuration files
Configuration files for the two mentioned executable files have the same name to their corresponding file, though
they have .config as their extension.
Such configuration files are XML-formatted, and would be accordingly:
· CreateDatabase.exe.config for CreateDatabase.exe
· CreateImport.exe config for CreateImport.exe
· Export.exe config for Export.exe
· MicroDeployment.exe config for MicroDeployment.exe

All configuration files have the following structure and required configuration in which three main keys are found
inside of the <appSettings> element:
· ProofConcept_Utility: Contains the name of the executable file without its extension.
· DSNDB: Contains the connection string to the database that the executable connects to. For the
CreateDatabase.exe, this connection represents the database that will be created.
· PROVIDERTYPE: Contains the specific data provider to be used for the above connection (SQL Server or Oracle).

To configure the executable, you need to make sure that you specify the connection and provider as described
below.

When using SQL Server:

<add key="DSNDB" value="Persist Security Info=True;User
ID=[SQL_Login];Password=[Login_password];Data Source=[DB_Server]
\[Named_instance];Initial Catalog=[Database];" />
<add key="PROVIDERTYPE" value="MSSqlClient" />
Consider:
· [SQL_Login]: The login account used to connect to that SQL Server database instance.
· [Login_password]: The encrypted password for the above login.
· [DB_Server]: Name or IP address of the database server. Use \[Named_instance] when applies, if your database
instance is not the unnamed default one.
· [Database]: The name of the project environment's database. Recall that specifically for the CreateDatabase, this
database you specify is the one that will be created.

Page 170 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 When configuring the executable, the SQL Server login used will require sysadmin rights.

When using Oracle:

<add key="DSNDB" value="Data Source=[DB_Server]:[Port_number]/[Service];User
ID=[User_schema];Password=[User_schema_password];Unicode=True;" />
<add key="PROVIDERTYPE" value="Oracle" />
Consider:
· [DB_Server]: Name or IP address of the database server.
· [Port_number]: The TCP port used for the connection to the database service.
· [Service]: The service identification for an Oracle instance.
· [User_schema]: The name of the project environment's database. Recall that specifically for the CreateDatabase,
this database you specify is the one that will be created.
· [User_schema_password]: The encrypted password for that user schema.

As mentioned above, the password of the database must be encrypted to protect it in case of unauthorized access
to the configuration files. Follow this procedure to encrypt the password:

1. In the Work Portal of your development environment, click on Admin and then Password Encryption.

This will display a window in which, you can cipher any text you want.

2. Type the string to cipher in the Encryption Text field and confirm in the field below. This will make sure that the
text entered for the first time is correct. If both fields do not match, the password will not be ciphered.
Finally, click Encrypt,

Page 171 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
3. The Ciphetext field will display the password encrypted. Copy this string and paste it in the according property
according to your Database engine.

CreateDatabase.exe
You will need it to create a blank database of Bizagi's model, only the very first time when you actually create the
target environment's database.
Otherwise, for incremental deployments, you do not need to use it since you will be deploying changes and new
process versions over an existing database.

Recall that for projects running in a .NET platform, you may consider using the One-click Deployment for the very
first deployment.
If you do use the One-click Deployment for the initial deployment, then you may skip the CreateDatabase.exe use.

Keep in mind regarding the new database you want to create:

· If you are using SQL Server, then your instance should have an explicit predefined TCP/IP port.
For more information about SQL Server requirements and configuration, refer to SQL Server Configuration.

Page 172 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 · If you are using Oracle, you need to have previously created the BizagiAdmon user and consider that the
password you set for your new Database, must be the same one used by the BizagiAdmon user.
For more information about Oracle requirements and preconfiguration, refer to Creating a project using Oracle.

To use CreateDatabase.exe, first make sure you have copied the whole MC folder in a local path of a machine that
has network access to your Production environment database (the MC folder contains the executable files and the
dlls needed).
Then:
1. Edit the CreateDatabase.exe.config file so that you specify the connection details of the database you want to
create.
2. Execute CreateDatabase.exe.
You will see its user interface present the following:
· Target: Shows the database and its database server, to which the executable was configured.

Bear in mind that the unicode settings of your development database will be copied to your production
environment.

3. Create the database.

For this, use either of the 2 create options.
· Create Bizagi Test database: Click this link to start with the creation of the blank Bizagi model database.
Through this option, this database will be automatically marked as a Test database.
· Create Bizagi Production database: Click this link to start with the creation of the blank Bizagi model database.
Through this option, this database will be automatically marked as a Production database.

Once you confirm this action, the database creation will show its current progress:

Page 173 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Once you are notified it has been finished, you may close the executable.

Export.exe
Use this tool to generate the initial package of objects you want to deploy from your Development environment.
This step of the Advanced Deployment is done in the Development environment.

What you need to do

Before you start, make sure your processes are ready and that they don't need additional changes to be deployed.
To use Export.exe, edit the Export.exe.config file so that you specify the connection details of your Development
environment database.
This is step is also located in the seventh step of the Process Wizard, clicking the Export Process option.

Page 174 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You can also select the Advanced option located in the Deployment section of the Export/Import menu.

A window appears with the Advanced deployment wizard.

Page 175 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You will see its user interface present the following:
· Database: Shows the database and its database server, to which the executable was configured.
· Processes Tab: Displays all processes and their versions. You should select those you want to include. When you
right click a process version and select Define process dependencies a window appears where you can select the
dependencies you want to force-include in your deployment. Keep in mind that only the selected processes are
deployed, those which are not selected are not deployed even when they are related with other selected objects.
Select the Entities, Query forms or Business Rules that you want to relate from the list. When a selected entity
does not have attributes, it will not be included in the deployment.

Page 176 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Experience tab: Select the experience components you want to deploy. Keep in mind that experience elements
are highly uncoupled and can be deployed without considering their necessary relation or component to work
properly. For more information refer to Relate Objects.

Page 177 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Advanced tab: Select the objects you wish to include in the deployment. Among these objects you can select the
themes you've made with the Theme Builder, Environment parameters, authentication options and user properties.

Page 178 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 · When you choose to include environment parameters make sure that these parameter values, such as the SMTP
server and interfaces URL, correspond to their environment configuration. When you deploy the package with
these settings the target environment's parameters will be overwritten.
· If you check the Authentication options, the authentication configured in the target environment will be
overridden. Do not use this option unless you are sure to change the authentication options with the
configuration of your source environment.

· Description tab: Add the information you consider relevant for this package such as the included processes, their
versions, entities and other relevant changes.

Page 179 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click on the Export button.
This generates the package with your selected objects and process versions and save it as a local .bex file. A
window appears informing that the export was successful and it shows a summary of your export file.

Page 180 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You can check the contents of the export package by clicking the View Package button.

Page 181 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 When a parameter entity managed in production is considered in the deployment package, all of its attributes
and relations are included, even unused ones.

CreateImport.exe
Use this executable to review and apply the package you created through Export.
In the revision carried out at this point you will consider if the package will be applied in your Production
environment by evaluating for the last time the information to be applied.
At the end of the revision, you will be able to apply the file selected, which is the final package for your Production
environment.

To use CreateImport.exe, first make sure you have already copied the whole MC folder in a local path of a machine
that has network access to your Production environment database. Know that the MC folder contains all three
executable files and the .dll files needed.
Edit the CreateImport.exe.config file so that you specify the connection details of your Production environment
database.
Execute CreateImport.exe.

Page 182 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 We strongly recommend that you select the Enable metadata validation option. This validation detects two of
the most common errors that occur during a deployment:
· References to objects that don't exist in the catalog: When a deployed object has a reference to an object
that doesn't exist in the package or in the target database this validation is triggered.
· Processes without an associated version: When objects like rules or experience elements don't have an
associated process version, this validation error is triggered. If this happens, you must review your deployment
configuration and make sure you selected an associated version for these objects.
These validations are important because they reduce errors in the Production environment substantially.

A window appears with the import wizard, which presents the following:
· Target Database: Shows the database and its database server, to which the executable was configured.
· Backup Database: Create a snapshot of your target database.
· Specify the file you want to import: Use the Browse button to load the .bex file created with Export.exe. The path
to the file appears in this field.
· Package information: This section shows the author (user), project, source database and the export date of the
package to import.
· You may use View process objects to import, or the View export advanced options option to review the
information that is included in the package as from the Export options to review what was exported.
o View process objects to import: view all objects that contain process information that will be published into the
Production environment.

Page 183 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 o View export advanced options: view all the advanced options that will be published and updated into the
Production environment.
o View description: view the .bex file export summary, written by the user who generated the file.

Review what will be deployed using the View process objects to import, View export advanced options and View
description options. You can check the objects that will be included in the deployment:

Page 184 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Page 185 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 If you check the Authentication options, the authentication configured in the target environment will be
overridden. Do not use this option unless you are sure to change the authentication options with the
configuration of your source environment.

Click on Apply package. This option deploys the package by running scripts in the target database, and therefore it
is important you take proper measures at this point.

Page 186 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This procedure may take a few minutes and it is important that you are aware that it will run scripts at the database.
Once it is done, it will notify the success:

Page 187 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 This process generates a log in the folder where you ran the CreateImport.exe. This log will let you easily identify
the cause of an error or if the process was executed successfully. Its name will be logImport[TimeStamp].txt
where the timestamp will follow this format YYYYMMDD hh_mm_ss.

· If the import is successful the log will look like this:

3/01/2019 3:06:43 PM: Workspace is valid!
3/01/2019 3:07:11 PM: Adapter execution
3/01/2019 3:08:35 PM: Import catalog end
· If instead the process had an execution error your log will look like this
2/21/2019 11:05:04 AM: Exception on Import: Package version is not supported by
this version of bizagi: 11.1.0
2/21/2019 11:05:08 AM: [{"type":"IncompatibleVersion","Message":"Package
version is not supported by this version of bizagi: 11.1.0"}]

The first line of the log will show you what kind of error Bizagi found in trying to import your process. On the
second line you can find more information regarding the error. Keep in mind that the log will vary depending on
the error.

Database Snapshot
In the Advanced Deployment, you import the BEX file using the createImport.exe executable. Bizagi offers an option
to generate a snapshot of the target database, which you can revert easily if there is an external issue affecting the

Page 188 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
database in the deployment procedure and you want to return to its initial state previous the deployment. Reverting
a database is faster than restoring a backup, which makes the deployment efficient.

When you open the createImport.exe, you can click the Backup database link. This automatically generates a
snapshot in the database.

The snapshot name is the name of the source database with a time stamp as follows: [Database_name]
_yyyyMMMdd_HHmmss.

Page 189 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The snapshot is always stored in the same source database's instance, and is a read-only file:

Database snapshot is available for the following SQL instances versions:

SQL Instance Enterprise Standard Web Express

version

SQL 2017

SQL 2016 SP1

SQL 2016 - - -

SQL 2014 - - -

SQL 2012 - - -

SQL 2008 R2 - - -

Snapshot Considerations
Please bear in mind the following recommendations:
· If a snapshot exists you cannot delete or restore your database. You must delete the snapshot first.
· Do not leave snapshots permanently. They must be used to revert rapidly the database to an original state if
needed. After used it is recommended to clean all your snapshots.
· A snapshot do not replace backups. Please keep all your backup schema.

We recommend looking at snapshot considerations in the following link.

MicroDeployment.exe
Use this tool to generate the package of specific objects you want to deploy from your Development environment.
This step is done in the Development environment.

What you need to do

To use MicroDeployment.exe, edit the MicroDeployment.exe.config file so that you specify the connection details of
your Development environment database.
This is step is also located in the seventh step of the Process Wizard and click theMicrodeployment option.

Page 190 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You can also select the Advanced option located in the Deployment section of the Export/Import menu.

A window appears with the Microdeployment wizard.

Page 191 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
For more information, refer to Microdeployment.

What is next?
Once you have completed your process deployment through the Advanced Deployment, we recommend you clean
up the server's cache before announcing that the deployment procedure is completed.

When running your processes in an IIS, after performing an advanced deployment you should clear the cache of
your Work portal and database.
In order to do this, invoke the following Bizagi web services as available in every project:
· Render cache as stored in the database: http://[your_server][your_project]/webservices/cache.asmx?
op=CleanRenderCache
· Application cache: http://[your_server][your_project]/webservices/cache.asmx?op=CleanUpCache

Note that you should restart your IIS services.

The deployment procedure only considers metadata, meaning that if you want to preserve the User's data and
values of parameter entities managed in production from your development environment in the target
environment, you must do a Data Synchronization.

Package Visualizer

Overview
When a project runs in a production environment and multiple deployments have been made, it is important to
review and analyze the new packages to make sure that the package to deploy is correct. It is also important to
check what is going to be deployed before generating the file, that is, whether you want to deploy a project for the
first time, perform a deployment for improvement of a project or explore a deployment package.
Bizagi knows this and provides an interface called Package Visualizer. Through this section, we describe how it can
be used, the information it provides, and some other important details.

Page 192 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
When can you use it?
The Package Visualizer is useful when you are going to create or import a .bex file. The following is the list of
contexts where this feature can be used:

· One click deployment: in the last step of a deployment process, you see the View exported objects button. When
you click it, the Package Visualizer shows the objects that will be deployed to the selected environment.

· Importing a .bex file using the Management Console: in Management Console, it is available an option to
explore the .bex file in the file menu in the main ribbon. When you click it, the Package Visualizer shows the
objects in the .bex file when the deployment was generated.

· Importing a .bex file using the Bizagi Studio: is available an option to explore the .bex file in the file menu in the
main ribbon to visualize a .bex file.

Page 193 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
How to use it
The Package Visualizer lets you graphically explore and analyze all the components and objects taken into account
in a deployment. However, it does not let you change, add or delete any information, components and objects. In
this part of the article, we describe the details of the features which are available when launching the Package
Visualizer either from any of the three options mentioned before.

There are four components in the visualizer:

1. Tree View

Page 194 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The Tree View is a hierarchical representation of the objects. It is presented on the left panel of the Package
Visualizer and splits the deployment's objects into three main groups: Application (Business Processes), Entities
and Global. The Bizagi structure is not completely represented in the tree since it would be too big, only a
prioritized group of Bizagi's elements is shown. Such group considers:

· Application
o Application
o Processes
o Process Version
o Business Rule
· Entity
o Entity (And subtypes)
o Attribute
o Values of entities
o Relevant
o Stakeholder Context
o Collections | My Stuff
o Stakeholder Actions
o My search
· Global
o Holidays
o User Properties
o User Groups
o Document Templates
o Emails
· Other

Page 195 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 o System Entities

2. Context view

The Context View shows the members of the selected node in the Tree View. When a selected node has
subcategories, the Context View shows tables containing the information of the elements of every subcategory. In
this table, you can see the name of the object, the last person who modified it, and the last modification date.

When you select a node from the Tree View, the Context View shows the context path in the title and several tables
with the objects of the node grouped by the type of element. Each element in the table shows its name, the last
person who modified and the date of the last modification for each attribute.

Page 196 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Objects not included in the package
You can activate a feature to compare the bex package with your development environment, and identify the objects
that are not included in the package. This feature lets you identify a particular element of your project, that must be
included in a deployment package. It is very important to understand that this is comparison between the package
generated, and the development environment, therefore, depending on the size of your development database, it
takes some time to fetch all the information.

To get the objects not included in the package, activate the switch located at the top-right corner of the Package
Visualizer:

This feature is only available when you have a connection with the Development environment database. If you are
using the Package Visualizer in the createImport.exe of the advanced deployment, or with microdeployments, this
option is not displayed.

Page 197 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 If you are visualizing the bex file from the Management Console, the bex must belong to the same project you
are opening in the console, and you must open the development environment.

Bizagi loads up all the information of from the development environment. Now you can see the objects that are not
included in grey color, as a disabled-like appearance:

Global objects
When you do not include global objects in the package, and you activate the Objects not included in package,
Global elements are show in four categories:

Rules: Global business rules defined from the Expert view.

Holdiays: Holidays schemas created in the Organization module.
User Groups: User Groups created in the Organization module.
Emails: Notifications configured in Business configuration.

3. Search View

Page 198 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
When you move to the Search tab, a search bar appears so you can input object names or query for people (those
who modified the objects).

The following image shows a search performed by object name:

The following image shows the search results of a person's name query:

The search results are grouped by the type of object, and can be collapsed or sorted (on an ascending or
descending fashion) by any of the columns. To collapse a group, click the icon shown next to the group's title. To
sort a table by a column, click the column's name to cycle between ascending, descending.

4. Dependency Viewer

Page 199 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
When you select a node from the Tree View, you can click the element name to display the dependency viewer. The
dependency viewer lets you identify the elements involved in the deployment package and the relation between
them.

Once you select the element, the Dependencies view shows you a map with the information of the elements which
have a relation with the selected element.

An element can be used by several objects in the deployment packages and can have several dependencies. To
change the object where the dependencies are analyzed, select the object from the drop-down list displayed at the
top of the view.

Page 200 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Hover the mouse pointer over any of the elements of the map to show its name.

You have the following options available when using the dependency viewer.

Icon Name Description

Left to right Shows the map oriented from left to right. This is the default view

Top to bottom Shows the map oriented from top to bottom

Auto zoom Shows the map with a 100% zoom

Fit to view Fits the map to the current view size

Important considerations
· With the package visualizer you can explore .bex files generated using a version of Bizagi higher than or equal to
11.0.
· Some of the files generated in Bizagi 11.0 may show an error when trying to visualize it. This error may also occur
when the .bex file has problems with its metadata.

Page 201 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Advanced deployment: In Export, you see the View Package button in the successful export notification window.
When you click it, the Package Visualizer shows the objects that will be deployed to the selected environment.

It is not available a Save option since the .bex file is not editable when you navigate the objects to be deployed
using the Package Visualizer.

Data Synchronization

Overview
Up until this point, the Deployment procedure has only considered metadata. This means that your target
environment now hosts "the shell" of your project, that is, all of the imported processes and parameter entities. If
you have data on your development environment that you wish to preserve in your target environment, then you
need to perform a Data Synchronization.

How to perform a Data Synchronization procedure?

Page 202 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The Data Synchronization consists of two utilities that are launched from the Management Console: Export data and
Import data. The first step is to generate a .bdex file which is the result of the Export data procedure performed on
the Source environment. After that, the next step is to import such .bdex file into the target environment by
launching the Import data procedure from the Target environment.

This procedure lets you take data from your development environment into your target environment. The data that
you can select to be included in the procedure is listed below:
· Parameter Values managed in production.
· Users and their relations.
o Areas
o Groups
o Languages
o Locations
o Organizations
o Positions
o Roles
o Skills
o Time Zone
o Working Time Schema

Bear in mind that you can only import data into an environment whose metadata counterpart has already been
deployed. This means that if you have not deployed an entity into an environment, you cannot synchronize its data
into the same environment.

If a parameter entity is selected to be considered in the synchronization process, all of its registers are taken into
account. This means that you cannot individually select which elements to include and even unused values are
included in the .bdex file.

Export data
This utility lets you handpick the data from your development environment to include on the .bdex file.

Launch this tool from the Management Console inside the Configuration tab on the ribbon.

Page 203 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The Export data wizard is displayed.

The wizard guides you through the Export procedure. At the top part of the window you can see at what step of the
procedure you are in. The first step lets you Select the data to export. From the left panel tick the data elements
that you want to include in the .bdex file, and the click Add. Those element are now visible on the right panel, which
means that they will be included in the .bdex file.

Page 204 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Next when you have finished selecting the data to export. Make sure you have ticked all of the elements that
you wish to import since the ones that are not included will not be available in the import procedure.
After clicking Next you have the opportunity to select the user relations that to export.

Page 205 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Once again, tick on the left panel the user relations you want to export and then click Add to make sure they are
included in the right panel. You can always tick the box next to Available data to tick all of the options at once.

Page 206 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
At any time, you can go to the previous step to review what you have included by using the Previous button on the
bottom right part of the window. If you identify an element that has been mistakenly included, to exclude it you only
need to tick it on the right panel and then click Remove.

Page 207 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Page 208 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 When syncing user data from one environment to another one, the passwords are not considered. That is why if
you have your authentication method set to Bizagi your users' credentials are handled as follows:
1. Random passwords are generated for all the synced users.
2. Each user is marked as expired, this way they are prompted to update their password on their first log-in
attempt after the synchronization.
3. The user performing the synchronization decides whether to send an email asking users to change their
passwords. If he decides not to do so, the admin user must change in the Work Portal the passwords of each of
the newly synced users.

Once you are done selecting the Data and User relations to export, click Next to head to the third and last step of
the wizard.

In this window, all the entities included in the first step of the wizard are listed on the left panel (Selected data).
When you click on an entity in the left panel, the wizard will show you the available attributes for you to select the
Entity key. This key is used in the import procedure to compare the existing records on the target environment
against the ones exported from the development environment, which is done to prevent the Data Synchronization
from creating duplicate records.

Page 209 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Select the combination of columns that uniquely identify each record of the entity. Do so for each of the entities
listed on the left panel, and once you are done, click Finish.
On the displayed file explorer, provide a name to the file and select the location where it will be saved to.

Page 210 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Save to generate the corresponding .bdex file. A pop-up alert will inform you if the file was successfully
generated or if an error occurred.

Page 211 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
To apply the newly generated file into your target environment, rely on the Import data procedure. Continue
reading the next section for a step by step guide on how to use it.

Import data
To synchronize data into your target environment, you need to import a .bdex file generated by the Export data
procedure. This procedure needs to be performed in the Management Console of your target environment.
Launch this utility from the Management Console on the Configuration tab. The Import data wizard is displayed.

Page 212 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The top part of the wizard informs you at what step of the procedure you are in. The first step is to select a .bdex
file to import. Click Browse to display a file explorer. Navigate your file system and selected the .bdex file that
contains the data you want to import.

Page 213 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Open the select the file and then click Next to move on to the next step of the import procedure.
The second step of the wizard is displayed.

Page 214 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
In this step, two columns are shown. The one on the right lists all of the data from the selected .bdex file that is
going to be imported into the environment. By ticking each element individually you can Add or Remove data
elements from this column in order to handpick the objects that you want to include in the import procedure.
Once you have moved the elements between the columns according to your needs, click Next to continue to the last
step of the procedure.

Page 215 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This screen has two panels, the one on the left shows the selected elements. You can click on each one of them to
review if there are Warnings or Errors that you may need to resolve or take into account before continuing with the
import procedure. Those messages are shown in the main panel.
For example, you can appreciate in the image above that there is one error related to the Cost Center entity: One
of its registers is already present in the environment by analyzing them with the entity key selected in the export
procedure. For this specific case, the solution is to export a new .bdex file where the entity key is more specific,
namely selecting more columns as the entity key. Another alternative is to go to the previous step of the wizard and
leave that entity unselected on the import. The solution that you may apply depends on your business needs at
the given time. If you try to continue with the procedure without fixing the issue, an pop-up message displays and
prevents you from effectively applying the .bdex file into your environment.

Page 216 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Warning messages are shown in yellow. This type of messages inform you about a possible problematic situation,
and lets you address it by approving (or not) the solution provided by Bizagi. This situation can be evidenced in the
following image. Warning messages, unlike error messages, don't prevent you from continuing with the procedure.

Page 217 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
As soon as you finish reviewing and resolving errors and warnings, click OK to effectively import the data into your
environment. If everything runs smoothly, the following message is displayed.

Page 218 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
At this point you have finished Synchronizing your data from your development environment into your test or
production environment! you can now use those values and information from the Work Portal or from wherever
they are used in.

If you are using Automation Service, our cloud offering, this procedure must be carried out as outlined below:
1. Generate the .bdex file with Export data procedure from your Development Environment.
2. Log into your Automation Service Management Console through your virtual machine and perform the
Import data procedure.

Microdeployment

Overview
Often, there are situations where you need to apply a minor change into a specific part of a project without
affecting the majority of it.
Given that in such situations, you still need to deploy changes, as minor as they can be, you need to make sure that
such deployment doesn't include objects which may alter other parts of your project.

Some examples of those situations are: the need to change some specific texts or labels on forms, change only one
query form, or change one business rule.

For such situations, Bizagi introduces the Microdeployment feature.

Through Microdeployment, as hinted by its name, you can deploy specific, minor changes in your processes.
The image below displays how, for a given process, you can deploy only one specific form (UI).

Page 219 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This article describes the Microdeployment, its prerequisites, considerations, and a step by step guide.

Before you start

There are some important aspects to consider before starting a Microdeployment:

· A Microdeployment, as a procedure, does NOT undergo the same logical steps of a traditional deployment. You
may consider the Microdeployment as a shorter and faster procedure when compared to other deployments.
As such, a thorough Dependency Analysis is NOT performed when exporting a package to an environment.
This means that any metadata included in the exported .bex file, must already exist in the environment where that
.bex will be imported into (e.g. testing or production environment).
In other words, when performing a Microdeployment there is one aspect that you can consider so that it results in a
successful deployment: object references. The following table summarizes the possible outcomes.

Situation Outcome

Objects being deployed only refer to other objects that The Microdeployment succeeds
are already present in the target environment's
metadata

Objects being deployed refer to other objects that are The Microdeployment fails
not present in the target environment's metadata

· To use a Microdeployment, some basic environment rules (as those enforced by a traditional deployment) are
applicable, such as making sure that there is only one valid production environment set for one Bizagi project.

Page 220 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
A Microdeployment is applicable to both on-premises and cloud projects.

What can you include in a Microdeployment?

Not all objects can be included in a Microdeployment due to some of them having complex references.
The following list considers objects which are eligible for a Microdeployment:

· Rules
· Mappings
· Message Templates
· Forms
· Document Templates
· Queries
· Start forms
· Search forms
· Custom columns

Any other type of objects are not available, and so, these are not shown in the Microdeployment wizard.

What you need to do

The following steps provide a high level outline of the actions that you need to follow to successfully carry out a
Microdeployment.

1. Generate a deployment package including only those specific objects you wish to deploy.
2. Import the package in the target environment.

Example
Consider as an example, that an environment has been already set up having the Vehicle Insurance Policy
Underwriting process (as available from our Process Xchange), which is operational in a production environment.
For this example, the Microdeployment targets a cloud environment.

Description
The initial state of this scenario is:
· The Vehicle Insurance Policy Underwriting process' has a first activity called Register Client and Vehicle Data.
· The form (UI) for that Register Client and Vehicle Data looks as shown below.

Page 221 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Your manager pointed out that the Case information group shown in the form is no longer desired.
In other words, you will need to delete this Case information group from the form.
· Assuming you and your team colleagues are currently working in the development environment, while
implementing other unfinished changes, then it becomes clear that you need to perform a Microdeployment, so
that those other changes do not affect operations of your process.

Performing the changes in the development environment

The first thing is actually making the minor changes to the process (as pointed out by your manager).
In the following image you can see how the group is not present anymore and the Policy Owner Information is now
the uppermost element of the IP_CustomerVehicleBasicData form:

First step (Generate a deployment package including only those specific objects you
wish to deploy).

Page 222 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Once changes are implemented, you proceed to generate a .bex file by only considering the form in question.
To do so, go to the seventh step of the wizard and select the Microdeployment option. This option is also available
in the Export/Import tab.

The Microdeployment wizard appears.

Page 223 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The first step of the wizard lets you filter the elements you want to deploy. Select the element types in the left panel
of the wizard and the element's process. Filter the objects you want to export within: Application, Entity, Global (such
as Entity forms) or select all. You can use the Filter field to find the process.
Click Next.

According to your selection, a panel is displayed where all the objects that can be considered in a Microdeployment
are available.
Use the Filter field or navigate the panel to find the modified element and check it to indicate that it is included in
the Microdeployment.

Page 224 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click the Export button and select a directory in your machine where you want the deployment package (.bex file) to
be saved.

Page 225 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Second step (import the package in the target environment).
Head to the management options of your target environment (either the Management portal for cloud
environments or by using the ApplyImport.exe tool for on-premises projects), to import the .bex file.
To do so, click the Import option, select the recently created .bex file, confirm that you want to upload it and wait
for the process to be finished.

You can check that the Microdeployment was successful by checking the form of the first task, making sure that the
Case information group is no longer present. Since the Import did not result in an error you can assume that no
new metadata was introduced by the import within your target environment.

Page 226 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Thus you can rest assured that unfinished/undesired changes were not mistakenly included.

At this point you have successfully carried out a Microdeployment, and your manager's suggestion is now fulfilled!

Important considerations
Consider the following when using a Microdeployment:
· The Microdeployment is only available when using the Advanced Deployment.
The Microdeployment is NOT available for the One-click deployment feature.
· Any object referenced by those ones being deployed must already exist in the metadata of the target
environment, otherwise the Microdeployment procedure will fail.
Those referenced objects are NOT automatically included (because a thorough Dependency Analysis is not
performed).
For this reason, a Microdeployment is eligible for specific objects of a process, only when such process has already
been deployed to that same target environment.
· If you are microdeploying Customize Columns, make sure that the variables or vocabularies, are previously
deployed so its metadata exists in the target environment.
· In Automation service, a maintenance window can be triggered automatically, if the microdeployment package
contains an element that requires resetting the cloud-based environment. Refer to the Bizagi cloud maintenance
window.

Troubleshooting
As mentioned above, a Microdeployment fails whenever you include in the Deployment Package one or more
objects of metadata that have not been previously deployed in that same target environment.
In such situations, attempting to import a Microdeployment package displays a message similar to the one shown
below.

Page 227 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
As hinted by the message, those metadata objects which are not already in the target environment, have their GUIDs
displayed for troubleshooting purposes.
Upon clicking Yes, the error message will be copied to your clipboard, allowing you to search for those objects in
the Package Visualizer in order to identify them and address the issue later by removing those objects from the
Deployment Package.

Advanced Deployment example

Overview
Bizagi presents an Advanced Deployment as an alternative to the One-click Deployment in Bizagi Studio, to perform
Deployments of Processes in specific scenarios having sophisticated requirements.
For more information about the One-click Deployment which assists this process, which is automatically deploying
process packages, refer to Deploying your processes.
For more information about its description and user interface, refer to the Advanced Deployment.

In this section we illustrate an example of the Advanced deployment used to deploy your Bizagi processes into a
production environment.

Setting up the Advanced Deployment

To set up the Advanced Deployment, note that it provides 3 different executable files one of them is to be used in
the Development environment, and the other two in a machine that can access the target environment's database,
which may not be within the Development environment's network.

To set it up, carry out these steps:

1. Make sure you locate the Advanced Deployment executable files.

The Advanced Deployment executable files are located at the Management Console folder at Bizagi's default
installation path, which is usually at C:\Program Files\Bizagi\Bizagi Studio\MC.

2. Make sure you copy this folder whole content in a machine which has network access to your target environment
database where you will deploy.
There are no further installation steps required.
This means you will likely create a duplicate of this folder in a machine that has access to your Production database
in case that you don't have a common machine that has network access to both Development and Production.

3. Configure the executable's configuration files.

Within the folder structure of the Advanced Deployment structure, you will find these executable files:
CreateDatabase.exe, Export.exe, and CreateImport.exe, with their corresponding configuration files:
CreateDatabase.exe.config, Export.exe.config, and CreateImport.exe.config.

To configure these files, follow the criteria mentioned above.

· First configure Export.exe, by editing the Export.exe.config file so that you specify the connection to the
Development Database from where you want to obtain changes in your project.
· Then configure the CreateImport.exe by editing its CreateImport.exe.config file so that you specify the connection
to the target environment Database to where you want to publish the changes in your project: Test, Production.
You will need to configure CreateDatabase.exe similarly only for your initial deployment.

Page 228 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· To configure the connection detail in these files, locate the DSNDB and the PROVIDERTYPE key as described at
Advanced Deployment.

Only in case you are performing a first Deployment to your Test or Production environment (the target Database
does not exist), then you will need to run an additional executable file in this folder called CreateDatabase.exe.
To do this, configure the CreateDatabase.exe.config with the connection detail of the Database you wish to
create.
This Database will be created as a blank Bizagi project, and set to be a Test or Production Database.

Keep in mind that:

· If the new Database is in SQL Server, your instance should have an explicit predefined TCP/IP port.
For more information about SQL Server requirements and configuration, refer to SQL Server Configuration.
· If the new Database is in Oracle, you need to have previously created the BizagiAdmon user and consider that
the password you set for your new Database, must be the same one used by the BizagiAdmon user.
For more information about Oracle requirements and preconfiguration, refer to Creating a project using Oracle.

Preparation for the Advanced Deployment

Creating the Export package, the .bex file, is always the first step in using the Advanced Deployment, as this file will
contain the changes we want to take from a Development environment and into our target environment.

Therefore, before you begin the exportation of the Processes and their objects, make sure that these conditions are
met so that the file contains the proper information:

1. All changes in the development environment must have been saved. At this point, you should know which
Processes and Sub-Processes you want to deploy, and any team members working in Bizagi Studio must make sure
that they have checked in these Processes.

2. Data and configuration managed directly in the Production environment should be taken into account.
For data, it is really important to handle the Parameter entities values, so that you can review and tell which
Parameter entities values should be updated into the target environment.
In addition to this and in general, it is strongly recommended to be completely sure about what will be included in
the Deployment (including: security settings, interfaces and external systems configuration, environment parameters,
etc).

For more information about these subjects, refer to the Previous considerations and requirements for a
Deployment.

Using the Advanced Deployment

Using the Advanced Deployment is divided into 2 major tasks: First running the Export utility to generate the
package with the information to be deployed, and then using the other utilities at the target environment (Test,
Production) to apply the deployment package.

Using the Export at the Development environment

1. Run Export.exe.
A window appears with the following options:

Page 229 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Option- number
in the image Description
above

Shows the Project's Database name and its Database Server.

1
This should refer to your Development environment.

2 Lists the applications in our project.

3 Lists the Processes and Sub-Processes per application which can be selected.

Shows the versions of our Processes which can be selected for export. By right-clicking a
4
version, the option to manually include dependencies appears.

Relate Experience objects such as searches, relevant options, actions, triggers and
5
contexts defined for any entities.

6 Allows to configure the exportation options.

7 Creates the export file (.bex).

8 Load the information configured in a JSON file.

9 Save the information configured in a JSON file.

There are some additional tasks which can be run after having generated the export file.
These are also present in the Import utilities.

Page 230 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. Mark the Processes, Sub-Processes and experience components you wish to deploy.
There is a special option at the version's right-click if you with to include parameter entities, master entities, query
forms and business rules; in order to force some objects into the Deployment package.
To view more information about how this option works, refer to Relate objects.

If you have defined experience components select the Experience tab and make sure all components are related.
In this case, consider we only want to deploy all experience components for the Stakeholder called Call Center
Agent and the actions associated to the Ticket Activities entity from the Help Desk process.

Page 231 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Each item listed will require the following components to be deployed:
· Relevant to me options: Update Customer information and Register New Ticket.

Relevant to me options are process shortcuts. Therefore the process it launches must be related individually when
deploying.

Page 232 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Page 233 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Since the shortcut is dependent from a context, make sure it is selected for deployment as well.

Page 234 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Search: Cases

Page 235 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This is a search, thus we need to take into account the stakeholder entity from which the search is available, the
entity to perform the search and the contexts where it is available.

Page 236 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 o The search form is automatically deployed along with the searched entity.
o The stakeholder from which the search is available is automatically considered when the search is selected.
o The context related had been selected previously.

Page 237 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Actions: Register Activity / Solve ticket and Escalate Ticket

Page 238 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Depending on the sort of action, different components and objects are related, in this case Register Activity / Solve
ticket and Escalate Ticket are form actions. Therefore, the related objects are:

o The entity where the action is defined, this will also deploy the related form. Since we are ticking the activity, this
will automatically deploy the entity associated.

Page 239 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 o Every related context. In this case, the action Register Activity / Solve ticket is always available for the Help
Desk Agent stakeholder, and is only available under the Not Last Service Level context of the Help Desk Agent
stakeholder.

Page 240 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 o The processes where the action can be launched from.

Page 241 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This way all experience components of the Call Center Agent are now ready to be deployed. For further information
about relating objects and experience components, please review Relate Objects article.

Make sure you the Authentication options checkbox in the Advanced options is not checked, if this option is
checked the authentication configured in the target environment will be overridden. Do not use this option unless
you are sure to change the authentication options with the configuration of your source environment.

3. Generate the .bex export file by clicking on Export.

Choose where to save this file. You will need to use this file in the target environment (Test or Production).

If any error is shown, you will need to adjust it in your source environment (Development), and repeat the export
until it is successful.

Using the Import utilities at the target environment

Before running the Import utilities, make sure that your target Database exists.
If this is a first Deployment to the Test environment, or the first one to the Production environment, use the
CreateDatabase.exe utility to create a new and blank Bizagi Database for that environment.
Remember to take backups of your target environment, and proceed with these steps:

Page 242 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
1. Run CreateImport.exe.
Its window will show the following options:

Option- number in the image Description

above

1 Shows the project's database name and the database server.

This should refer to your target environment Test or Production.

2 Presents the option to load the .bex file.

3 Presents the information about how the export was configured.

4 Applies the imported .bex file.

2. Load the .bex export file (created in the previous step) by using the Browse button.
Once loaded, you may view and make sure that the objects to import correspond to those expected.

3. Perform the Deployment by using the Apply package option.

This will execute scripts and modifications in the target Database.
Make sure you carry out tests and keep in mind proper cautions.

What is next?
After you have deployed your Processes into a test or production database, make sure you reload changes in
Bizagi.

Page 243 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· When having processes run in a .NET platform, this means restarting the services of your IIS so that the Work
Portal is reloaded with the changes.

Command line for Advanced Deployment

Overview
Once the automation of a process has been completed, the next step is to make it available for users and clients to
interact live with it, which means that the following step after automation is Deployment.

Bizagi offers 2 main different ways to deploy a project, namely One-click Deployment and Advanced Deployment.
The former provides an interface to step by step configure the deployment's variables and objects. The latter gives
the user total control over what is going to be deployed and what is not. For more information on Deployment
procedures refer to this article.

Some users may require to automate the deployment process by simply running a .bat file or they wish to perform
changes on specific components on their production environment without performing a complex deployment
process. Bizagi acknowledges these situations and offers deployment automation via Command Line Deployment.
This is a third way of deploying projects which only requires the edition of config files from the user or the
specification of parameters.

When to use the Command Line Deployment?

Deployments of Processes is done once the automation stage is completed and when you wish to publish your
processes into a Test or Production environment.
The Command Line Deployment is useful when you want to automate the deployment process by running a .bat file.

How does the Command Line Deployment work?

Command Line Deployment works by following the Export and Import steps from Advanced Deployment by
enabling the execution of these steps by command line.

Important
Before you continue, make sure you acknowledge the following considerations.
· The target environment must have a database of Bizagi's model. Thus, make sure that you run
CreateDatabase.exe when performing the deployment process for the first time.
· The parameters should not contains the double dash prefix --.
· Any backslash character \ inside the configuration file should be replaced with double backslash character \\.
· Any quote character " set in the command line window should be preceded by a backslash character \.

Required profile
The profile of the user working with the Advanced Deployment needs to:
1. Have a basic understanding of JSON structure (in order to configure the configuration files).
2. Have access to the project environments' Databases (with the superuser credentials).
3. Have expertise or important know-how, about the concepts involved in a Deployment of a project in Bizagi.
For more information about the treatment for deploying objects in Bizagi, refer to deployed objects.
4. Have an understanding of the implemented Processes in the project.
This means knowing about these processes' purposes, data model, versions, integrations, security settings,
environment settings management (i.e policy, alarms, parameter entity values), and general workings.

Take into account that for proper testing (carrying our user acceptance tests), this will include being able to tell
which is the expected behavior of the Processes in the Work Portal (under the different business scenarios).

Command Line Deployment executable files

The Command Line Deployment uses two of the executable files featured by the Advanced Deployment, each having
its own parameters.
These executable files come in by default installed where the Management Console is installed (at C:\Program
Files\Bizagi\Bizagi Studio\MC\).

Page 244 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The purpose of each executable file and where it should be used is described in the following table.

Executable Purpose

Export.exe Creates a .bex export file where you will have a package of objects
from your Development environment of selected process versions.

CreateImport.ex Applies the changes into your Production environment. This is

e done after analysis of the .bex export file against the Production
environment, and considering how any existing information should
be handled (i.e merge of records).

For examples of how to build .bat files which run the executed files above, please refer to Export configuration
templates.

Export.exe
Use this executable to generate the initial package of objects you want to deploy from your Development
environment.
This should be the only executable file which is configured to reference the Development environment database (the
others will reference the Production environment database).

The execution of this file uses the following structure:

Export.exe --DSNDB "..." --Provider "..." --Outputfile "..." --Config "..." --

Workflows "..." –-Options "..." --ExperienceObjects "..." --Log "..." --ErrorLogger
"..."

Parameters notes and description:

· DSNDB: Connection String to the source project database. This parameter is mandatory and should be included in
the command line or in the config file for the execution (--Config attribute).
When using SQL Server:
"Persist Security Info=True;User ID=[SQL_Login];Password=[Login_password];Data
Source=[DB_Server]\[Named_instance];Initial Catalog=[Database];"
Consider:
o [SQL_Login]: The login account used to connect to that SQL Server database instance.
o [Login_password]: The password for the above login.
o [DB_Server]: Name or IP address of the database server. Use \[Named_instance] when applies, if your database
instance is not the unnamed default one.
o [Database]: The name of the project environment's database. Recall that specifically for the CreateDatabase,
this database you specify is the one that will be created.

When using Oracle:

"Data Source=[DB_Server]:[Port_number]/[Service];User
ID=[User_schema];Password=[User_schema_password];Unicode=True;"
Consider:
o [DB_Server]: Name or IP address of the database server.
o [Port_number]: The TCP port used for the connection to the database service.
o [Service]: The service identification for an Oracle instance.
o [User_schema]: The name of the project environment's database. Recall that specifically for the CreateDatabase,
this database you specify is the one that will be created.
o [User_schema_password]: The password for that user schema. It is strongly recommended to encrypt the
password using Password Encryption feature.

· Provider: Client of the source project database. This parameter is mandatory and should be included in the
command line or in the config file for the execution (--Config attribute).

Page 245 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 The possible values are "MSSqlClient" or "Oracle".

· Outputfile: name of the .bex export file where you will have a package of objects from your Development
environment of selected process versions. This parameter is mandatory.

· Config: JSON file where the deployment configuration is set. This parameter is mandatory as long as no
parameters have been defined through command line. The creation of this file is explained beyond.

· Workflows: JSON structure with all the processes to be deployed. This parameter is mandatory and should be
included in the command line or in the config file for the execution (--Config attribute).
This parameter must be set in the following structure:
--Workflows "[{\"DisplayName\": \"Bilirubin\",\"Version\": \"1.0\"},
{\"DisplayName\": \"Credit Card\",\"Version\": \"1.1\"}]"

· Options: JSON structure with the additional possibilities to include or exclude those objects managed by Bizagi.
This parameter is mandatory and should be included in the command line or in the config file for the execution
(--Config attribute). All the values here are Boolean type.

OPTION HOW TO USE IT? WHEN TO USE IT?

Include environment parameter \"EnvironmentParamsValue\" You may include managed values

values : true|false for your given environments. It is
recommended to make sure that
these parameter values (such as the
SMTP server, interfaces URL, etc)
correspond each to their
environment configuration.

Include user jobs \"Custom Job\": true|false If your project uses custom jobs,
make sure you set this to true in
order to make sure these are
included.

Include organization \"Org Tables\": { Set true for any organization

\"Position\": true| configuration you want to include in
false, the deployment.
\"Skills\": true|false,
\"Location\": true|
false,
\"Area\": true|false,
\"Role\": true|false
},

Include authentication options. \"AuthOption\": true|false You may include the authentication
options you have previously
customized in Bizagi Studio for this
project. Nonetheless, these options
can be managed through the
Management Console in your
production environment.

Include records of parameter \"EntParamData\": true| You may initially and from Bizagi
entities managed in production false Studio options, make sure set true
for each parameter entity whose
records you will need to be
deployed from the Development
environment.

Page 246 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 If you do have entities that need
their values updated from the
Development environment, make
sure this item is set as true.

Example:
--Options "{\"Custom Job\": false,\"Org Tables\": {\"Position\": true,\"Skills\":
true,\"Location\": true,\"Area\": true,\"Role\": true},\"EnvironmentParamsValue\":
true,\"AuthOption\": true,\"EntParamData\": false}"

· ExperienceObjects: JSON structure with all the Experience objects to be deployed. This parameter is
mandatory and should be included in the command line or in the config file for the execution (--Config
attribute).
This parameter must be set in the following structure:
--ExperienceObjects "[{\"Entity\": \"Librarian\",\"Type\": \"MySearch\",\"Name\":
\"Search books\"},{\"Entity\": \"Patient\",\"Type\": \"EntityAction\",\"Name\":
\"Start Triage\"},{\"Entity\": \"X-ray\",\"Type\": \"EntityConstructor\",\"Name\":
\"EntityConstructor\"}]"

· Log: File where the trace of the deployment execution will be recorded. This parameter is optional.

· ErrorLogger: File where the errors during the deployment execution will be recorded. This parameter is
optional.

Even though some parameters are mandatory, if no parameters were set for the execution. The export will be
executed using its own user interface.

Export configuration file

In order to ease the construction of the parameters (either to paste them to the Command Prompt Window or to
send them through the config file), Bizagi features an option available from the export method of Advanced
Deployment. This option allows you to export a JSON file with the structure for the parameters --Workflows, –-
Options, and --ExperienceObjects.

To generate the configuration file, follow these steps:

1. Follow the steps 1 to 4 described file in Advanced Deployment for export.exe.

2. Once the configuration has been made, click the Save button.

Page 247 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
3. Select the path where the configuration file will be saved. The configuration file is saved as JSON type.

Page 248 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Once the configuration file is stored, you may use it by setting its full path in the --Config parameter. For further
deployments, you may update this configuration file manually or by following again the steps mentioned.
If you want to include the information of your connection string in this file, add the Dsndb and Provider
parameters before the Workflows parameter.

Page 249 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
CreateImport.exe
Use this executable to review and apply the package you created through Export.
To use CreateImport.exe, first make sure you have already copied the whole MC folder in a local path of a machine
that has network access to your Production environment database (the MC folder contains all 3 executable files and
the dll files needed). Furthermore, the export file created before must be accessible from your production
environment.

The execution of this file uses the following structure:

CreateImport.exe --DSNDB "..." --Provider "..." --FilePath "..." --Log "..." --

ErrorLogger "..." --Config "..."

Parameters notes and description:

· DSNDB: Connection String to the source project database. This parameter is mandatory and should be included in
the command line or in the config file for the execution (--Config attribute).
When using SQL Server:
"Persist Security Info=True;User ID=[SQL_Login];Password=[Login_password];Data
Source=[DB_Server]\[Named_instance];Initial Catalog=[Database];"
Consider:
· [SQL_Login]: The login account used to connect to that SQL Server database instance.
· [Login_password]: The password for the above login.
· [DB_Server]: Name or IP address of the database server. Use \[Named_instance] when applies, if your database
instance is not the unnamed default one.
· [Database]: The name of the project environment's database. Recall that specifically for the CreateDatabase,
this database you specify is the one that will be created.

When using Oracle:

Page 250 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 "Data Source=[DB_Server]:[Port_number]/[Service];User
ID=[User_schema];Password=[User_schema_password];Unicode=True;"
Consider:
· [DB_Server]: Name or IP address of the database server.
· [Port_number]: The TCP port used for the connection to the database service.
· [Service]: The service identification for an Oracle instance.
· [User_schema]: The name of the project environment's database. Recall that specifically for the CreateDatabase,
this database you specify is the one that will be created.
· [User_schema_password]: The password for that user schema. It is strongly recommended to encrypt the
password using Password Encryption feature.

· Provider: Client of the source project database. This parameter is mandatory and should be included in the
command line or in the config file for the execution (--Config attribute).
The possible values are "MSSqlClient" or "Oracle".

· FilePath: name of the .bex export file generated before. This parameter is mandatory and should be included
in the command line or in the config file for the execution (--Config attribute).

· Log: File where the trace of the deployment execution will be recorded. This parameter is optional.

· ErrorLogger: File where the errors during the deployment execution will be recorded. This parameter is
optional.

· Config: JSON file where the configuration is set. This parameter is mandatory as long as no parameters have
been defined through command line.
The config file should have the same mandatory parameters mentioned before. Example:

{
"DSNDB": "Persist Security Info=True;User
ID=[SQL_Login];Password=[Login_password];Data Source=[DB_Server]\
\[Named_instance];Initial Catalog=[Database];;",
"Provider": "MSSqlClient",
"FilePath": "input.bex",
"Log": "log.txt",
"ErrorLogger": "error.txt"
}

Even though some parameters are mandatory, if no parameters were set for the execution. The CreateImport will
be executed using its own user interface.

What is next?
Once you have completed your process deployment through the Command Line Deployment, we recommend you
clean up the server's cache before announcing that the deployment procedure is completed.

When running your processes in an IIS, after performing a command line deployment you should clear the cache of
your Work portal and database.
In order to do this, invoke the following Bizagi web services as available in every project:
· Render cache as stored in the database: http://[your_server][your_project]/webservices/cache.asmx?
op=CleanRenderCache
· Application cache: http://[your_server][your_project]/webservices/cache.asmx?op=CleanUpCache

Note that you should restart your IIS services.

Page 251 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Command line deployment example

Overview
Bizagi presents the Command Line as an alternative to the One-click Deployment in Bizagi Studio, to perform
Deployments of Processes in specific scenarios having sophisticated requirements.
For more information about the One-click Deployment which assists this process (automatically deploying process
packages), refer to Deploying your processes.
For more information about its description and user interface, refer to the Advanced Deployment.

In this section we illustrate an example of the Command Line deployment used to deploy your Bizagi processes into
a production environment.
The example will deploy the Help Desk process available from our Process Xchange using a SQL Server database.

Setting up the Command Line Deployment

To set up the Deployment, note that it provides 3 different executable files (1 of them is to be used in the
Development environment, and the other 2 in a machine where there is access to the target environment's Database
(i.e a machine with access to a Production environment, which may not be within the Development environment's
network).

To set it up, carry out these steps:

1. Make sure you locate the Deployment executable files.

The Deployment executable files are located at the Management Console folder (at Bizagi's default installation path,
which is usually at C:\Program Files\Bizagi\Bizagi Studio\MC).

2. Make sure you copy this folder whole content in a machine which has network access to your target environment
database (where you will deploy).
There are no further installation steps required.
Notice that this means you will likely create a duplicate of this folder in a machine that has access to your Production
database (in case that you don't have a common machine that has network access to both Development and
Production).

3. Configure the CreateDatabase.exe only for your initial deployment.

Only in case you are performing a first Deployment to your Test or Production environment (the target Database
does not exist), then you will need to run an additional executable file in this folder called CreateDatabase.exe.
To do this, configure the CreateDatabase.exe.config with the connection detail of the Database you wish to
create.
This Database will be created as a blank Bizagi project, and set to be a Test or Production Database.

Keep in mind that:

· If the new Database is in SQL Server, your instance should have an explicit predefined TCP/IP port.
For more information about SQL Server requirements and configuration, refer to SQL Server Configuration.
· If the new Database is in Oracle, you need to have previously created the BizagiAdmon user and consider that
the password you set for your new Database, must be the same one used by the BizagiAdmon user.
For more information about Oracle requirements and preconfiguration, refer to Creating a project using Oracle.

Preparation for the Command Line Deployment

Creating the Export package (.bex file) is always the first step in using the Command Line Deployment, as this file will
contain the changes we want to take from a Development environment and into our target environment.

Page 252 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Therefore, before you begin the exportation of the Processes and their objects, make sure that these conditions are
met so that the file contains the proper information:

1. All changes in the development environment must have been saved. At this point, you should know which
Processes (and Sub-Processes) you want to deploy, and any team members working in Bizagi Studio must make
sure that they have checked in these Processes.

2. Data and configuration managed directly in the Production environment should be taken into account.
For data, it is really important to handle the Parameter entities values, so that you can review and tell which
Parameter entities values should be updated into the target environment.
In addition to this and in general, it is strongly recommended to be completely sure about what will be included in
the Deployment (including: security settings, interfaces and external systems configuration, environment parameters,
etc).

For more information about these subjects, refer to the Previous considerations and requirements for a
Deployment.

Using the Command Line Deployment

Using the Command Line Deployment is divided into 2 major tasks: First running the Export utility to generate the
package with the information to be deployed, and then using the other utilities at the target environment (Test,
Production) to apply the deployment package.

As explained before in Command Line Deployment, for sending the parameters to the executable files, you may
choose to configure a configuration file or you may send each parameter separately. For the example of this article,
we will use the configuration file for the Export procedure and we will send parameters for the Import procedure.
Disregard the option you want to use, you may use .bat files in order to automate the procedure, for more
examples of these .bat files, refer to Export configuration templates.

Using the Export at the Development environment

1. Configure the file Export.exe.config with the connection detail of your development's database, locate the
DSNDB and the PROVIDERTYPE key as described at Advanced Deployment.

2. Run Export.exe.
Its window will show the following options:

Page 253 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Option- number
in the image Description
above

Shows the Project's Database name and its Database Server.

1
This should refer to your Development environment.

2 Lists the applications in our project.

3 Lists the Processes and Sub-Processes per application which can be selected.

Shows the versions of our Processes which can be selected for export. By right-clicking a
4
version, the option to manually include dependencies appears.

Relate Experience objects such as searches, relevant options, actions, triggers and
5
contexts defined for any entities.

6 Allows to configure the exportation options.

7 Creates the export file (.bex).

8 Load the information configured in a JSON file.

9 Save the information configured in a JSON file.

2. Mark the Processes, Sub-Processes and experience components you wish to deploy.

Page 254 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Notice there is a special option at the version's right-click if you with to include parameter entities, master entities,
query forms and business rules; in order to force some objects into the Deployment package.
To view more information about how this option works, refer to Relate objects.

If you have defined experience components select the Experience tab and make sure all components are related.
In this case, consider we only want to deploy all experience components for the Stakeholder called Call Center
Agent and the actions associated to the Ticket Activities entity from the Help Desk process.

Page 255 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Each item listed will require the following components to be deployed:
· Relevant to me options: Update Customer information and Register New Ticket.

Relevant to me options are process shortcuts. Therefore the process it launches must be related individually when
deploying.

Page 256 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Page 257 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Since the shortcut is dependent from a context, make sure it is selected for deployment as well.

Page 258 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Search: Cases

Page 259 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This is a search, thus we need to take into account the stakeholder entity from which the search is available, the
entity to perform the search and the contexts where it is available.

Page 260 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 o The search form is automatically deployed along with the searched entity.
o The stakeholder from which the search is available is automatically considered when the search is selected.
o The context related had been selected previously.

Page 261 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Actions: Register Activity / Solve ticket and Escalate Ticket

Page 262 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Depending on the sort of action, different components and objects are related, in this case Register Activity / Solve
ticket and Escalate Ticket are form actions. Therefore, the related objects are:

o The entity where the action is defined, this will also deploy the related form. Since we are ticking the activity, this
will automatically deploy the entity associated.

Page 263 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 o Every related context. In this case, the action Register Activity / Solve ticket is always available for the Help
Desk Agent stakeholder, and is only available under the Not Last Service Level context of the Help Desk Agent
stakeholder.

Page 264 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 o The processes where the action can be launched from.

Page 265 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This way all experience components of the Call Center Agent are now ready to be deployed. For further information
about relating objects and experience components, please review Relate Objects article.

3. Export the configuration options by clicking the Save button.

Page 266 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
4. Select the path where you want to save the JSON file; for example purposes, the file will be saved at Management
Console folder.

Page 267 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
5. Edit the configuration file using the text editor of your choice and add the connection detail of your
development's database at the begging of the file as explained in Command Line Deployment.

6. Open a Command Prompt window en navigate to Bizagi's default installation path, which is usually at C:\Program
Files\Bizagi\Bizagi Studio\MC.

Page 268 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
7. As mentioned before, the configuration file was saved in this folder named as ExportSettings.json. Run the
Export,exe file using the following command:

Export.exe --Outputfile "Export1.bex" --Config "ExportSettings.json" --Log "log.txt"

--ErrorLogger "Errors.txt"

8. Once the log shows that the file was exported, close the Command Prompt window.

· You may add the command explained here using a .bat file in order to enable the execution by running the
given file. This will let you run the Export process easier. Review an example in Export configuration templates.
· It is strongly recommended to encrypt the Database password using Password Encryption feature from the
Work Portal or from the Utility commands.
· If any error is shown, you will need to adjust it in your source environment (Development), and repeat the
export until it is successful.

Using the Import utilities at the target environment

Before running the Import utilities, make sure that your target Database exists.
If this is a first Deployment to the Test environment, or the first one to the Production environment, use the
CreateDatabase.exe utility to create a new and blank Bizagi Database for that environment.
Once you have ensured this, remember to take backups of your target environment, and proceed with these steps:

Page 269 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
As mentioned before, we are running the CreateImport.exe by sending all their parameters.

1. Open a Command Prompt window en navigate to Bizagi's default installation path, which is usually at C:\Program
Files\Bizagi\Bizagi Studio\MC.

2. As mentioned before, this example will deploy the Help Desk process using a SQL Server database. Run the
CreateImport.exe file using the following command:

CreateImport.exe --DSNDB "Persist Security Info=True;User

ID=[DBUser];Password=sa;Data Source=[DBServer];Initial Catalog=[DBName];" --Provider
MSSqlClient --FilePath Export1.bex --Log logImport.txt --ErrorLogger ErrorImport.txt

3. Once the log shows that the file was imported, close the Command Prompt window.

Page 270 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 · If your process uses Oracle Database, perform the according changes.
· You may add the command explained here using a .bat file in order to enable the execution by running the
given file. This will let you run the Import process easier. Review an example in Export configuration templates.
· It is strongly recommended to encrypt the Database password using Password Encryption feature from the
Work Portal or from the Utility commands.
· If any error is shown, you will need to adjust it in your source environment (Development), and repeat the
import until it is successful.

What is next?
After you have deployed your Processes into a test or production database, make sure you reload changes in
Bizagi.
· When having processes run in a .NET platform, this means restarting the services of your IIS so that the Work
Portal is reloaded with the changes.

Other utility commands

Overview
The Command Line Deployment have extra methods that can be taken into account to automate some manual
operations. The information will be detailed in this article:

1. Environment Variables configuration.

2. Passwords Encryption.
3. Force entity replication.
4. Export configuration templates.

1. Environment Variables configuration

Bizagi has predefined and custom variables that can be configured depending on user's needs. This functionality
helps to update a project's general configuration values, which will reflect on execution behaviors. For example, if
you wish to change the time it takes for Bizagi to wipe its cache, you can modify the value of the corresponding
Environment Variable in order to do so.
Other
The way to specify the variables and its corresponding values is through the execution of BizagiAutomation.exe in a
command line as follows:

BizagiAutomation.exe --runtype UpdateEnvironment --DSNDB "..." --Provider "..." –

EnvironmentName "..." --BizagiValues "..." --CustomValues "..." --Config "..." --Log
"..." --ErrorLogger "..."

Parameters notes and description:

· --runtype: it is used to specify the type of execution of the BizagiAutomation.exe program. In this case the value
of this parameter is UpdateEnvironment since Environment Variables are being updated.
· --DSNB: Connection String to the project database. This parameter is mandatory.
When using SQL Server:
"Persist Security Info=True;User ID=[SQL_Login];Password=[Login_password];Data
Source=[DB_Server]\[Named_instance];Initial Catalog=[Database];"
Consider:
o [SQL_Login]: The login account used to connect to that SQL Server database instance.
o [Login_password]: The password for the above login.
o [DB_Server]: Name or IP address of the database server. Use \[Named_instance] when applies, if your database
instance is not the unnamed default one.
o [Database]: The name of the project's database.

When using Oracle:

Page 271 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 "Data Source=[DB_Server]:[Port_number]/[Service];User
ID=[User_schema];Password=[User_schema_password];Unicode=True;"
Consider:
o [DB_Server]: Name or IP address of the database server.
o [Port_number]: The TCP port used for the connection to the database service.
o [Service]: The service identification for an Oracle instance.
o [User_schema]: The name of the project's database.
o [User_schema_password]: The password for that user schema. It is strongly recommended to encrypt the
password using Password Encryption feature.
· --Provider: Database client. This parameter is mandatory.
o For Oracle databases use the following string: Oracle
o For SQL Server databases use the following string: MSSqlClient
· --EnvironmentName: Name of the environment to configure. Could be one of Development, Test or Production.
This parameter is mandatory.
· --BizagiValues: predefined properties to be updated in JSON Syntax. This parameter is optional.
· --CustomValues: user defined properties to be set in JSON Syntax. This parameter is optional.
· --Log: File where the execution logs should be appended. This parameter is optional.
· --ErrorLogger: File where the error logs should be appended. This parameter is optional.
· --Config: File with the execution parameters in JSON syntax.
This parameter is an option the user has to send the parameters to the command line program that facilitates the
process. In case you want to set the parameters for the execution using a file, you have to build a config file with
the following format:

{
"DSNDB":"[DSNB String as it was described above]",
"Provider":"[MSSqlClient or Oracle]",
"environmentName": "[Development or Test or Production]",
"bizagiValues":{
"sendEmailCopyTo": "[email protected]",
"enableEmail": false,
"interfaceThresholdTime":2500
},
"customValues": {
"AdmonEmail": "[email protected]",
"defaultHolidays": "200"
}
}

When choosing to send a config file with the parameters, the user should write it before hand and execute the
BizagiAutomation.exe command with the --config parameter only. Providing next to it the path to the file containing
the execution parameters. For example:

BizagiAutomation.exe --runtype UpdateEnvironment --Config "Path to file"

Please note that mandatory parameters should be specified in at least one way, either on the command prompt or
the config file. In case it is specified on both, Bizagi will only consider the value given in the command prompt.

Regarding the BizagiValues and CustomValues, take into account that:

· There should at least be one value for BizagiValues and one for CustomValues for the program to execute.
· All CustomValues specified must match an existing one with the same exact name.
· You can set as many of them as you like, defining them in JSON format.
· All the BizagiValues available are:

Page 272 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 AttribMaxLengthThre EmailIntegrationPas QueryEngineDSNDB UploadMaxFileSize
shold sword

BizagiSchedulerInte EmailIntegrationPor QueryEngineProvider UploadPath

rval t Type

CacheAvailableMemor EmailIntegrationUse RepDsndb WebDavFolder

yPercentageLimit rname

CacheExpirationChec EmailRecipient RepProviderType WebDavUrl

kInterval

CryptographyEncrypt EnableEmail SendEmailBccTo WebServicesTimeOut

ionAlgorithm

CryptographyHashAlg EnableEntityLog SendEmailCopyTo WsLegacyEnabled

orithm

CryptographyKeyUrl EnableMMFactLog SkipRecipients WsSecurityEnabled

DataStoreEnabled EnablePushNotificat SmtpAccount WsSecurityPassword

ions

DisableAbortNotific EnableTrace SmtpEnableSsl WsSecurityUserName

ations

EmailIntegrationAcc EntityTableCacheTim SmtpPassword WsSecurityX509CertF

ount eout indType

EmailIntegrationCon EntityTesting SmtpSenderAcc WsSecurityX509CertF

nectionType indValue

EmailIntegrationEna InterfaceThresholdT SmtpServer WsSecurityX509CertS

bled ime toreLocation

EmailIntegrationEna Logging SmtpType WsSecurityX509CertS

bleSsl toreName

EmailIntegrationHos ParamEntityInstance SoaBusinessKeyEnfor WsSecurityX509CertV

t sThreshold cement alidationMode

2. Passwords Encryption
Password Encryption allows you to add an extra security layer to passwords or other relevant information in your
project. This feature uses SHA-2 hashing function to encrypt any text string. This feature is also available through the
Work Portal and can be used in every environment. For further information on this feature via the work portal, refer
to this article.

Just as it works in the Work Portal, Bizagi allows you to generate encrypted passwords through Command Line
Automation. In order to use this functionality you just need to run the BizagiAutomation.exe command line tool with
GeneratePassword runtype parameter as follows.

BizagiAutomation.exe --runtype GeneratePassword --Password "Text to encrypt" --

EncryptType "Encryption type" --Log "..." --ErrorLogger "..." --Config "..."

Parameters notes and description:

· runtype: it is used to specify the type of execution of BizagiAutomation command line tool. In this case
GeneratePassword is used as the value of this parameter since the need is to encrypt a password.
· Password: it is used to specify the text that the user wants to encrypt. It should be passed as the value of this
parameter. This parameter is mandatory and should be included in the command line or in the config file for the
execution.

Page 273 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· EncryptType: it is used to indicate the encryption type required. The different possible values are P for project
file's passwords, and C for configuration file's passwords. mandatory. This parameter is mandatory and should
be included in the command line or in the config file for the execution.
· Log: its value indicates the file where the execution logs will be appended. This parameter is optional.
· ErrorLogger: its value indicates the file where the error logs will be appended. This parameter is optional.
· Config: File with the execution parameters in JSON syntax. This parameter is mandatory when one or more
mandatory parameters are not sent.

· The result of the execution will be the encrypted value which will be returned on the command prompt.
· You can copy and paste this string wherever it is required.

3. Force entity replication

Bizagi can be integrated with external data sources to obtain information from other systems that an organization
may already have in place. One of those mechanisms is data replication, which consists of local copies of external
data sources that are updated periodically to provide current information from other systems to a Bizagi
application. For more information on Data Replication refer to this article.

When a deployment process is done, the database will start from scratch by default. This means that there will be
no information whatsoever of any entity, including replicated tables. To avoid waiting for the update process of
the data replication to run and populate the required information, Bizagi provides a way to enforce the
replication of the information via the Command Line Deployment.

To do so, users may execute the BizagiAutomation command line tool with the ForceReplication runtype specified.
The command should be executed as follows.

BizagiAutomation.exe --runtype ForceReplication --DSNDB "Database info" --Provider

"Provider info" --Config --Log --ErrorLogger

Parameters notes and descrption:

· Parameters enclosed in squared brackets ("[", "]") are optional. This means that the user may or may not use them
for the execution.
· Parameters not enclosed in squared brackets are mandatory. This parameters should be included in the
command line or in the config file for the execution.
· runtype: it is used to specify the type of execution of BizagiAutomation command line tool. In this case
ForceReplication is used as the value of this parameter since the need is enforce the replication of the external
data source.
· DSNB: Connection String to the project database. This parameter is mandatory.
When using SQL Server:
"Persist Security Info=True;User ID=[SQL_Login];Password=[Login_password];Data
Source=[DB_Server]\[Named_instance];Initial Catalog=[Database];"
Consider:
o [SQL_Login]: The login account used to connect to that SQL Server database instance.
o [Login_password]: The password for the above login.
o [DB_Server]: Name or IP address of the database server. Use \[Named_instance] when applies, if your database
instance is not the unnamed default one.
o [Database]: The name of the project's database.

When using Oracle:

"Data Source=[DB_Server]:[Port_number]/[Service];User
ID=[User_schema];Password=[User_schema_password];Unicode=True;"
Consider:
o [DB_Server]: Name or IP address of the database server.
o [Port_number]: The TCP port used for the connection to the database service.

Page 274 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 o [Service]: The service identification for an Oracle instance.
o [User_schema]: The name of the project's database.
o [User_schema_password]: The password for that user schema. It is strongly recommended to encrypt the
password using Password Encryption feature.
· Provider: Database client. This parameter is mandatory.
o For Oracle databases use the following string: Oracle.
o For SQL Server databases use the following string: MSSqlClient.
· Log: its value indicates the file where the execution logs will be appended. This parameter is optional.
· ErrorLogger: its value indicates the file where the error logs will be appended. This parameter is optional.
· Config: File with the execution parameters in JSON syntax. This parameter is mandatory when one or more
mandatory parameters are not sent.

4. Export configuration templates

If you are still not sure or confident enough to write the commands to perform a successful Command Line
Deployment, Bizagi offers a way to generate examples of how each application should be executed. This will
generate a folder containing all the examples for each of the runtypes of the BizagiAutomation tool.

To generate the templates execute the following lines in your command prompt.

BizagiAutomation.exe --runtype GenerateTemplates

Inside the MC tools folder, a new folder will be generated containing all the examples for each runtype.

1. Open a Command Prompt an navigate to MC folder (C:\Program Files\Bizagi\Bizagi Studio\MC).

2. Run the command described before.

Page 275 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
3. Check the location stated in the command prompt and you will find the generated folder with its contents.

4. Each sub-folder corresponds to an application of BizagiAutomation.exe. Inside you will find an example config
file, Execution (bat file) using the config file, Execution (bat file) using command prompt parameters and a ReadMe
with further considerations.

Page 276 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
5. Explore the generated files to understand how they work and replace the default parameters with your own in
order to perform the Deployment as you need it. The .bat and config files may be opened with the text editor of
your choice in order to see or edit their content.

Project configuration alternatives

Overview
Though every Bizagi project is specifically designed for a given purpose they all share the same general structure
and are initially setup on a generic way. Bizagi acknowledges that some projects may use best a different setup
procedure according to specific compliance requirements, or according to the involved system architecture.

Further information
Refer to the sections below to view a high-level procedure for these two scenarios:
· To view how to set up a Bizagi in cluster and then rely on the Advanced deployment to publish processes, refer to
High availability setup procedure.
· To view how to set up a Bizagi project (its Work portal and Scheduler) manually whenever running the Automation
Server installer is not possible, refer to Manual setup procedure without installers.

High availability setup procedure

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:

Page 277 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
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).

Page 278 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
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.

Page 279 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· 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).

Page 280 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
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.

Page 281 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 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.

Page 282 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· 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.

Page 283 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
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)

Page 284 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
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"/>

Page 285 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
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.

Page 286 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· 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.

Page 287 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
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.

Page 288 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
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.

Manual setup procedure without installers

Overview
This section describes how to manually configure Automation Server for a Test or Production environment running
in a .NET platform, and whenever it is not an option to run the Automation Server installer (i.e, without the
Management Console included by it).
Keep in mind that this procedure is not needed when using the One-click Deployment feature in Bizagi (it is
applicable when using Advanced Deployment).

Before you start, it is important you make sure that your Authoring (Development) environment is already set.
The path where Bizagi is installed in your Development environment (by default at C:\Program
Files\BizAgi\[Bizagi_edition]\) will be referred to as <BIZAGI_PATH> from this point on.

Prerequisites
Installing Automation Server (via its installer), includes required components. However and given that this manual
configuration parts from not running the installer, then the following steps are carried out.
Notice that Bizagi does not require additional components at the database server.

If you will be manually installing your Bizagi operating environment, you will need to make sure your server has
these components previously installed:

1. Microsoft .NET Framework 4.5.2 full.

You may install this component as directly available from download at Microsoft Web sites:
https://www.microsoft.com/en-us/download/details.aspx?id=42642

2. Internet Information Services components.

To make sure your server has a supported version of IIS and the necessary components, refer to: IIS configuration.

3. Additional components according to your project's characteristics.

· If you are using for your Process repository is an Oracle Database, or you use the Virtualization/Replication
features to connect to an external Oracle Database, you will need to install the ODP.NET connectivity client.
· If your project integrates with SAP systems, through the use of Bizagi SAP connector, you will need Visual C++
2010 redistributable.
Before you start
Before you set up Bizagi's operating environment in a Production server, make sure:

1. Having purchased the proper Bizagi license.

This license should be at hand in order to activate it in the production server, otherwise Bizagi Work Portal will not
work.
For further information about licenses, please contact [email protected].

If you are setting up a clustered environment for Bizagi (multiple nodes to support load balancing capabilities),
you may carry out the steps described below, but it is important to contact our support team to make sure you
have activated your license in the clustered environment (for all Bizagi nodes).

2. Having acknowledged the implications of a manual installation.

When manually setting up the runtime of Automation Server for your processes, note that you will need to carry out
a similar procedure when upgrading your project to a newer Bizagi version.
Plan accordingly so that you acknowledge that you will need to upgrade Bizagi version with a previous assessments,
replacing files and by running scripts.

Page 289 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Contact our support team if you wish to carry out this procedure.
Additionally, it is recommended to install as well the Management Console (in a machine having access to the
database server), in order to be able to administer your project's parameters, as described in the Additional steps
section.

What you need to do

Once you have met the prerequisites, in order to configure your Production or Test environment in Bizagi, these
steps are taken (further detail is explained in the Procedure section):

1. Create your Production or Test Database.

In this step, you publish those processes which have been already implemented to a database different than the one
used in the Development environment.

2. Create your project's folder structure

In this step, you create a directory in which you will place all relevant files and structure for your Bizagi project.

3. Install and configure the Work portal

In this step, you install your project's Work portal in the IIS.

4. Install and configure the Scheduler service.

In this step, you install your project's Scheduler as a Windows service (the Scheduler service is in charge of
executing offline tasks).

5. Activate your license.

In this step, you activate the purchased license to support your Production or Test end users.

Procedure
Carry out the following:

1. Create your Production or Test Database.

When the One-click Deployment feature is not used, you will need to create a Database for your Production or Test
environments.
You create this Database with your published processes by using the Advanced Deployment tool.
For more information refer to the Advanced Deployment.

Once this step has been completed, make sure that you end up having the details of the connection to your
Production or Test Database (these will be needed to configure the Work portal and the Scheduler service).

2. Create your project structure

Before you install the components for the operating environment of Bizagi, make sure you create a local directory at
the server, in which you will place all relevant files and structure for your Bizagi project.
Keep in mind:

· The path on which this directory is created, will be addressed from now on as <PROJECT_PATH>.
· Name the directory after the name of your project.
· Inside of the created directory, you will need to create the following sub-directories:
Backups, ComponentLibrary, Database, Docs, Domains, EntityManager, Resources, SOA, Temporary, Tools, and
Trace.

Your <PROJECT_PATH>\[Your_project_name] structure should have at this point:

Page 290 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
3. Install and configure the Work portal
To install Bizagi Work portal, you will need to copy Bizagi web folder and files into
<PROJECT_PATH>\[Your_project_name].

These set of steps for the Work portal should be done in any number of servers, if your solution considers more
than one in a clustered environment that supports load balancing capabilities.
Therefore and for a cluster configuration, make sure you install and configure the Work portal in each of your
cluster nodes.

3.1. Copy the Web application folder.

Take a copy of the WebApp folder found at the Bizagi's Project Model files (located at
<BIZAGI_PATH>\ProjectModel\WebApp\), and place it into the server's local path of your project (inside of
<PROJECT_PATH>\[Your_project_name]).

3.2 Review the Work portal folder’s access rights.

Once you have copied the WebApp folder into the new path, make sure it is not marked as read-only content.

To review this, you may right-click that folder to select its properties and make sure that the Read-only checkbox is
unselected.

Page 291 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Then, make sure that you also grant Full control rights.
We recommend you use one account that has such access rights and that is valid within your domain (a dedicated
network's service account).

Page 292 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click OK to save changes.

3.3 Preconfigure the Work portal.

Edit the Work portal configuration file so that it includes the connection details to your project's database.

To do this, locate the <PROJECT_PATH>\[Your_project_name]\WebApp\web.config file and edit its

DSNDB, PROVIDERTYPE and PROJECT keys according to the detail of the connection to your Test or Production
database. Follow the detail provided below.

· If you are using SQL Server:

<add key="DSNDB" value="Persist Security Info=True;User
ID=[login_account];Password=[login_password];Data
Source=[db_server_instance];Initial Catalog=[project_database];" />

<add key="PROVIDERTYPE" value="MSSqlClient" />

<add key="Project" value="[project_name]"/>

For this consider:

o [db_server_instance]: The Database server, including the instance name if explicitly defined.
o [project_database]: The name of your project's Database.
o [login_account]: The user login used to connect to that Database instance.
o [login_password]: The password for the user login. This information can be included as encrypted.
o [project_name]: The name of your Bizagi project for this environment.
Notice that this detail should refer to the database created with the Advanced Deployment procedure.

· If you are using Oracle:

<add key="DSNDB" value="Data Source=[db_server]:[port_number]/[service_name];User
ID=[user_schema];Password=[schema_password];Unicode=True;" />

<add key="PROVIDERTYPE" value="Oracle" />

Page 293 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
<add key="Project" value="[project_name]"/>

For this consider:

o [db_server]: The Database server.
o [port_number]: The port in which the Database service listens to.
o [service_name]: The Database service identifier.
o [user_schema]: The name of your Bizagi project (seen as the user schema).
o [schema_password]: The password for that user schema.
o [project_name]: The name of your Bizagi project for this environment.
Notice that this detail should refer to the database created with the Advanced Deployment procedure.

The following image illustrates the Work portal configuration file connecting to a SQL Server database:

It is important to make sure that the value for the Project key (<add key="Project"
value="[your_project_name]"/>) matches the name of your project which should match the folder' name
at <PROJECT_PATH>\[Your_project_name]

If your server uses IIS 7 or higher, keep in mind that you need the HTTP compression feature enabled for
performance enhancements in Bizagi.
You may want to review that your web.config contains the <httpCompression> use (specified inside of
<system.webServer>) :

Page 294 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Save the changes and close the file.

3.4 Create the Work portal's Web application

To create the Work portal as a Web application, first make sure you have a proper application pool for the Work
portal.
To do this open the IIS Manager (inetmgr).

Under the application pools, use the Add application pool... option to create one having:
· Name: Give a unique name to this pool.
If you are using a 64-bit installation, it is suggested naming the pool as Bizagi 64-Bit ASP.NET v4.0.
Otherwise, for a 32-bit installation you may name the pool as Bizagi 32-Bit ASP.NET v4.0.
· .NET Framework version: 4.5.2.
· Manage pipeline mode: Integrated.

Page 295 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click OK.
Then edit its advanced settings to make sure the following values on its properties:
· Enable 32-Bit Applications: False (if you are using a 64-bit installation).
For 32-bit installations, select True.
· Identity: [your domain\service account]
Make sure you select the service account you configured for step 3 having rights over:
· The project's Work portal path: <PROJECT_PATH>\[Your_project_name]\WebApp
· Temporary folders used by the .NET Framework, such as C:\Windows\Temp or C:
\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\

We recommend you use one account that has such access rights and that is valid within your domain (a dedicated
network's service account).

Page 296 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click OK.
Once the application pool is set, add a new Web application for Bizagi's Work portal by using the Add application...
option:

Notice that by default and most commonly, the Application is set to the Default Web site.
Though, you may use different Web site and consider its port number setting if different than the default port 80.

Make sure you set:

· An Alias for its location.
· Use the Application pool defined previously.
· Reference as the physical path the WebApp folder located at <WEB_PATH>\WebApp

Page 297 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click OK.

By default, the Web application's Authentication settings are created having Anonymous authentication enabled
and Windows authentication disabled.
It is required that Anonymous authentication is enabled regardless of the authentication used by your project.

You will need to review the Windows authentication setting only if you will be using integrated Windows
authentication in your project.

Finally, run the following commands in a command prompt:

%systemroot%\system32\inetsrv\APPCMD unlock config -section:system.webServer/httpCompression
%systemroot%\system32\inetsrv\APPCMD unlock config -section:system.webServer/serverRuntime

At this point, the Work portal has been set for your Bizagi operating environment.

4. Install and configure the Scheduler service.

To install this service, you will need to copy Bizagi Scheduler folder and files into
<PROJECT_PATH>\[Your_project_name].

4.1. Copy the Scheduler folder.

Take a copy of the Scheduler folder found at the Bizagi's Project Model files (located at
<BIZAGI_PATH>\ProjectModel\Scheduler\), and place it into the server's local path of your project (inside
of <PROJECT_PATH>\[Your_project_name]).

4.2 Review the Scheduler folder’s access rights.

Once you have copied the Scheduler folder into the new path, make sure it is not marked as read-only content.

To review this, you may right-click that folder to select its properties and make sure that the Read-only checkbox is
unselected.

Page 298 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Then, make sure that you also grant the proper access rights to the following users:

USER RIGHTS

ASPNET Modify, Write

[your domain\service account] Modify, Write

SYSTEM user Full control

Page 299 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click OK to save changes.

4.3 Preconfigure the Scheduler.

Edit the Scheduler's configuration file so that it includes the connection details to your project's database.

To do this, locate the <PROJECT_PATH>\[Your_project_name]

\Scheduler\BizAgi.Scheduler.Services.exe.config file and edit its DSNDB, PROVIDERTYPE and
PROJECT keys according to the detail of the connection to your Test or Production database. Follow the detail
provided below.

· If you are using SQL Server:

<add key="DSNDB" value="Persist Security Info=True;User
ID=[login_account];Password=[login_password];Data
Source=[db_server_instance];Initial Catalog=[project_database];" />

<add key="PROVIDERTYPE" value="MSSqlClient" />

<add key="Project" value="[project_name]"/>

For this consider:

o [db_server_instance]: The Database server, including the instance name if explicitly defined.
o [project_database]: The name of your project's Database.
o [login_account]: The user login used to connect to that Database instance.
o [login_password]: The password for the user login. This information can be included as encrypted.
o [project_name]: The name of your Bizagi project for this environment.
Notice that this detail should refer to the database created with the Advanced Deployment procedure.

· If you are using Oracle:

Page 300 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
<add key="DSNDB" value="Data Source=[db_server]:[port_number]/[service_name];User
ID=[user_schema];Password=[schema_password];Unicode=True;" />

<add key="PROVIDERTYPE" value="Oracle" />

<add key="Project" value="[project_name]"/>

For this consider:

o [db_server]: The Database server.
o [port_number]: The port in which the Database service listens to.
o [service_name]: The Database service identifier.
o [user_schema]: The name of your Bizagi project (seen as the user schema).
o [schema_password]: The password for that user schema.
o [project_name]: The name of your Bizagi project for this environment.
Notice that this detail should refer to the database created with the Advanced Deployment procedure.

The following image illustrates the Scheduler's configuration file connecting to a SQL Server database:

It is important to make sure that the value for the Project key (<add key="Project"
value="[your_project_name]"/>) matches the name of your project which should match the folder' name
at <PROJECT_PATH>\[Your_project_name]

Save the changes and close the file.

Your <PROJECT_PATH>\[Your_project_name] structure should finally look like:

Page 301 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
4.4 Install the Scheduler service.
To install the Scheduler as a Windows service, create a file called BizAgi_[Project_name]
_Scheduler_Service_Install.bat with the following content:

CD /D "%~dp0"
C:\WINDOWS\Microsoft.NET\[framework_version]
\v4.0.30319\installutil /name=BizAgi[project_name]SchedulerService
BizAgi.Scheduler.Services.exe
NET START "BizAgi[project_name]SchedulerService"
pause

Consider:
· [project_name]: Is the name of your project.
· [framework_version]: Should be defined as framework64 or framework according to your Bizagi installation (32
or 64 bits).

Once you have created this file, run it with an administrator account to install the service. You may want to review the
log and the machine’s services to make sure that the service has been successfully created and that it appears listed
as available.

Page 302 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Right click on the Scheduler to select its properties and make sure it is started under the same identity and account
used by the IIS application pool:

Notice that at the end, the service called BizAgi[project_name]SchedulerService will need to be started.

5. Activate your license.

Activate your purchased license in which for this specific setup, you may activate licenses through a Bizagi which is
installed in a server within the same network as your test/production server.

Page 303 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 If you are setting up a clustered environment, please contact our support team.

At this point, you will be set with your Bizagi operating environment.

Additional steps
To administer your operating environment, keep in mind that you may use the Management Console, even from a
different server (it requires connectivity to the database).
By using the Management Console you may configure active parameters in production such as: the SMTP server,
URLs and systems involved in external Web services, ECM and Virtualized systems, among others.
To use the Management Console, keep in mind you need to install it in a server with network access to the project's
database.

When defining the documents repository of your project (where case attachments are stored), note that if you are
using a file server's shared folder then you will need to make sure that the service account described above (used
to startup the application pool and Scheduler), have read and write access to that folder.
Recall that if you are using a clustered setup having more than one node, then each node should be able to
access this shared folder with the required rights.

Best practices in the production environment

Overview
The Production environment (where your business processes are made available to your end users) is the most
critical environment that requires safe operations and adequate response times.
In this environment your processes must work at their best, to avoid disruptions, make sure the accuracy and
availability of information and provide the best user experience.

This section lists best practices for you to take into account when seeking the best operation of your processes in
the Production environment.

Governance best practices

Consider the following recommendations to help you carry out procedures related to Bizagi processes.

1. Avoid affecting end users

This is absolutely applicable when performing maintenance or system tasks. For example:

· Carry out system tasks integrating other systems, such as LDAP synchronization or Data replication, during
non-working or off-peak hours
When using LDAP synchronization to import your users into Bizagi, synchronizing records in parameter entities from
external data sources, or, in general, when having the system perform a task which involves in processing large
volumes of information, schedule the task to occur outside of work hours at best, at non-busy hours or at a time of
least throughput.
For LDAP synchronization, this is relevant when synchronizing more than 1000 users.

· Carry out Bizagi maintenance during non-working hours, plan and communicate accordingly.
Similarly, carry out any maintenance task affecting the availability of your processes, in an appropriate time frame
which reduce the effect on your end users.
Such tasks can involve: process deployments, version upgrades, database tuning, platform updates and patches,
and archiving information.

Page 304 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Maintenance tasks imply planned downtime. Plan the work, communicate, it to your team and coordinate such tasks
beforehand. Have contingency measures in place when applicable.

2. Enforce continuous improvement while minimizing risks

Continuous improvement is key to delivering your Bizagi processes, and leveraging flexibility along with the
dynamism of your evolving business.
However, when enforcing continuous improvement and performing round trips in your process definitions, review
which types of improvements/changes you need and how these may affect your running operations.
To approach continuous improvement with your Bizagi processes, consider classifying changes into these
categories:
· Changes affecting the process workflow (e.g., introducing new process paths/tasks; retiring paths/tasks which are
no longer needed).
· Changes affecting the data model (e.g., new attributes, entities or relationships).
· Changes affecting process logic (e.g., a modification in a business rule).
· All other changes (such as a modification in the user interface).
Such changes are usually considered minor.

Bizagi lets you to create a new version of the process as a whole, or new versions of its inner process definitions
(such as the user interfaces).
Creating a new version of the process separates process' definitions as well (clones them into the new version),
except for the data model.
Existing cases in a production environment continue to work on the process version with which they were created,
while new cases will always run under the latest process version.
Therefore, you need to decide if it is best for your scenario to create a new process version completely or simply
create a new version of the user interfaces.

Consider:

NEW VERSION OF WHEN IT IS RECOMMENDED

The process as a whole · When you need changes affecting the process
workflow.
· When you need major changes affecting the data
model (an important number of new definitions, or
discontinuing the use of some existing definitions).
· When you need changes affecting process logic and
you're not sure how the changes will affect the current
cases running in Production environments.

The user interfaces (forms) · When you need changes, which are usually considered
minor in user interfaces.
· When you need changes affecting the data model,
such as simply creating new definitions to have their
information captured in the user interfaces.
· When you need changes affecting process logic and
that is applicable to a rule which relies on information
within a form.

According to the above, you do not need to create a new version of the process, or of the user interface, if the
changes are considered minor and very specific; and you are sure that these changes will not create side effects for
cases running in production environments.

Configuration best practices

Consider the following recommendations to best configure certain Bizagi features.

1. Always use filters where applicable

Page 305 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
For instance when synchronizing users from LDAP, or when using Data replication or Data virtualization, rely on
adequate filters to narrow down the volume of information processed to what is actually needed.

2. Disable traces by default

For a production environment, it is really important to disable traces.
Traces provide a measure to follow up issues (should they arise) and, therefore, should be active only when needed
(after identifying that something needs to be diagnosed for a limited period of time).
We do not recommend continuously running traces in the Production environment, since trace files and logs can
grow a lot, thus generating performance problems (I/O contention).

3. Configure integrations adequately

When integrating with another service, repository or system in general, consider the recommended best practices
as available at https://help.bizagi.com/bpm-suite/en/index.html?what_to_avoid_in_interfaces.htm (such as setting
integrations in asynchronous activities, setting a reasonable timeout, and designing according to the volume of
information that is exchanged).

Performance and availability best practices

Consider carrying out these infrastructure measures to enhance performance and availability of your operations.
Consider:
· Setting up a Bizagi ODS (e.g., for best availability and performance of the Work portal for daily tasks).
· Configuring the SMTP service through IIS (for enhanced business continuity).
· Scaling out the Scheduler service (for high availability and scalability of the Scheduler).

For reference architecture, system requirements, sizing, growth and scalability details, and a complete overview of
best practices oriented to the infrastructure, refer to the complete System requirements chapter at
https://help.bizagi.com/bpm-suite/en/index.html?automation_systemreq.htm.

Security best practices

Consider carrying out security hardening for the Work portal, as described at Security hardening at the IIS.

Setting up a Bizagi ODS

Overview
Bizagi Operational Data Store (ODS) is an optional feature, designed and recommended to improve Automation
Server's performance and availability.
The concept behind Bizagi ODS is to avoid affecting the daily processes and Work portal performance with the
effort required for queries and analysis reports.

Through the Bizagi ODS, you create a read-only database replica to use for Process Analytics requests (such as
BAM and Analysis tasks) and to run queries.
This way, the resources involved for such purposes do not affect the transactional database to enhance its
availability.
This feature is especially powerful in mission-critical applications and whenever high volumes of information are
demanded to run analysis queries.

This feature is not eligible for Automation Server.

ODS configuration is not targeted for cloud environments since these environments already implement
architecture leveraging cloud native services that optimize separately, the process runtime operations and any
query to reports or analytics.

How does it work?

Through Bizagi ODS configuration, the BAM and Analytics or the queries module in the Work Portal make use of a
database which is a separate replica of the database used as the Processes repository.

Page 306 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This lets operations and requests executing queries with a large amount of data (such as the requests for Analysis
Reports for real-time monitoring or historical analysis), be carried out without using the resources employed for the
daily Process Activities.

The following diagram illustrates Bizagi ODS architecture:

Prerequisites
To use Bizagi ODS, you will need to configure replication for your Process repository (Bizagi project database).
Configure database replication at the database configuration itself, and requires different steps according to the
database engine used (SQL Server, Oracle).

Once this replication is set up, following the description and recommendations below in the ODS Configuration
Guidelines, setting up the ODS feature requires configuring the connection information in Bizagi (the connection
string) to that replicated database.

Useful information to accomplish database replication is available at these external links:

· For SQL Server 2008, 2008 R2: http://technet.microsoft.com/en-us/library/ms151198.aspx.

· For Oracle: http://www.orafaq.com/wiki/Advanced_Replication_FAQ

Page 307 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The following guidelines show what to keep in mind while configuring the replication for your Bizagi Processes
repository. For a detailed guide on the steps to achieve this, refer to Database documentation such as:
http://www.sql-server-performance.com/2010/transactional-replication-2008-r2/

Setting up a database replica is also helpful in business cases where you wish to integrate a reporting suite or other
BI tools, so these tools do not execute queries directly at the transactional database but use the replica instead.

ODS Configuration Guidelines

Proper configuration of a replicated database and any further security settings, are responsibility of the database
administrator.
This guideline is provided for best practices and requirements in Bizagi's ODS configuration:

1. Bizagi's database is the only publisher.

No matter how many intermediary distributors are used, the main database of Bizagi (Process repository) must be
the only one replicating its data into the ODS.

2. Near-real-time replication.
To have updated information for BAM reports, every action in the main system must be transmitted quickly to the
ODS.
For example, transactional replication achieves this in Microsoft SQL Server.

3. One-way replication.
Operations in the ODS must not affect the main Bizagi database. The ODS can be used to build aggregations,
temporal data, intermediary tables, or other data that is not necessary in the main system. For example,
transactional replication achieves this in Microsoft SQL Server.

4. Proper replication size estimation.

Given that some database-writing operations involve large data transactions (for example editing diagrams in Bizagi
Studio or uploading files to the web application), we recommend that you estimate an adequate approximate size
for the replication articles and configure them where necessary.
You can measure them in a test environment.
For example, for the Max Text replication Data option used in Microsoft SQL Server, 3 to 5 MB is usually sufficient.

5. Proper replication credentials.

Usually, the main database and the ODS reside in different database servers.
Use domain accounts such as the SQL Server Agent to run replication services.
Avoid accounts such as "Local System", because the credentials for this account have no access to shares on the
network, and it is not an authenticated network account.

Further information
Once you have set up your database replica, configure connectivity to the ODS in Bizagi.
You may do this separately for both features relying on this mechanism:
· Enable ODS for Process Analytics.
· Enable ODS to run queries.

Configuring ODS for Process Analytics

Overview
The Bizagi ODS is a powerful option that enhancing availability and performance of your transactional database.
Once you have set the database replica of your Bizagi database, proceed to configure the connection to such ODS
in Bizagi.
This is done by using Bizagi Management Console for any environment (Test or Production).

For introductory information and to review prerequisites for this option, refer to Setting up a Bizagi ODS.

Defining ODS for Process Analytics

Page 308 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Once you have set the database replication configuration for the ODS, configure the connection to the ODS in Bizagi
in the Bizagi Management Console for any environment (Test or Production) as described below.

1. Open the Environment options

To configure the ODS from the Management Console, select the Configuration tab and click the Environment
button to start Environment configuration.

This option is also available in Bizagi Studio for the Development environment:

Page 309 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. Locate the ODS Configuration
Under the Advanced options, an Operational Data Store sectionlets you to configure the connection to your
replicated database for this environment.

3. Configure the ODS connection

Configuration varies according to the server and platform running your processes.
When running Automation Server in a .NET platform, choose the Provider type and then provide the details.

For SQL Server, input the connection details:

· Server: The database instance where the ODS is at.
· Database: The replicated database (ODS).
· Login name: The login account used for the connection to the database.
· Password: The password for the login account used for the connection to thet database.

For Oracle, input the connection details:

· Service: The connection string to the Oracle database instance. Use [databaseServer]:[port]/[serviceName] syntax:
· Username: The user schema representing the replicated source.

Page 310 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Password: The password for the user schema.

Execution
Once this information is configured, Process Analytics queries executed in the Work Portal will be carried out against
the ODS, and without using other resources than those involved for the end users' daily activities.

Additional options
In addition to the previous option, Bizagi encourages the use of a query engine to support your ODS as a best
practice, boosting your BAM and Analytics modules even more.
To learn more about this possibility, refer to How to enable query engine ODS support.

Configuring ODS to run queries

Overview
The Bizagi ODS is a powerful option that enhances availability and performance of your transactional database.
Once you have set up a copy of your Bizagi database, configure the connection to the ODS in Bizagi.
Do this using the Bizagi Management Console for any environment (Test or Production).

For introductory information and to review prerequisites for this option, refer to Setting up a Bizagi ODS.

Defining ODS for Queries

To enable Query Engine support in Bizagi ODS, the Query Engine ODS parameters as you do with the Operational
data store configuration:

Page 311 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
For SQL Server, input the connection detail:
· Server: The database instance which is the ODS.
· Database: The replicated database (ODS).
· Login name: The login account used for the connection to that database.
· Password: The password for the login account used for the connection to that database.

For Oracle, input the connection detail:

· Service: The connection string to the Oracle database instance. Use [databaseServer]:[port]/[serviceName] syntax:
· Username: The user schema representing the replicated source.
· Password: The password for that user schema.

Important
· The replicated database is configured by the client. The client decides whether to keep the database replication
live.
· If the replicated database is currently offline, this feature automatically retrieves data from the operational project
database.
· Since the Query Engine only reads the database, there are no transactions. Hence, there is no control of commit
or rollback.
· Replicated databases must be from the same engine. Ie. SQLServer - SQLServer, Oracle - Oracle.

Page 312 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Configuring the SMTP service through IIS

Overview
Bizagi lets use an e-mail server to send notifications defined in Processes.
Specify the e-mail server's location in the Environment options of your Bizagi project.
However and as a recommended practice, in a production environment you should rely on an intermediate SMTP
service running on the local Bizagi server where Automation Server runs.

Advantages of using such intermediate SMTP service (a relay service) as a bridged connection to your corporate
SMTP server, include:
· The need to use authentication to relay to the corporate SMTP server.
· You may also use a different SMTP port number than the default one (port 25), or implement TLS.
· The possibility of business continuity in your processes (if the SMTP Server is temporarily off-service, processes in
Bizagi will continue leaving notifications in queue at the IIS).
· Improved traceability and monitoring for process notifications, obtaining additional stats, and the use of a store
and forward mechanism.

In some scenarios, you may even consider using the intermediate SMTP server on a different server other than the
Bizagi server. This is not ideal, but is useful when the Bizagi server has no direct access to your corporate SMTP
service.

For processes running in Windows operating systems, thee local SMTP service is provided by the IIS which may
be enabled directly at the Bizagi server.

Page 313 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This section shows how to install the SMTP Server service provided by Internet Information Services (IIS), and
configure to work with Bizagi by relaying messages to your corporate SMTP (applies when processes are running
on a Windows platform).

Prerequisites
To use and set the SMTP Server service from the IIS, make sure you have the required features and role services
installed.
SMTP service is available only for Windows server operating systems (such as Windows Server 2012 and 2008).

Installation of the SMTP Server feature is done through the Server management options:

This requires additional server roles from the IIS Web server (such as the IIS 6 Management console and Remote
Server Admin Tools):

Once this feature is installed, make sure that the SMTP service is running, and set to start in automatic mode:

Page 314 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
What you need to do
Once you have the SMTP service installed, carry out the following steps to setup a relay to your corporate server:

1. Configure the SMTP server in the IIS

2. Create a domain for the SMTP server
3. Configure e-mail server parameters in Bizagi

Procedure
Follow the steps described below.

1. Configure the SMTP server in the IIS

1.1. Launch IIS Manager 6.0
Configure the SMTP service through the IIS 6 Management Console (even when you have a newer version of IIS).
You can use the Start -> Administrative Tools -> Internet Information Services 6.0 option to lanuch it, or use the
Server management options.

Page 315 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
1.2. Configure the SMTP server properties
We strongly recommend that you adjust the settings to comply with best security practices.
To verify the settings, right click and select properties:

Page 316 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Review the following configuration:
· Authentication should be anonymous access:

Page 317 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Connection should be allowed only from the Bizagi server (in this case it is local, and is referred to as localhost):

· Relay should be allowed only from the Bizagi server (localhost):

Page 318 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· For the Messages options, tune the parameters to configure: allowed limit message size (according to your
permitted and expected increment in file size put by e-mail attachments), allowed limit session size (similar to the
previous parameter, but for grouping more than one e-mail in the same activity or Bizagi transaction), limit
number of messages per connection to (similar to the previous parameter, but limiting the number of messages
when grouping more than one e-mail instead of using file size as criteria), and limit number of recipients per
message to (sets the maximum number of recipients in a same e-mail).

Review whether your processes in Bizagi send e-mail notifications which may exceed the default settings.

Page 319 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
For Delivery options,
· Under the delivery settings, specify the outbound security employed to authenticate against your corporate SMTP
server:

Page 320 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Use the Advanced options to specify the location of your corporate SMTP server (as the smarthost to relay to).
Enter a server name or use IP addresses inside of squared brackets (as [xxx.xx.xx.xx])

2. Create a domain for the SMTP server

2.1 Create a new domain
To follow best practices, create an SMTP domains to handle notifications from your Bizagi processes.
To start, right-click Domains and select New->Domain.

Page 321 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2.2 Specify that it is a remote domain
Choose Remote as the domain type and click Next.

2.3 Name the domain accordingly

Name this domain to match the domain of your sent notifications, and click Finish.

Page 322 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2.4 Set further options for the domain
Right-click the newly created domain and select Properties.

This SMTP server should be the one authorized to send e-mail notifications (make sure that Allow incoming mail to
be relayed to this domain is enabled).
It needs to support relay.
Configure outbound security as needed, according to the credentials you need to provide to your corporate SMTP
server.

In the Route Domain box of the properties window, select Forward all mail to Smart Host.
Enter the name of your corporate SMTP Server, or enter its IP address within square brackets "[ ]".

Page 323 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click OK.
For more information about SMTP domains, refer to Microsoft's official documentation at
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/e2156172-7118-4ff2-9a6a-
1b7dd52580fa.mspx?mfr=true.

Finally, make sure that the service is still in a started mode after you have completed your changes:

3. Configure the E-mail server parameters in Bizagi

Once the SMTP is setup, configure the environment parameters for your Bizagi project.
In the production or testing environments you may do this through the Bizagi Management Console as provided by
Automation Server. Reference the local server (localhost) as the SMTP server.

For this part, provide information for the Email configuration section.
Check the Enable mail check box and specify a sender account that uses the expected domain:

Page 324 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click OK to save changes and make sure you perform an IISReset on your IIS.

Scaling out the Scheduler service

Overview
Each Bizagi project needs an installed service called the Scheduler on its Automation Server.
The Scheduler is a Bizagi agenti 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 refering 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:

Page 325 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
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:

Page 326 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 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:

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

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

Page 327 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
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:

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

2. 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. 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:

Page 328 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
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.

Page 329 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
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:

Page 330 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
In the end, you should see your additional Scheduler services installed and listed among your Windows services:

Page 331 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Do not start the multiple services at this point, as you need to edit their configurations first.

2. 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"/>

Page 332 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 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.

Page 333 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 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.

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.

Setting up a load balancer

Overview
When setting up a cluster to provide high availability for the Bizagi Work portal, you will need to ensure that you
configure a load balancer to route requests to the different servers of your cluster.
To configure your load balancer you may configure a hardware-based load balancer such as f5, along with specific
aspects (such as Sticky sessions).

Further information
Refer to the respective guidelines according to the option you choose:
· Setting up an f5

Example setting up an f5

Overview
When setting up a cluster to provide high availability for the Bizagi Work portal, you will need to ensure that you
configure a load balancer to route requests to the different servers of your cluster.
Bizagi recommends the use of a hardware-based load balancer such as f5, along with specific aspects for you to
consider when configuring this load balancer.

Configuration requisites
The important aspects you will need to consider are:
1. The use of a “sticky” mechanism in f5 for the persistence profile, such as destination address affinity
persistence.
2. The use of a load balancing algorithm in f5 which takes advantage of your servers as much as possible, such as
the round robin method.

Before you start

Consider that through the steps listed below, you will simply set up the f5 load balancer.

Page 334 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This means that you know which Bizagi servers you will be employing for a clustered setup (ideally you should have
by now configured your Bizagi Work portal in all servers and activated applicable licenses).

Configuring f5 load balancing.

Follow these steps to configure both destination address affinity as the persistence profile, and a round robin
algorithm in f5.

1. Browse into the Main tab of the f5 configuration and locate the Local traffic group.
2. Go into Pools and click the icon next to Pool list to add a new one.

3. Give a Name to the pool (plus a meaningful Description if you wish), and ensure you choose https as the Active
protocol to involve in the Health Monitors configuration.

4. At this point you may also choose to set Round Robin as the Load balancing method (alternatively you may
choose another method which best considers your servers capacity).

Page 335 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
5. Use the New Node option to specify the Node Name and Address for each of the Bizagi servers making up your
cluster.
Ensure you set the Service port and protocol accordingly as well (i.e., 443, using HTTPS).

6. When done, click the Add button so that the server is registered as a node belonging to the actual pool and
shown in the table below.
Recall that you need to do steps #5 and #6 for each of the servers of your cluster so that in the end, you have them
all registered and displayed in the table of Nodes.

7. Click Finished when done.

8. Back in the Main tab and Local traffic group, locate the Virtual Servers and click on the icon next to Virtual
Server List to add a new one.

Page 336 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
9. Give a Name to the virtual server (plus a meaningful Description if you wish), and ensure you specify: The
Destination Address/Mask (IP as how you wish end users to target Bizagi) and the Service Port specs (port
number and protocol; i.e., 443 using HTTPS). You may leave other settings with default values.

10. Next at the HTTP Profile configuration, ensure you select http for the HTTP Profile.
11. Ensure you select your corresponding SSL certificate for the SSL Profile (Client) configuration, and you may
select serverssl as the one applicable to SSL Profile (Server) configuration. Choose Auto Map as the value for
Source Address Translation.

Page 337 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
12. For the Default Pool setting, ensure you select the pool you created previously (steps #3-5), and leave the
default dest_addr option for the Default Persistence Profile.
Click Finished when done.

Page 338 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Important
This guide seeks to illustrate those main aspects and requirements needed for an f5 load balancer to work with
Bizagi (i.e., a “sticky” mechanism for persistence, and a load balancing method/algorithm which attempts to route
requests as evenly as possible to all servers in a cluster), according to vendor’s best practices.
This guide is not comprehensive as to illustrating all steps possibly needed for a f5 configuration or further tuning
as per customer’s specific settings. Specific order of steps or user interfaces presented may vary according to the
employed f5 version.

For additional and complete f5 information, refer to f5’s official web site.
For instance, refer to:
· https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-profiles-reference-12-1-0/4.html for
details about the different Persistence profile types
· https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-concepts-11-5-0/5.html for load
balancing methods and overall pool features and settings.

Security hardening at the IIS

Overview
When you have an application in a production environment, it is important to consider best practices that provide
an adequate level of security.
Such best practices include the configuration recommendations issued by the vendor of the application, but within
these you should also adapt best practices that suit your infrastructure setup and that apply to your whole
company.

We recommend that you commit to and enforce compliance with the guidelines and procedures as set by the
policies and standards related to information security. This way, aspects regarding control, monitoring, auditing and
other features, are included within the definition of what constitutes application security.

Bizagi deploys a Work portal for end users to use, as a web application.
Therefore, Bizagi Ltd strongly recommends implementing the necessary measures for application hardening in every
project, to mitigate certain risks and vulnerabilities from which web applications are not exempt from.

Recommendations
Follow the detailed recommendations described in the links below. They are presented as basic, intermediate or
advanced recommendations.
For most projects, the most common risks are mitigated by carrying out the basic recommendations.

· Basic recommendations
· Intermediate recommendations
· Advanced recommendations

Basic hardening

Overview
This section presents security recommendations to apply in Bizagi Work portal related to Bizagi's configuration
(application hardening).
You should be authorized to work with security of access and configuration of your premises and equipment,
appliances or components involved in the complete solution which are not integral parts of Bizagi, such as: the
network and storage, firewalls, load balancers or other appliances, and other servers such as domain controllers or
database servers.

For more information regarding the scope of these recommendations, refer to Security setup recommendations.

Page 339 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 The following recommendations apply when Bizagi is running on a .NET platform, independently from the Web
server IIS version on which it runs.
In this section, the recommended configuration presumes an IIS Web server version 7.5, and hardening is carried
out according to IIS capabilities.

Before you start

Keep in mind the following considerations:

Considerations regarding the platform

Always review and apply recommendations issued by Microsoft, the vendor of the base platform on which Bizagi
runs for .NET environments.
Consider bulletins and notifications about fixes and patches announced by Microsoft regarding your Windows OS
or the IIS.
Remember to carry out proper tests after applying fixes and patches to verify you are not affecting your Bizagi
project.

Considerations regarding the database

For a higher level of security regarding data access, Bizagi lets you configure the service account which is used to
configure database access through the Work portal and the Scheduler service to have the minimum required rights.
For more information about the setup of these accounts, for instance when using SQL Server, refer to SQL Server
prerequisites.

Considerations regarding authentication in Bizagi

Before you continue with the web-related configuration recommendations for the Work portal, make sure you
establish security policies for passwords (password formation and length, duration, and other elements for
protection and compliance with network security requirements).
When using local authentication for Bizagi, configure the relevant parameters to cover such policies, as described at
Bizagi authentication.

We recommend that you set up as a minimum the following parameters:

· Enable Lock Account: On
· Enforce Password change: On
· Enforce Password History: On
· Log Authentication Events: On
· Max Logon Attempts: 3
· Password expiration time: 30 days, or according to your criteria.
· Password minimum length: 8 characters, or according to your criteria.
· Password must have letters: On
· Password must have capital letters: On
· Password must have small letters: On
· Password must have numbers: On
· Password must have special characters: On
· Session Time: 5 minutes.
· Verify Password Sequences: On
· Password block time: According to your criteria.
· Blocked account duration: According to your criteria.
· Duration to restart failed attempts: According to your criteria.

Considerations regarding the system user in Bizagi

Recall that domain\admon is the system user created by default and employed internally by Bizagi.
Neither Username nor password should be changed for this user.
You may not disable this user since it is needed to perform automatic tasks related to processes such as timers and
scheduled jobs. We recommend you to make sure that this user is always enabled in your project.

Page 340 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
We strongly recommend that you edit this user's settings so that it that it does not have access to administration
options in the Work portal (it should be able to start specific processes and run tasks, but not a full admin).
To make sure this exclude this user from those authorized to manage your Bizagi system (This user should not be
able to manage users, nor modify values in Bizagi such as parameter entities, cancel or delete cases, etc).

Basic recommendations
Follow the configuration recommendations to mitigate most vulnerabilities.
These apply to your testing and pre-production environments as well (when using one).

For the next steps, make sure you have installed the IIS component World Wide Services -> Security -> Basic
Authentication, and IP and Domain restrictions (when installing IIS).

1. Using the HTTPS protocol

We strongly recommend that you configure your Bizagi Work Portal using the HTTPS over TLS protocol.
To do this, make sure you have a valid certificate for your server which registers to your server's domain.

Once you have a valid certificate for your server, register it for the Bizagi Work portal by using the Server
certificates option for the IIS Server:

Once the server is registered, specify the bindings in the Work portal's web site (by default, at Default Web site):

Page 341 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
For the bindings, you will be able to specify HTTPS use, with its secure port, and select the appropriate registered
certificate.
Click OK to save this configuration.

When using HTTPS, consider editing the web.config file to specify <add key="PROTOCOL" value="HTTPS"/>.
This applies when using case links in process notifications, as described at Notifications using case links.

Secure Protocols
The Bizagi Work Portal supports the following protocols:

· SSL 2
· SSL 3
· TLS 1.2

We strongly suggest to use the TLS 1.2 secure protocol and deactivate the others.

To activate the TLS 1.2 protocol in your IIS server you must follow these steps:

1. Backup your registry files

Open the Registry Editor typing Regedit in the search option of your windows. From the File tab, select Export, and
save the reg file from all branches.

2. Add the TLS 1.2 key

In the Registry editor, navigate to this location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Proto
cols

Include the TLS 1.2 key under Protocols folder. This look like a new directory under the Protocol folder.

3. Create two keys in the TLS folder.

Page 342 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Right click the TLS 1.2 folder and create the Client and Sever key.

4. Create values
Right click the right panel and create the DWORD values under both Server and Client keys as follow:

DisabledByDefault [Value = 0]
Enabled [Value = 1]

5. Disable TLS and SSL older versions

under the same location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Proto
cols

locate the DWORD values of TLS 1.0 , 1.1 and SSL 3.0 and set the Enabled value to 0.

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 in the web.config file of the Work Portal:

<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

Page 343 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
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 OR Use TLS 1.2.

Google Chrome
1.Connections are automatically negotiated at the highest grade.
2. 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.

2. Filtering unauthorized requests

We recommend you to identify the gateway from which your end users access the Bizagi Work portal.
This way, you can use a range of valid IP addresses to filter HTTP requests to your application.

To do this, include a white list of IP addresses authorized to access the Bizagi Work portal at the site level (you may
even specify an authorized domain).
Use the IP Address and Domain restrictions option:

Similarly, you may rely on Web Application Firewall products to harden security to access Bizagi (to rely on
additional features such as those oriented to intrusion detection, etc, and to consider corporate policies to secure

Page 344 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 your application especially when having Bizagi setup for internet access).

When using a DMZ, make sure that both the inside and outside firewalls do not allow indiscriminate access through
firewall configuration and ports.

Important
For Bizagi, security is an aspect of critical importance.
Therefore, Bizagi periodically releases new versions which feature improvements and fixes for issues detected in
previous versions.
Fixes for those detected issues may include specific solutions for identified security vulnerabilities.

We strongly recommend you to consider a periodic upgrade to Bizagi's latest releases for your solution, by always
following the usual guidelines for an upgrade procedure, including:
· Plan, coordinate and appropriately test these upgrades.
· Rely on an array of environments (development, testing, pre-production when applicable, and production).
· Take proper contingency measures (e.g backups) before upgrading.
· Evaluate customizations or additional security configurations such as the ones listed above, so that stakeholders
are aware that it is part of the plan to reconfigure certain components after the upgrade.

When having customizations or applying hardening measures such as the ones above, follow one of these two
alternatives when carrying out a version upgrade:

1. If doing the upgrade through Bizagi Management Console, you will need to reconfigure and verify that such
measures are still applied after the upgrade. We recommend backing up customizations before starting the
upgrade.
By default, an upgrade carried out through the Management Console will not check whether you have done
modifications to the original files and file structure.

2. You may choose to do the upgrade through a manual procedure (without using the Bizagi Management
Console).
If you do, consider all the relevant components and files that you need to replace manually for the Work Portal
and Scheduler, while avoiding overwriting your configured customizations or the already applied hardening
measures.

For highly critical security issues, Bizagi may consider issuing hot fixes and recommend that you apply them without
awaiting for a newer version.

To evaluate or consider additional application hardening aspects, refer to Intermediate recommendations.

Intermediate hardening

Overview
This section presents security recommendations to apply in the Bizagi Work portal regarding aspects which are
relevant to Bizagi's configuration (application hardening).

To carry out the recommendations presented below, you should have already followed what is described in Basic
recommendations.

The following recommendations apply when Bizagi runs on a .NET platform, independently from the Web server
IIS version on which it runs.

Page 345 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 This section describes the recommended configuration for an IIS Web server version 7.5, and such hardening is
carried out according to the IIS capabilities.

Intermediate recommendations
These apply to your testing or staging environment as well.

For the next steps, make sure you have installed the IIS components World Wide Services -> Security -> Basic
Authentication, and IP and Domain restrictions (when installing the IIS).

1. Encrypting information using HTTPS

Include the following element in the web.config file of your Work portal (by default, located at C:
\Bizagi\Projects\[your_project]\WebApplication\) to encrypt cookies.
Include in the <system.web> element the following line:
<httpCookies httpOnlyCookies="true" requireSSL="true" />

You may verify the proper configuration by logging to the Work portal and using a tool of your choice to inspect
how cookies are obtained (e.g. by means of Google Chrome's developer tools):

In the same web.config configuration file in your Work portal, edit the definition for <pages>, so that the ViewState
attribute always uses encryption. This action secures the information dictionary as described at
https://msdn.microsoft.com/en-us/library/ms178199(v=vs.85).aspx.
To do this, locate the pages element having:
<pages controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID" />
And include:
viewStateEncryptionMode="Always"

Save the changes and close the file.

2. Including additional protection in Bizagi web services

By default Bizagi includes its built-in web services in the .\WebApplication\WebServices\ folder (inside the default
path at C:\Bizagi\Projects\[your_project]\).
There are two types of web services published at this location: business-oriented web services which make up
Bizagi's API, and web services which provide functionality used internally by Bizagi.

We strongly recommend that you provide an additional layer of security to restrict access to these web services,
and to use separate folders for the two types of web services to implement different security measures for each.
You may even leave as inaccessible the business-oriented web services if your project will not be using them.
Even though you should use HTTPS configuration, you should explicitly configure the web services' folder and
access with the measures described in the table below.

Service type Actions

Page 346 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Web services for internal Define an IP whitelist which only includes the local Bizagi server's IP, as an
purposes of Bizagi authorized server allowed to access these web services..

Web services which are part Define an IP whitelist which only includes the identified and authorized external
of Bizagi API (business servers (or an IP range), as those allowed to invoke web services in Bizagi.
oriented)
Configure basic authentication to access these web services. This way, external
application would need to authenticate prior to invoking web services in Bizagi.

To do this, follow these steps:

· Separate the Web services

Separate those internal services from those which provide integration capabilities.
Internal Web services are: Cache.asmx, WFEQuery.asmx and WFAsynch.asmx.

To do this, create a new folder in the Web application's structure provided in Bizagi's Work portal (by default at C:
\Bizagi\Projects\[your_project]\WebApplication\).
You can name this folder SOAPservices (or a different name of your choice):

Move all of the files located at the .\WebApplication\WebServices\ folder except Cache.asmx, WFEQuery.asmx and
WFAsynch.asmx, into this new folder:

Page 347 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Once you are done, verify that only Cache.asmx, WFEQuery.asmx and WFAsynch.asmx, are still located at the .
\WebApplication\WebServices\ folder.

· Set Basic authentication for the Web services for integration

Configure the IIS, so the .\WebApplication\SOAPservices\ folder containing Bizagi's Web services which promote
application integration (i.e, WorkflowEngineSOA, EntityManagerSOA, QuerySOA), uses basic authentication.
Through this setting, external applications invoking these services will need to specify basic authentication
credentials (user, password).

To do this, enable Basic Authentication and make sure Anonymous authentication is disabled for that folder:

Make sure that users allowed to access this content are granted privileges to its physical path (according to your
registered domain).
For this grant permissions for the SOAPservices folder:

Page 348 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click OK to save this configuration.

You can even leave as inaccessible the business-oriented web services, or delete them, if your project will not use
them.
When setting basic authentication for web service access, make sure that your other applications invoking such
services will be able to authenticate.

· Set an IP whitelist to access Web services

For the IIS configure that:
o The .\WebApplication\WebServices\ folder containing Cache.asmx, WFEQuery.asmx and WFAsynch.asmx, is
accessible only by authorized IP addresses (in this specific case, only by the local server).
o The .\WebApplication\SOAPservices\ folder containing business-oriented web services is accessible only by
authorized IP addresses or an IP range of addresses (in this specific case, those IPs belonging to the external
application invoking Bizagi).

To do this, include each allowed IP address explicitly by using the IP and Domain restriction feature in the IIS:

Page 349 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
For the whitelist approach to work, make sure that your default feature settings deny access for unspecified clients
(choose Deny):

Click OK to save this configuration.

3. Delete unused folders in the production environment

We recommend that you delete the folders whose use is oriented to the development environment.
This action is to avoid leakage of code information (a vulnerability known as Source code leakage).

You may delete the following folders located inside the jQuery folder (by default C:\Bizagi\Projects\[your_project]
\WebApplication\jquery):
· automatictesting

Page 350 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· editor
· rendering
· renderingflat
· reporting
· testmobility
· workportal
· workportalflat

Delete as well:
· Readme.txt located at the desktop templates (by default at C:\Bizagi\Projects\[your_project]
\WebApplication\jquery\overrides\templates\desktop\Readme.txt).
· Login.aspx located at the Admin folder (by default at C:\Bizagi\Projects\[your_project]
\WebApplication\Admin\Login.aspx).

Important
For Bizagi, security is an aspect of critical importance.
Therefore, Bizagi periodically releases new versions which feature improvements and fixes for issues detected in
previous versions.
Fixes for those detected issues may include specific solutions for security vulnerabilities.

We strongly recommend that you consider a periodic upgrade in your solution to Bizagi's newest releases, by
always following the usual guidelines for an upgrade procedure such as:
· Plan, coordinate and test appropriately all upgrades.
· Rely on your different environments (development, testing, pre-production when applicable, and production).
· Take proper contingency measures (e.g. backups) before starting the update.

Page 351 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Evaluate customizations or additional security configurations such as the ones listed above, so stakeholders are
aware that it is part of the plan to reconfigure certain features after the upgrade.

When you have customizations or applying hardening measures such as the ones above, follow one of two
alternatives when carrying out a version upgrade:

1. If upgrading through the Bizagi Management Console, reconfigure and verify that such measures are still
applied after the upgrade (we recommend backing up customizations before starting the upgrade).
An upgrade done through the Management Console will not check whether you have done modifications to the
original files and file structure.

2. You may upgrade through a manual procedure, without using the Bizagi Management Console.
If you do, consider all the relevant components and files that you need to replace manually for the Work Portal
and Scheduler, while avoiding overwriting your configured customizations or the already applied hardening
measures.

For highly critical security issues, Bizagi may issue hot fixes and recommend that you apply them without waiting for
a newer version.
To evaluate or consider additional application hardening aspects, refer to Advanced recommendations.

Advanced hardening

Overview
This section presents security recommendations to apply in the Bizagi Work portal which are relevant to Bizagi's
configuration (application hardening).

To carry out the recommendations presented below, you should have already followed what described at
Intermediate recommendations.

The following recommendations apply when Bizagi runs on a .NET platform independently from the Web server
IIS version on which it runs.
In this section, we describe the configuration for an IIS Web server version 7.5, and such hardening is carried out
according to the IIS capabilities.

Advanced recommendations
These apply to your testing or pre-production (when you use one) environments as well.
This section presents specific steps to mitigate a range of vulnerabilities.

For some of these steps, make sure you have installed the URL Rewrite module for the IIS.
The module in its 2.0 version (for IIS versions 7, 7.5 and 8) is a plugin that can be downloaded directly from
http://www.iis.net/downloads/microsoft/url-rewrite.

1. Rewriting values in server variables

We recommend that you configure rules that rewrite certain values which may leak information regarding the server
(this action seeks to mitigate the vulnerability known as information leakage).
Values providing IIS server information are disclosed by default in the following variables: RESPONSE_SERVER,
RESPONSE_X-ASPNET-VERSION, and RESPONSE_X-POWERED-BY.

Page 352 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
To rewrite these values, perform the following steps:

Use the URL Rewrite option for the Bizagi Work portal (at the site folder level). Select View Server variables to
make sure you have placed those three variables to rewrite:

Use the Add option three times to include the variables one by one. In the end you should be able to see them all
listed:

Page 353 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Next, click Back to rules to add the rules that will rewrite values.
For each variable (RESPONSE_SERVER, RESPONSE_X-ASPNET-VERSION, and RESPONSE_X-POWERED-BY), click
Add rule(s).. and select the blank type of rule for the Outbound category.

Page 354 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The properties for each rule will be :
· Name: A name according to your choice.
· Precondition: None.
· Matching scope: Server variable.
· Variable name: Enter the name of the corresponding variable to rewrite (RESPONSE_SERVER, RESPONSE_X-
ASPNET-VERSION, or RESPONSE_X-POWERED-BY).
· Variable value: Matches the pattern.
· Using: Regular expression.
· Pattern: .+
· Ignore case: On.

· Action type: rewrite

· Value: EMPTY.
· Replace existing server variable value: On

Page 355 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You should be able to see the rules listed for the three variables:

Similarly, from a browser, you should be able to inspect these values as sent by the server:

2. Using secure headers

We recommend that you establish secure headers to avoid disclosing information which may be used for potential
attacks (to mitigate a vulnerability known as ClickJacking).
Configure the header by using the following values:

Page 356 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Header Value

x-content-type-options nosniff

x-dns-prefetch-control off

x-frame-controls SAMEORIGIN

x-xss-protection 1; mode=block

Strict-Transport-Security Strict-Transport-Security: max-age=31536000; includeSubDomains

content-security-policy default-src: ‘self

NOTE: Here you may add URLs different from the application URL (depicted as
"self"). For more information, refer to
https://www.owasp.org/index.php/Content_Security_Policy

To accomplish this, perform these steps:

Use the HTTP Response Headers option for the Bizagi Work portal (at the site folder level), to add each header with
the value as listed above, using the Add option:

Once you have done this, you should be able to see them all listed:

Page 357 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Important
For Bizagi, security is an aspect of critical importance.
Therefore, Bizagi periodically releases new versions which feature improvements and fixes for issues detected in
previous versions.
Fixes for those detected issues may include specific solutions for security vulnerabilities.

We strongly recommend that you consider a periodic upgrade of your solution to Bizagi's newest releases, always
following the usual guidelines for an upgrade procedure such as:
· Plan, coordinate and appropriately test each upgrade.
· Upgrade all environments (development, testing, pre-production when applicable, and production).
· Before starting the upgrade, take proper contingency measures (e.g backups).
· Evaluate customizations or additional security configurations such as the ones listed above, so stakeholders are
aware that it is part of the plan to reconfigure certain features after the upgrade.

When you have customizations or have applied hardening measures such as the ones above, follow one of these
options when carrying out a version upgrade:

1. If you use the Bizagi Management Console, back up your customizations before starting. After the upgrade,
reconfigure each measure and verify they are still applied.
By default, an upgrade done through the Management Console does not check whether you have done
modifications to the original files and file structure.

2. Do the upgrade through a manual procedure (without using Bizagi Management Console).
If you do, consider all the relevant components and files that you need to replace manually for the Work Portal
and Scheduler, while avoiding overwriting your configured customizations or the already applied hardening
measures.

For highly critical security issues, Bizagi may issues hot fixes and recommend that you apply them without waiting for
a newer version.

Infrastructure alternatives

Overview
If you set up your Bizagi project using Automation Server, you have options regarding the infrastructure you
provision, according to your specific requirements.

Page 358 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Further information
Consider the following guidelines for such alternatives:
· Setting up Bizagi in an Azure VM.
· Setting Bizagi for secure internet access (via a reverse proxy in a DMZ).

Setting Bizagi in an Azure VM

Overview
If you own an Azure subscription, you can set up Bizagi to run in the cloud. This article describes the steps and gives
you hints on how to create and set up your Azure virtual machine so you can install and run Bizagi in your server.

When setting up Bizagi in the cloud, we recommend deployment of processes through the Advanced Deployment
tool, so processes are deployed through packages in an offline manner.

What you need to do

To use the Bizagi Virtual Machine in Azure, follow these steps:
1. Create an Azure virtual machine
2. Configure the virtual machine
3. Install Bizagi in that virtual machine

Procedure
Follow the steps detailed below.

1. Create an Azure virtual machine

You can create your Azure virtual machine by following these steps.

1.1. Log in into your Azure account.

1.2. Select New > Compute > Windows Server

Page 359 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
1.3. Set your server's basic settings: Name, User name and password (to access the VM), Subscription, Resource
group and Location. Once you're done, click OK.

1.4. Next, select your server's size by clicking the "Select" button. We recommend you choose a server with a RAM
over 8GB and Local SSD over 10GB.

1.5. Leave the configuration settings on their default values and click OK.

Page 360 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
1.6. Finally, click the "Create" button to create your new virtual machine.

2. Configure the virtual machine

To configure your VM, go to the Virtual machines menu and make sure your machine is running; if it is not, select it
and click Start.

Page 361 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Then, go to your virtual machine's dashboard and click Connect, to start a download of an .rdp file that will let to
log in to your virtual machine.

Use the credentials (username and password) that were entered at Basic Settings.

Page 362 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Once logged in, go to "Server Manager" and click "Add roles and features".

Click Next, make sure "Role-bases or feature-based installation" is selected as installation type. Click Next.

Page 363 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Select as destination server the virtual machine you created. Click Next.

Page 364 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Select the roles: Net framework 3.5 and 4.5, remote server administration tools (Web Server IIS), SMTP server. Click
Next.

Page 365 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Next.

Page 366 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Check that the IIS Role services are selected. Click Next.

Page 367 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Install on the confirmation window.

Page 368 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Once the Installation is done click Close.

3. Install Bizagi in that virtual machine

At this point, you are done setting up the platform where Bizagi will run.
You may install Bizagi (as you would normally do).
For a testing or production environment, use Advanced Deployment to publish processes.

Setting Bizagi for secure internet access

Overview
This section describes how to set up a secure HTTP server for your Bizagi processes, so that they can be accessed
securely via the internet.
Automation Server supports access from both an intranet and an extra net with proper security measures, by using
a reverse proxy architecture.

By following this guide you can implement a reverse proxy for your Bizagi project, using an Apache HTTP server and
secure socket layer (SSL) encryption so that any device can access the Bizagi Work portal.

The following represents the considered set up:

Page 369 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Page 370 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This proxy server is set up so that access from Internet is redirected in a securer manner to your Bizagi server, while
users in the intranet continue to access the Bizagi web application from the inside.

Using Apache HTTP Server

To use Apache HTTP Server, install it in your DMZ and configure it according to the sections below.

Installing Apache HTTP Server

To install Apache as the server to access Bizagi, follow these steps:

1. Download Apache HTTP Server. Find the latest available version according to your chosen server in the Apache
HTTP Server official webpage.

2. Install the server. Notice that the prompted configuration parameters may be modified later. Your chosen path
for the Apache HTTP Server will be addressed from now on as <APACHE_HOME>.

Secure and advanced configuration in Apache

To enable secure and advanced modules in Apache to provide reverse proxy access your Bizagi project, follow
these steps:

1. Locate the Apache configuration file.

Edit the httpd.conf file located at <APACHE_HOME>\conf\ as described below.

This file may be edited too in Windows by accessing the option through Start -> All Programs -> Apache HTTP
Server 2.2 -> Configure Apache Server -> Edit the Apache httpd.conf configuration file.

Page 371 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. Enable the necessary proxy modules.
Remove the leading "#" character from these lines:

LoadModule proxy_module modules/mod_proxy.so

LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so

To enable and use SSL, remove the "#" character from the following line:
LoadModule ssl_module modules/mod_ssl.so

Page 372 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
For further and complete guide information about the Apache proxy module, refer to the official documentation.

To use it SSL, enable its port by including the following line, found under the listening options (optional):
Listen 443

The default Listen option uses port 80, but 8080 is also often used.

Page 373 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
3. Configure the reverse proxy settings.
Include the definition of the reverse proxy. Verify that you are using SSL.

If your Apache HTTP Server will not use a digital certificate and SSL was not enabled, include the following lines at
the end of the file:

<VirtualHost [APACHE_IP]:[APACHE_PORT]>
ServerName [BIZAGI_SERVER]
# Proxy configuration
ProxyRequests Off
ProxyPreserveHost On

ProxyPass /[YOUR_PROJECT]/jquery http://[BIZAGI_SERVER]/[YOUR_PROJECT]/jquery

ProxyPass /[YOUR_PROJECT]/Charts http://[BIZAGI_SERVER]/[YOUR_PROJECT]/Charts
ProxyPass /[YOUR_PROJECT]/css http://[BIZAGI_SERVER]/[YOUR_PROJECT]/css
ProxyPass /[YOUR_PROJECT]/img http://[BIZAGI_SERVER]/[YOUR_PROJECT]/img
ProxyPass /[YOUR_PROJECT]/js http://[BIZAGI_SERVER]/[YOUR_PROJECT]/js
ProxyPass /[YOUR_PROJECT]/Localization http://[BIZAGI_SERVER]/
[YOUR_PROJECT]/Localization

ProxyPass /[YOUR_PROJECT] http://[BIZAGI_SERVER]/[YOUR_PROJECT]

ProxyPassReverse /[YOUR_PROJECT] http://[BIZAGI_SERVER]/[YOUR_PROJECT]
</VirtualHost>

For these lines, provide the appropriate values:

· [APACHE_IP]: The IP address to access your Apache service.
· [APACHE_PORT]: The HTTP port under which Apache service recive requests.
· [BIZAGI_SERVER]: The server which hosts your Bizagi project (on which Automation Server runs).
· [YOUR_PROJECT]: The virtual directory of your Bizagi project.

For instance, if your Bizagi project is named MyProject, the configuration for the file should be (assuming an Apache
installation attending at port 80):

Page 374 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
On the other hand, if your Apache HTTP Server will use a digital certificate and SSL was enabled, it is necessary to
configure a virtual host by including the following lines:

NameVirtualHost *:443

<VirtualHost *:443>

DocumentRoot "<APACHE_HOME>/htdocs"
ServerName [BIZAGI_SERVER]

<Directory "<APACHE_HOME>/htdocs">
Options Indexes FollowSymLinks MultiViews
AllowOverride None
SSLRequireSSL
Order allow,deny
Allow from all
</Directory>

SSLProxyEngine on

ProxyRequests Off
ProxyPreserveHost On

ProxyPass /[YOUR_PROJECT]/jquery http://[BIZAGI_SERVER]/[YOUR_PROJECT]/jquery

ProxyPass /[YOUR_PROJECT]/Charts http://[BIZAGI_SERVER]/[YOUR_PROJECT]/Charts
ProxyPass /[YOUR_PROJECT]/css http://[BIZAGI_SERVER]/[YOUR_PROJECT]/css
ProxyPass /[YOUR_PROJECT]/img http://[BIZAGI_SERVER]/[YOUR_PROJECT]/img
ProxyPass /[YOUR_PROJECT]/js http://[BIZAGI_SERVER]/[YOUR_PROJECT]/js
ProxyPass /[YOUR_PROJECT]/Localization http://[BIZAGI_SERVER]/
[YOUR_PROJECT]/Localization

ProxyPass /[YOUR_PROJECT] http://[BIZAGI_SERVER]/[YOUR_PROJECT]

ProxyPassReverse /[YOUR_PROJECT] http://[BIZAGI_SERVER]/[YOUR_PROJECT]

Page 375 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 SSLEngine on

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile "<LOCAL_PATH>/public.crt"
SSLCertificateKeyFile "<LOCAL_PATH>/ApachePrivateKey.key"
SSLCertificateChainFile "<LOCAL_PATH>/intermediate.crt"

<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>

<Directory "[BIZAGI_SERVER]/cgi-bin">
SSLOptions +StdEnvVars
</Directory>

BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
</VirtualHost>

In these lines, provide the appropriate values:

· <APACHE_HOME>: Apache's installation directory. This configuration file uses "/" (instead of "\") as the folder
separation character.
· <LOCAL_PATH>: The local path in which the SSL certificate files are found.
· [APACHE_IP]: The IP address to access your Apache service.
· [APACHE_PORT]: The HTTP port under which Apache service recives requests.
· [BIZAGI_SERVER]: The server which hosts your Bizagi project (on which Automation Server runs).
· [YOUR_PROJECT]: The virtual directory of your Bizagi project.

View further the complete guide about the SSL directives.

Save the changes in this file and restart your Apache HTTP server.
At this point you are set to access your Bizagi project from the Internet through the Apache HTTP Server in a secure
manner!

Important
In the configuration presented above, the Bizagi Work portalmust allows anonymous authentication.
This means, whether you are using integrated authentication (such as Windows) or Bizagi's local authentication, at
the Bizagi Server (namely in the IIS, for the .NET edition), you need to enable anonymous authentication.

Checkpoint
To verify and access Apache's service type in your browser:
http://[APACHE_IP]:[APACHE_PORT]/[YOUR_PROJECT]

This request will redirect you to your configured Bizagi Work Portal.

System maintenance and monitoring

Overview
Maintenance and monitoring tasks are fundamental for a system to make sure the availability of information and
adequate performance of that system.
By carrying out maintenance and administration tasks appropriately, you should be able to maximize a system's
uptime, Automation Server included, and make sure appropriate performance, avoiding unplanned disruptions of
the service to the end users.

Page 376 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Within such maintenance and monitoring, there are tasks which serve different purposes. such as:
· Tasks which are oriented to contingency plans, either as part of the preparation to carry out certain procedures,
or as part of a scheduled bigger plan (e.g, BCP, DRP).
· Tasks which are part of the tuning required to keep a system working properly and with optimal performance.
· Tasks which are part of the monitoring you should carry out to anticipate any unexpected event in the best way.
· Tasks which are part of maintenance to Automation Server as a product, to consider improvements through
version upgrades.

Once your project has been deployed to a Production environment make sure you have a plan that considers the
following tasks to make sure proper management and operation of the Bizagi System.

Tasks
Consider these tasks within your maintenance and administration plans.

1. Backing up Bizagi
It is important that you take a periodic snapshot of Bizagi, so you can restore Bizagi as a contingency measure for
unplanned events.
Consider which components to backup, as described at Backups.

2. Monitoring your platform, services and relevant infrastructure assets

It is important to always monitor the underlying infrastructure and platform of Bizagi (the servers and further
services integrated to your system), as well as monitoring the performance of Bizagi services.
For information about the recommended guidelines, refer to Monitoring.

3. Maintaining your database

It is important to constantly tune your database.
Additionally, by carrying out monitoring tasks on your database (and its performance), you will be able to detect
features you may be able to optimize.
For more information about the recommended guidelines for these tasks, refer to Database Maintenance.

4. Managing environment parameters and other systems

At anytime you may review variables and parameters which affect Bizagi processes.
It is important to guarantee that notifications, integration points and other specifics of your project keep working
properly, with optimal performance, and that their services are properly set in Bizagi.
Amongst environment parameters, make sure that the business configuration is adequate, and that configuration
related to external systems (by means of Web services, SAP connector, SMTP server, LDAP authentication, ECM
system integration, or databases via Data Virtualization and Replication) is accurate.
If you need to carry out any important changes in external systems (e.g, migrating the location of the servers that
host your services), you can adjust the configuration in Bizagi.
For information about how to review and manage your system, refer to Environment settings and administration.

5. Upgrading your Bizagi version

Bizagi generates new versions periodically which include both great new features and bug fixes.

Page 377 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
We strongly recommend that you upgrade your projects to the newest release, so you can enjoy the benefits of
mew Bizagi features, enhancements and major improvements.
It is important that you plan and coordinate the upgrade, and that you carry out proper user acceptance tests are
carried out before rolling out a version upgrade in a production environment.
We recommend following the guidelines and procedure to upgrade your project to a newer Bizagi version that are
described at Bizagi versions and upgrades.

6. Publishing new versions and continuous improvements for your processes

As part of your own business-oriented maintenance, you should enforce continuous improvement for your
published processed.
Bizagi offers you different process deployment alternatives to do this.
You should plan very carefully when to create a new version of a process running on a Production environment, and
when to directly modify the original version.
For more information on this, refer to Continuous improvement and incremental deployments.

Backups

Overview
As with any system, backups of your Automation Server give you the option to:
· Roll back unapproved changes to restore your system to a previous state, with as little downtime as possible.
· Rely on a snapshot that serves as a restore point for contingency measures (in case of an unplanned event which
affects your operations).
For these reasons, creating backups of Bizagi is an important task for system maintenance and administration.
For more information, refer to System administration.

Guidelines
Back up an operational Automation Server information at the database, its component files, and its case
attachments, following the procedures described below.

1. Make database backups frequently

For Automation Server, database backups are the main tool for responding to any contingency, so generate these
frequebtly.
It will be up to you and your policies to determine the frequency of making backups. Bear in mind that the higher
the frequency, the lower the possibility of losing data when facing an unexpected event or disaster.

For this, consider:

· We strongly recommend that you make database backups daily, at a minimum.
However and according to your analysis, sizing of the project or corporate policies, you may choose to make
backups more frequently.
Backups may be created automatically by scheduling the use of agents and tools as provided by the database
engine products themselves.
· We strongly recommend that you make additional backups prior to any procedure which involves major changes
in the database.
For instance, if you are planning a deployment of processes and new versions, or if you are planning a Bizagi
version upgrade or certain changes in your implementation that require verification, then it is a best practice to
make a database backup so you have a restore point to roll back changes to if (the results derived from the
changes are not as expected).

For more information regarding how to create backups manually, refer to Database backups.

2. Make backups of other components, according to how often these change

In addition to the database, make backups within the Bizagi System to cover other components as well:

· Files of the Work portal (Web application) and the Scheduler service
We strongly recommend that you make an initial backup of the files used by these components as soon as the
configuration is properly set.

Page 378 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Make another backup, just before making any changes that would affect the Work portal or the Scheduler.
You can back up these files just before doing a procedure that changes them, such as a Bizagi version upgrade or
applying a fix. Bizagi does not generate code, meaning that these files do not change or grow during daily
execution of processes.
For more information about how to make backups of these files, refer to Work Portal and Scheduler backups.

· Attachments (case files and documents uploaded from the processes).

By default, case attachments are not stored directly in the database, but separately in an ECM system or file server.
Make backups of the attachments of process instances, wheter they are stored in an ECM or on a file server
according to your own-defined policy, at least once a day.
For more information about how to make backups of these attachments, refer to Attachments backups.

Database backups

Overview
As part of common maintenance and administration tasks, it is of critical importance to always be able to rely on
backups in case you need to restore your project to a previous state, should an unexpected event occur.
We recommend that you make database backups according to the guidelines and recommendations (e.g.,
regarding periodicity) described at Backing up Bizagi.

Further information
To view more information about backing up or restoring a database, refer to the sections linked below (according
to the Database engine used by your Bizagi project):
· When using SQL Server, refer to SQL Server backup and restore
· When using Oracle, refer to Export and import utilities

SQL Server Backup and Restore

Overview
As part of common maintenance and administration tasks, it is of critical importance to always be able to rely on
backup so you can restore your project to a previous state, should an unexpected event occur.
Restoring your project to a previous state when having a database backup is a simple procedure for a Bizagi
System, given that Bizagi is data-driven.
For more information, refer to System administration.

Important notes
Backups in such types of tasks are mainly created as a contingency measure.

Restoring a database backup should only be considered as a contingency measure to restore a given
environment to a previous state, or to move an environment's database to a new location.
This means that a development environment backup should only be restored in the same development
environment, and a production environment backup should only be restored in the same production environment.
To create environments, Bizagi offers its Deployment options.

When using a SQL Server database instance as the database engine for a Bizagi project database, perform the
backup-and-restore operations through SQL Server Management Studio.
If you are using an Oracle instance as Bizagi's database instead, refer to Oracle's Export and Import.

Keep in mind that case attachments are not stored within the backup itself.

Page 379 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Prerequisites
To backup and restore a SQL Server database for a Bizagi project, it is required:

1. Have Microsoft SQL Server Management Studio installed for the client connection to the corresponding SQL
Server version of the database.
For further information about SQL Server Management Studio, refer to Microsoft sites such as:
http://www.microsoft.com/en-us/download/details.aspx?id=22985.

2. Have in your relevant SQL Server instances (both the source and target databases servers), a matching SQL
Server version and configuration collation.

Creating a database Backup

To create a database backup:

1. Login to your SQL Server instance through the SQL Server Management Studio.

Page 380 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. Right-click the specific database of your Bizagi project and select the Backup... option:

Page 381 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
3. Set the backup type to FULL mode.

Page 382 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You need to select or provide a valid path to store the resulting backup (.bak) file.
If you do not want to choose the default path, you may browse and select another file directory. If you choose a
different location, make sure you have write access.

Page 383 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
4. Click OK when the backup has executed completely.

Page 384 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Important
You can choose to make different types of backups:
· Full Backup: This is a complete backup of the entire database. Once it is made, committed transactions in the
transaction log are cleared, by mean of a process called log truncation; this is what keeps transaction logs from
growing forever.
· Differential Backup: This is backup of the database, but only the data that changed since the last full backup is
included. The transaction log is also truncated.
To restore a Bizagi project to its latest backup state, we recommend that you create backups using a Full backup
mode.
For instance, automatic backups created by Bizagi are set this way.

Page 385 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
To schedule your backups as an automated task, review useful external links such as
http://support.microsoft.com/kb/930615.

Restoring a database

Before you start

Before restoring a backup into a database in use, make sure that there are no active connections to the database.

If you are running your processes in a .NET platform, the Scheduler service will be most likely in a started mode,
using an active connection to the database.
To stop the Scheduler so that this connection is released, open the Bizagi Management Console and use the
Scheduler options:

Page 386 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Performing the restore operation
Once you have ensured that the database is not in use, you may restore it using a backup:

1. Login to your SQL Server instance through the SQL Server Management Studio.

2. Right-click the specific database of your Bizagi project and select the Restore -> Database... option:

Page 387 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
3. Select that the database will be restored from a device. Browse to and add your .bak backup file as the source
media:

Page 388 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Page 389 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 SQL Server keeps backward compatibility. This means that restoring a 2005 or 2008 backup can be done into a
2012 instance, but not vice versa (a newer version's backup cannot be restored into an older version).

4. Select the Restore option for this media.

Page 390 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
5. Go to the Options tab, and select the Overwrite the existing database option.

Page 391 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Make sure you select the appropriate existing target database files (.dat and .log).

Page 392 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
In a Bizagi project, these database files are by default located:
· At C:\Bizagi\Projects\[Bizagi_project]\Database\, in a scenario where the database server is the same local server
used for the Bizagi Server.
· At SQL Server's default path (C:\Program Files (x86)\Microsoft SQL Server\[instance_installation]\MSSQL\Data\) if
the database server is a remote server (and not the same Bizagi Server).

6. Click OK when the restore operation has executed completely.

Page 393 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Important
After restoring a database backup in a Bizagi project, restart your project services.
· If your project is running on a .NET platform, do this through the IISReset command, and by restarting the
Scheduler service.

Oracle Export and Import

Overview
As part of common maintenance and administration tasks, it is of critical importance to always be able to rely on
backups if you need to restore your project to a previous state, should an unexpected event occur.
Restoring your project to a previous state when having a database backup is a simple procedure for a Bizagi
System, given that Bizagi is data-driven.
For more information, refer to System administration.

Important notes
Backups in such types of tasks are mainly created as a contingency measure.

Page 394 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Restoring a database backup should only be considered as a contingency measure to restore a given
environment to a previous state, or to move an environment's database to a new location.
This means that a development environment backup should only be restored in the same development
environment, and a production environment backup should only be restored in the same production environment.
To create environments, Bizagi offers its Deployment options.

If you are using an Oracle database instance as the database engine for a Bizagi project database, perform the
backup-and-restore operations through Oracle's Export and Import utility.
If you are using a Microsoft SQL Server database as Bizagi's database instead, refer to SQL Server Backup and
Restore.

Keep in mind that case attachments are not stored within the backup itself.

Prerequisites
To use the export and import utilities in an Oracle database for a Bizagi project, you must:

1. Have the Oracle client installed where the export and import will be carried out

The installed client version will most likely differ according to the bit version (32-bit or 36-bit) supported by the
database server system. It is required that the Oracle client's version used in the export match the client's version
used in the import.

2. Have either the same or compatible character set configured for your Oracle database instances (at the
servers), as well as for the Oracle clients involved in the export and import

Ensuring that these character sets are the same one or a compatible one, is essential for Oracle’s export and import
utilities to maintain the integrity of the information (otherwise, information contained in the database can become
altered).

3. Have no more than one active Oracle home definition

If you have more than one Oracle client installed where you will use the export and import utilities, make sure that
the ORACLE_HOME environment variable is properly set to the Oracle client used by Bizagi.

Additional Considerations
If you are moving a Development project to a new server, and wish to keep your existing cases (Process instances),
take into account that file attachments are not stored in the database but on Automation Server server (by default),
or a file server or ECM, if configured.

If this is the case and you are using Automation Server server as the path for the cases' uploaded files, moving the
attachment files would be necessary.

Also, we highly recommend that an experienced user (such as a DBA with an advanced knowledge in Oracle) carry
out the export and import utility commands, for three main reasons:

1. The export and import utilities are run using DOS commands with use of command line parameters (which are
known to a DBA).
You may choose to use a parameters file if it is useful.

Page 395 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
There is more than one way to use Export or Import capabilities, such as the use of RMAN, however this article
illustrates the way recommended by Bizagi. You can use RMAN as long as you are an experienced userand can
guarantee that the complete information will be considered for backup and restore purposes.

2. Managing an Oracle database of a Bizagi project will require at some point (for a specific instruction in the
import), having at hand the credentials to connect as a user with privileges (for example, using the BizagiAdmon
user).

3. After you perform the export or import of an Oracle database, it is imperative to review the execution logs, so
that any possible errors and warnings thrown in the export and import are handled and solved, or verified as "OK".
Regarding errors, an issue that can show up and that needs immediate resolution, is when a tablespace in Oracle
runs out of space (and cannot be extended) during an import. This type of error will not stop the import, but can
leave the information incomplete and without integrity.
For example, warnings which may be ignored are those stating:
ORA-31684: Object type USER:"%USER_NAME%" already exists
On the other hand, some warnings which require resolution are like this:
ORA-39082: Object type ALTER_PROCEDURE:"%PROCEDURE_NAME%" created with compilation
warnings

The BizagiAdmon user must have already been created in the given Oracle database instance. A Bizagi project
creation requires that the BizagiAdmon user is previously created.

Using DataPump Export (expdp)

The Data Pump utility provides a mechanism for transferring data objects between Oracle databases.
Here is how to use the Datapump export utility to backup all the information in a Bizagi project from into a dmp
file.

To use Oracle’s DataPump export utility for a Bizagi project, carry out the following steps:

1. Preparting the backup directory

To make use of the DataPump export, you need to specify as a parameter the directory in which the .dmp backup
will be saved.

To do this, connect to your Oracle instance with the BizagiAdmon use using a sqlplus command:

sqlplus BizagiAdmon/%BIZAGIADMON_USER_PASSWORD%@%DATABASE_SERVER%:%SERVICE_PORT%/%
SERVICE_NAME%

In this commandt:

· %BIZAGIADMON_USER_PASSWORD% is the password for the BizagiAdmon user.

· %DATABASE_SERVER% is the name of the Oracle database server.
· %SERVICE_PORT% is the port number in which the Oracle database services are listening.
· %SERVICE_NAME% is the alias to your database instance.

Page 396 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Once connected, you can look up the created directories for your database instance in which you will also find
Bizagi's backup path:

To manually create a different directory to use another physical path for your backup and log, run the sqlplus
command as shown below:

Once you have at hand the name of the directory you will use, log off (disconnect) from your Oracle instance’s
BizagiAdmon session.

2. Opening a command prompt

Use a command prompt to execute the export commands.

To do this, launch a DOS command prompt:

Page 397 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Browse to your Oracle client home path, and into its "bin" folder:

3. Using the DataPump export utility

The characteristics of the import operation are determined by the export parameters you specify.
Input the following command line from the bin folder location:

expdp USERID=BizAgiAdmon/%SCHEMA_USER_PASSWORD% SCHEMAS=%SCHEMA_USER_TO_EXPORT%

DIRECTORY=%BIZAGI_BACKUP_PATH% DUMPFILE=%EXPORT_FILE% LOGFILE=%EXPORT_LOG%

In this command line:

· %SCHEMA_USER_PASSWORD% is the password for the user with system rights (BizAgiAdmon).
· %SCHEMA_USER_TO_EXPORT% is the name of the Bizagi project.

Page 398 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· %BIZAGI_BACKUP_PATH% should be "BizAgiBackupPath" by default if no customization was done, according to
step #1 (this parameter is the name for the directory on which the backup is located).
· %EXPORT_FILE% is the path and filename in which the exported information was saved (the .dmp created when
running the export).
· %EXPORT_LOG% is the path and filename in which the import log will be recorded. This file commonly uses the
.log file extension.

For more information about Oracle's DataPump import and export utility (available from Oracle 10g version
databases), refer to external links from the source: http://www.orafaq.com/wiki/Data_Pump.

4. Reviewing the DataPump export log

After the export execution, check for and resolve any possible errors.

To do this, go through the log recorded in the previous step once the export has finished.
This log will be located at the path and filename specified as "%EXPORT_LOG%".

The export utility will use the character set defined for your Oracle client.
Therefore, and as mentioned at the prerequisites section, this character set should be the same or a compatible
one to that defined for the database server. In addition, the character set must also be the same or a compatible
one to that involved when using the import utility.

Using the DataPump Import (impdp)

The Data Pump utility provides a mechanism for transferring data objects between Oracle databases.
We show how to use the DataPump import utility to restore information in a Bizagi project from a .dmp export file,
that meets one of the following conditions:

· This .dmp file was previously created through the DataPump export (manually using the expdp command).
· This .dmp file was created by Bizagi. This is done automatically when launching a project upgrade or a
deployment.

Backup files created by Bizagi will be found at the "backup path" specified when configuring an Oracle instance to
work with Bizagi (prerequisite of Bizagi project creation with Oracle databases).

The DataPump import (impdp command) presented in this section will not restore dmp backup files created
through the traditional export utility (exp command). Such dmp backup files not considered by this approach
were manually created when using the exp command. To importing a dmp file created with the traditional export
utility, needs to be done with the traditional import utility (imp command) described in the section above.

To use Oracle’s DataPump import utility for a Bizagi project, perform the following steps:

1. Make sure there are no active connections

For the DataPump import operation carried out to restore information, it is necessary that the schema user is not in
use (has no active connections).
Take into account, that Bizagi Scheduler's service will certainly have active connections if it is in a started status. If
this is so, you need to stop the Scheduler service.

Take proper precautions when ensuring that there are no active connections. Check for active connections by
using BizagiAdmon, through this command:

Page 399 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 SELECT s.sid, s.serial#, s.username FROM gv$session s
JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id
WHERE s.type != 'BACKGROUND' and s.username = '[your_user_schema]'

You can also force kill active connections (by using the command below), but under your responsibility and
controlling which specific sessions you are ending. Additionally, validate and guarantee that there are no users
working at that moment in the related Bizagi project (user schema).

ALTER SYSTEM DISCONNECT SESSION '[sid],[serial#]' IMMEDIATE;

2. Delete the schema user

When you restore an existing Bizagi project, the current schema user representing this project is deleted.

To do this, connect to your Oracle instance with the BizagiAdmon user using a sqlplus command:

sqlplus BizagiAdmon/%BIZAGIADMON_USER_PASSWORD%@%DATABASE_SERVER%:%SERVICE_PORT%/%
SERVICE_NAME%

In this sqlplus command:

· %BIZAGIADMON_USER_PASSWORD% is the password for the BizagiAdmon user.

· %DATABASE_SERVER% is the name of the Oracle database server.
· %SERVICE_PORT% is the port number in which the Oracle database services are listening.
· %SERVICE_NAME% is the alias to your database instance.

Then, execute the following drop user command (with cascade):

drop user %SCHEMA_USER_TO_IMPORT% cascade;

Note that %SCHEMA_USER_TO_IMPORT% is the name of the Bizagi project.

3. Create the schema user again

The schema user to restore the Bizagi project is created again (as blank) through a Bizagi stored procedure.

In the same session (and in the already connected sqlplus window), execute Bizagi's "spBA_ORA_CreateAppUser"
stored procedure to create the project user:

exec spBA_ORA_CreateAppUser('%SCHEMA_USER_TO_IMPORT%','%SCHEMA_USER_PASSWORD%');

Page 400 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
4. Look up the backup directory
To use the DataPump import, you will need to specify as a parameter the directory the .dmp backup is in.

Therefore, you can look up the created directories for your database instance in which you will also find Bizagi's
backup path:

You can create a different directory for your backup and log, by running the sqlplus lines shown below:

Page 401 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Once you have the name of the directory you will use, log off (disconnect) from your Oracle instance’s BizagiAdmon
session.

5. Open a command prompt

A command prompt to execute the import commands.

To do this, launch a DOS command prompt:

Page 402 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Then, browse to your Oracle client home path, and into its "bin" folder:

6. Use the DataPump import utility

Perform the DataPump import parameter specification. The parameters are completely different for those used by
the traditional import utility.

Input the following command line from the bin folder location:

impdp USERID=BizAgiAdmon/%SCHEMA_USER_PASSWORD% SCHEMAS=%SCHEMA_USER_TO_IMPORT%

DIRECTORY=%BIZAGI_BACKUP_PATH% DUMPFILE=%EXPORT_FILE% LOGFILE=%IMPORT_LOG%

In this command line:

· %SCHEMA_USER_PASSWORD% is the password for the user with system rights (BizAgiAdmon).
· %SCHEMA_USER_TO_IMPORT% is the name of the Bizagi project.

Page 403 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· %BIZAGI_BACKUP_PATH% should be "BizAgiBackupPath" by default if no customization was done, according to
step #4 (this parameter is the name for the directory on which the backup is located).
· %EXPORT_FILE% is the path and file name in which the exported information was saved (the .dmp created when
running the export).
· %IMPORT_LOG% is the path and file name in which the import log will be recorded. This file commonly uses the
.log file extension.

You run the import while connected as the schema user whose objects (Bizagi project) will be restored (the same
user and password as specified in step #3).

For more information about Oracle's DataPump import and export utility (available from Oracle 10g version
databases), refer to external links from the source: http://www.orafaq.com/wiki/Data_Pump.

7. Review the DataPump import log

After the DataPump import execution, check for and solve any errors (no errors should be shown when performing
an import in Bizagi).

To do this, go through the log recorded for this operation once the import has finished.

This log will be located by the path and file name specified as "%IMPORT_LOG%".

The import should finish correctly without warnings and having successfully enabled Bizagi's constraints.

The import utility will use the character set defined for your Oracle client.
Therefore, and as mentioned in the prerequisites section, this character set should be the same or a compatible
one as the one defined for the database server. In addition, the character set must also be the same or a
compatible one as that involved when using the export utility.

After an import, we recommend that you run the following query (with the BizagiAdmon user) to make sure that
there are records returned by it which point to any errors/issues:
SELECT * FROM ALL_OBJECTS WHERE OWNER = '%USER_NAME%' AND STATUS <> 'VALID';

Click for more information about this option in the Management Console.

Work portal and Scheduler backups

Overview
As part of common maintenance and administration tasks, it is of critical importance to always be able to have a
backup available if you need to restore your project to a previous state, should an unexpected event occur.
In addition to database backups, you should always make backups of the files used by Bizagi components, i.e the
Work portal and the Scheduler service.
Apart from the initial backup of these components, we recommend that you make backups just before making
changes to them.

Page 404 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Backing up these files can be done just before certain procedures, such as a Bizagi version upgrade or applying a
fix. Bizagi does not generate code, so the files do not change or grow over time because of the daily execution of
processes.
For more information, refer to Backing up Bizagi.

Work portal and Scheduler backups

Create copies of the folders and files structure used by the Work portal and Scheduler.
To create backups of these files and configurations, copy these folders into a secure location (preferably in an
external device or in cloud storage).

Back up folders and files where these components are installed:

· Work portal: Files found at

C:\Bizagi\Projects\[your_project]\Web Application\.
· Scheduler: Files found at
C:\Bizagi\Projects\[your_project]\Scheduler\.

Consider backing up other components and files which make part of your implementation's customized code.
This includes any .dll assemblies, style sheets and overrides and other components you consider relevant.

Attachments backups

Overview
As part of common maintenance and administration tasks, it is of critical importance to always be able to have
backups available so you can restore your project to a previous state, should an unexpected event occur.
In addition to backups of the database, and of the files used by Bizagi components, you need to make backups of
additional files.
Such files include case attachments uploaded in processes, which are not stored in the database.
For more information, refer to Backing up Bizagi.

ECM or file server

Page 405 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
If your project integrates an external ECM as the attachments repository, it is important to include backing up these
files within your ECM management and corporate policies.
If you use the default setting of having attachments stored on a file server, you need to make backups by creating a
copy of the main folder holding the files (named Docs by default), and moving that copy into an external drive or
the cloud.

We recommend that you make backups of uploads as often as you back up your database.
You can configure or edit the location of attachments when using a file server:

The %BA_UPLOAD_PATH% default value, refers to the local Bizagi server at

C:\BizAgi\Projects\[your_project]\Docs\.
However, we recommend that you define a different location for this purpose, that is not on the Bizagi server
(such as a shared file server), especially to support a Bizagi cluster.

Though this setting can be changed at any time to point to a different location, recall that you need to move the
complete folder structure to the new location when using a file server upon a change of location.

Monitoring

Overview
Monitoring is a fundamental task for system administration.
For more information, refer to System administration.

Page 406 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Monitoring needs to cover all the relevant assets which provide services to your Bizagi system, to make sure an
adequate operation of the Bizagi system.
This means you should constantly monitor: the underlying platform of Bizagi (the servers and further services
integrated to your system, especially including the database engine), other critical infrastructure elements (such as
the network), and the performance and correct operation of Bizagi services.

Further information
For more information about what guidelines to follow for monitoring, refer to the child topics of this section:
· Infrastructure and platform monitoring
· Services monitoring
· Bizagi Diagnostics tool

Infrastructure and platform monitoring

Overview
A fundamental task for project maintenance and administration in a Bizagi System, is monitoring the underlying
platform which enables an operational Automation Server.
A platform administrator should be alert to any significant changes or abnormalities in the system's behavior and
performance, and in charge of taking proper actions when necessary.
Infrastructure and platform services to monitor include the servers on which Bizagi components run, as well as other
IT assets and services which are part of your system architecture and which are typically involved in the solution,
such as storage and network services.
Adequate and pro-active monitoring lets you detect potential issues or bottlenecks to resolve, and helps you
identify where focus your efforts.

The following guidelines provide a starting point and useful recommendations for monitoring and generating
diagnostics the infrastructure and platform.
However, these guidelines do not cover every monitoring task a platform administrator needs to carry out, or
tasks related to maintenance and upgrades (the information provided below is illustrative and not exhaustive).

Monitoring the infrastructure

We recommend that you permanently monitor for adequate operation and performance of critical IT assets and
services.
For a Bizagi system, these aspects are specifically important:

1. Performance of the physical data repository (SAN)

Page 407 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
In a typical enterprise implementation, the databases, files, virtual machines and other IT assets, reside in a
repository that is separated from the physical servers and shared among different servers and other computing
devices.
If this is your case, refer to your storage provider documentation to determine the right monitoring procedures and
recommendations for storage performance.
When database storage is presented to the Windows Server as a volume, you can use Windows Performance
Monitor to identify possible data repository performance issues.
Best practices regarding storage performance analysis in a Windows environment are well documented by
Microsoft as the vendor.
For more information, refer to http://blogs.technet.com/b/askcore/archive/2012/02/07/measuring-disk-latency-with-
windows-performance-monitor-perfmon.aspx

2. Latency between database servers and SAN

Monitoring physical disk latency can be achieved by using specific commands as provided by the database engine
vendor.

For instance, the sys.dm_io_virtual_file_stats Transact-SQL (as provided by SQL Server), serves this purpose.
For more information on the command, refer to https://msdn.microsoft.com/en-us/library/ms190326.aspx).
Since the returned information might be difficult to understand, we recommend that you process to get a clear view
of what is really happening with each database.
We recommend carrying out a thorough analysis. This blog post http://www.sqlskills.com/blogs/paul/how-to-
examine-io-subsystem-latencies-from-within-sql-server/ provides a useful script for improving the readability of IO
subsystem latencies.

For anOracle database, use Oracle Enterprise Manager to monitor performance aspect.
For more information, refer to Monitoring I/O options such as the one shown at
https://docs.oracle.com/cd/B28359_01/server.111/b28275/tdppt_realtime.htm#CHDCCFDG.

3. Latency between the Bizagi servers and the database servers

Since Bizagi is an intensive data-access application, consider these optimal measures for the network connection
between the Bizagi servers and the database servers:

· Low latency: The network should have a latency of 0.15 ms (on average). In corporate system architectures, low
latency is usually achieved when you have the Bizagi server and database server on the same network segment
and use a switch.
You can also monitor network latency between the Bizagi server and the database server with a PING command
from the console.

· Adequate bandwidth: The recommended bandwidth is at least 10,000 kb in 64ms, according to the results
presented when invoking the following RESTful service:
http://[Bizagi_Server]/[Work_Portal_Site]/rest/Diagnostics/Database
You can invoke the service through the browser, after setting the corresponding values for your [Bizagi_Server] and
[Work_Portal_Site].

4. Connection between clients and the Bizagi servers.

For a corporate network (on-premise), or a VPN, you can monitor the network (in this case, the bandwidth is
relevant) between the Bizagi Server and the clients with a PING command from the console of the client.

Page 408 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
5. Other services.
Monitor other services which are external to Bizagi, but which are integrated into the solution.
This includes an ESB or other systems exposing web services; data sources for Bizagi; other services offered by the
corporate E-mail server, the file server or ECM repositories, as well as any system or repository used for
authentication purposes (e.g, the Active Directory) or additional appliances such as firewalls or a load balancer.
Services must be operational, and Bizagi should have granted access to services meant to provide access.

Monitoring the platform

To monitor the platform on which Automation Server components run, you can rely on the usual OS performance
counters.
For health checks, or to measure and monitor performance of the Bizagi server platform, we recommend these
performance counters in addition to any other you consider relevant:

· Processor\% Processor Time: Refers to the average percentage of processor time occupied. It is a main indicator
when deciding whether the CPU power of the IIS server is sufficient. This counter should remain below 85% for the
system to be considered healthy.
· System\Processor Queue Length: The processor queue fills with threads when the server’s processors are busy
servicing other threads. If this counter is usually above 2 and the % Processor Time remains at high levels, the
processors are a bottleneck in the system.
· Memory\Available Mbytes: Refers to the amount of physical memory (measured in Mbytes) in the system that can
be used by new processes. If the free memory is equal to or greater than 50%, the system is considered healthy.
A value of 25% free memory indicates a potential problem. If the memory is below 10%, examine the situation
carefully and take steps to free up memory. If the free memory is below 5%, the performance of the system
suffers.
· Memory\Pages/sec: Refers to the number of read and write requests from memory to disk. If this value remains
high and the Available Mbytes are below 10%, then the Memory subsystem is a bottleneck. Fewer than 500
pages/sec is considered normal, more may affect system performance.
· Network Interface\Bytes Total/sec: Refers to the total number of bytes – both sent and received – over the
network. If the value of this counter is usually greater than 80%, maybe another or faster network card should be
installed on the server.

Make sure that your servers always have enough available free disk space.
Note that the appropriate available free disk space will depend on your project's implementation characteristics
(given by your analysis for solution sizing and its growth rate) and your system architecture.

Whether for the database servers, the Bizagi servers, or any file servers involved for storage of documents,
whenever used disk space gets close to capacity, necessary actions to free up space.
Running your servers with too little free disk space may result in performance issues and unexpected behaviors
triggered by the operating system itself.

In addition, you may also consider: Paging file (% of use), Physical disk (% of disk time), or Logical disk (% of
processor time).

As a best practice, keep track of any changes in your server's logbook.

Apart from updates, audit trails, or certain measures, all important changes should be registered in there with
their corresponding timestamp.

Page 409 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Services monitoring

Overview
We recommend a platform administrator monitor Bizagi services: the Work portal, the Scheduler, and the connector
server.
Make sure all services are running and operational at all times, and that they are performing adequately.
Adequate and pro-active monitoring will help you detect if there are potential issues or bottlenecks to resolve and
where to make adjustments.

Monitoring the web server

Make sure you constantly monitor the service of the Bizagi web servers, such as IIS, provide.
You may rely on their logs.

LOG LOCATION

Event viewer logs C:\inetpub\logs

In addition to these logs, monitor events recorded by Bizagi.

For instance, on Windows operating systems, you can review the Windows Event Viewer (eventvwr).

Regarding Asynchronous Activities

Monitor how Bizagi Asynchronous Activities are processed.
These activities may run in the background, and may involve retries (for instance, due to an external interface being
off-line).

If your project relies strongly on Asynchronous Activities, we recommend that you closely monitor their execution.
You can also rely on the Asynchronous Activities Console in the Work portal, which displays tasks waiting for
processing (due to a previous failed attempt).

Bizagi provides an additional log which we recommend that you monitor, which keeps track of those external
services which present a delay or are unresponsive.
Whenever Bizagi invokes external web services, a new entry is recorded in a .csv file if the external service
exceeds the expected time threshold to return a response, or produces a timeout.
This file is saved in the .\Temporary\SOA\Log\ path of your project, with one file being stored per web service, as
C:\Bizagi\Projects\[your_project]\Temporary\SOA\Log\[your_interface]Log_1.csv.
Each file has one line per alert, with details including: DateTime, ErrorDescription, idCase, Task_Name, URL,
Method_Name, and InterfaceTime(MM:ss:mmm).

Regarding the IIS

We recommend that you monitor the size of the IIS request queue to detect bottlenecks produced at the Bizagi
servers.
Having a growing size of requests queued in the IIS (implying an increase in the number of requests in queue -a
degrading pattern, suggests that your clustered configuration needs additional nodes.
Delays in processing requests which are not produced by external services (i.e in integration points in Bizagi) or not
produced by the database server's capacity to deliver information, suggest that you should tune your Bizagi server
or scaled them up if the delays are increasing in frequency.

Log files of the web thread found by default at the W3SVC folders of C:\inetpub\logs\LogFiles provide detail:

Page 410 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 ASPECTS TO MONITOR INTERPRETATION

Log files of the Web threads The files present the following data measured in
milliseconds:
· timedb: The time it took for the database to deliver
the information requested by the Bizagi server.
· timeba: The time it took Bizagi's Work portal to
process the request.

The sum of these figures adds up the total time it took

to process a request once it started in the IIS not
including not consider the time a request was waiting in
queue.

Through IIS performance counters you may check

whether requests are being left in the queue in an
undesired/unexpected behavior.

You can monitor the Current queue size counter (under

the HTTP Service Request queue classification) for the
dedicated Bizagi application pool (by default named
Bizagi 64-Bit ASP.NET v4.0) to determine queue
behavior in the nodes.

Page 411 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You can also involve additional IIS-role specific performance counters, such as:
· ASP.NET Applications\Requests/Sec: Shows the throughput of the ASP.NET application on the server. It is
monitored along with other counters to determine whether the server is handling the application as it’s supposed
to.
· ASP.NET\Application Restarts: Indicates the number of restarts of the application in the server’s uptime. A high
value for this indicator should be investigated. The general counters can help you identify whether it is caused by
a bottleneck in the system or by the application itself.
· ASP.NET\Request Wait Time: Shows the amount of time (in milliseconds) that the last request was held in the
queue. It should be close to 0 ms. If this indicator is usually greater than 1000 ms, performance of the IIS server is
suffering.
· ASP.NET\Requests Queued: The queue fills up with requests that are waiting to be processed. This counter should
be monitored to find out when an application is overwhelmed. Analyzing of the application and server
performance together can help the administrator identify the cause for the filled queue.
· .NET CLR Memory\# Total Committed Bytes: Shows the amount of virtual memory reserved for the application on
the paging file. It should be monitored along with the general counters to identify issues with performance of the
IIS. Problems can be caused by having insufficient memory installed or by an application overusing the memory.
· Web Service\Get Requests/sec: Measures the number of GET requests processed in a second. If the value is not
optimal for a particular IIS server when compared to other servers, you can apply load balancing or clustering
technologies to lower the burden of the server in question. Check if server hardware and software characteristics
are similar; if they are not, include them as variables in your analysis.
· Web Service\Post Requests/sec: Measures the number of POST requests processed in a second. If the value is not
optimal for a particular IIS server when compared to other servers you can apply load balancing or clustering
technologies to lower the burden of the server in question. Check if server hardware and software characteristics
are similar; if they are not, include them as variables in your analysis.
· Web Service\Current Connections: Shows the number of active connections with that server's service. If the value
is not optimal for a particular IIS server when compared to other servers you can apply load balancing or
clustering technologies to lower the burden of the server in question. Check if server hardware and software
characteristics are similar; if they are not, include them as variables in your analysis.

Page 412 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 As with any IIS application, we strongly recommended that you tune and monitor the application pool's recycling
parameters so that their settings do not affect your working or peak hours significantly.

Monitoring the Scheduler

Monitoring the Scheduler is fundamental to ensuring adequate operation of Bizagi.
The Scheduler must be permanently in a started mode to keep Bizagi system maintenance tasks up to date, this
service should not be unexpectedly interrupted.

In some scenarios it may be useful to scale-up the Scheduler and use multiple instances running simultaneously
(adding additional nodes as necessary).
This is especially useful to distribute the processing involved in tasks carried out by the Scheduler:
· Importing and synchronizing users with an LDAP repository.
· Importing and synchronizing information of parameter entities via Bizagi's Data Replication technology.
· Executing Asynchronous activities and their retries.
· Executing custom jobs.
· Sending alarms or other specific notifications.
· Others activities, such as triggering timers or other scheduled/time-based delays.

Depending on the sizing of your project, further pro-active monitoring or other characteristics of your
implementation, decide whether using additional instances of the Scheduler service is needed.
System maintenance is also performed by the Scheduler, but in a cluster, these tasks are always performed by the
master instance and not distributed/load balanced.

Should any error or unexpected behavior happen, the server's log (for instance, in a Windows operating system, in
the Event viewer) records it.
Additional aspects to monitor are:

ASPECTS TO MONITOR INTERPRETATION

Scheduler executing jobs A growing trend in the creation of jobs to be executed

by the Scheduler, when compared to the Scheduler's
processing capacity, suggests reviewing its
configuration.

If you notice an increase of jobs to be executed by the

Scheduler in queue, consider additional instances for a
clustered Scheduler configuration.

Monitoring the Connector Service

Monitoring the Connector Service is fundamental to ensuring the execution of external connectors installed in your
project.
The Connector Service must be permanently in a started mode to let the connector run and generate traces.

Page 413 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Additional aspects to monitor are:

ASPECTS TO MONITOR INTERPRETATION

Errors in the Event Viewer and Log files If you notice any error when executing your connectors, consider tracing
the connector to determine the cause.

Connector monitor logs You can review logs of the connector monitor, that constantly review if
the Connector service is up and running correctly.

You can find these logs in the following folder:

Bizagi Studio: C:\Program Files\Bizagi\Bizagi
Studio\ConnectorsService
Bizagi Engine: C:\Program
Files\Bizagi\Engine\ConnectorsService

See Connector Monitor

Bizagi system user

The domain\admon is the system user employed internally by Bizagi (created by default). You may not disable this
user since it is needed to perform automatic tasks such as timers or scheduled jobs, and we recommend that you
check that the user is enabled in the database. For further information about the Admon user, click here.

Important notes regarding the database

It is very important that you monitor the database engine to make sure that it is operational and that it can process
the requested information in a timely fashion.
By monitoring the database and its performance, you can determine if you need to scale-up the servers hosting the
database (or scale them out, when using an active-active cluster scheme such as Oracle RAC).
For more information about guidelines on both monitoring and maintenance of the database, refer to Database
maintenance.

Bizagi Diagnostics

Overview
Bizagi Diagnostics is a toolkit that provides monitoring options for Automation Server operations in a test or
production environment.

Page 414 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
A system administrator can use Bizagi Diagnostics, to run health checks on Automation Server components and the
overall environment, while identifying issues that are affecting operations of the Bizagi project (e.g, performance
issues, service downtime), to analyze and resolve them promptly.

Major features
Bizagi Diagnostics does not add significant overhead in runtime. It:
· Lets you work with logs all stored in one place.
· Provides business-oriented analysis and other options which use contextualized information.
· Relies on modern technologies while providing data analysis flexibility.

The image above illustrates the underlying concept of how Bizagi Diagnostics works and how you could set it up.
We recommend that Bizagi Diagnostics run on a separate server (not where Automation Server operates).

Before you start

Bizagi Diagnostics displays information based on server events as reported by each of the Automation Server
components (i.e, Work portal, Scheduler service) in the underlying project.
You will need to make sure that Automation Server components are constantly reporting such events into logs.
Further information on how to configure this reporting is specified in the chapters below.

The system administrator must know the expected SLAs of the Bizagi project, including service thresholds involving
external systems integrated with by the project.

Further information
Refer to the following articles for next steps:
· Setting up Bizagi Diagnostics.
· Using Bizagi Diagnostics.

Setting up Bizagi Diagnostics

Overview
Bizagi Diagnostics is a toolkit that provides monitoring options for Automation Server operations in a Test or
Production environment, as described at Bizagi Diagnostics.
The following section illustrates the prerequisites of Bizagi Diagnostics and how to set it up in your environment.

Page 415 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Prerequisites
Make sure you meet the following software and server configuration requisites before installing and using Bizagi
Diagnostics.

PREREQUISITE WHAT YOU NEED FURTHER INFORMATION

Java (JRE) from Java Runtime Check for an installed Java JRE and its versions by using a command
Oracle. Environment prompt and typing:
installed where java -version
Bizagi Diagnostics
will run.
Make sure you use
version 8, update 71
or higher.

You can download Java JRE from Oracle's official website at:
http://www.oracle.com/technetwork/java/javase/downloads/index.html

JAVA_HOME Check this environment variable's configuration by using a command

environment prompt and typing:
variable configured. echo %JAVA_HOME%

Microsoft .NET Microsoft .NET Download Microsoft's .NET framework, version 4.5, directly from its
framework. framework 4.5 and official website at:
ASP.NET 4.5 (or http://go.microsoft.com/fwlink/?LinkId=395269
higher) installed
where Bizagi Enable ASP.NET 4.5 within the features of the .NET 4.5 framework.
Diagnostics will run.

Microsoft .NET 3.5 Enable the .NET framework 3.5 features which include compatibility for
features (enabling 2.0 and 3.0 framework features.
these regardless of
having 4.5).

Microsoft An operational IIS to Use a supported IIS provided by a supported Windows operating
Internet host the Bizagi system (e.g, Windows server 2008 R2, 2012 R2).
Information Diagnostic web
Services. application.

Page 416 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Supported IIS
versions are: 6, 7,
7.5, 8, or 8.5.

IIS with the enabled Enable roles for the IIS Web server feature, as shown below:
role of:
IIS 6 Management
Compatibility.

A configured base You can use the Default web site provided by the IIS:
site at the IIS to host
the Bizagi
Diagnostics web
application.

An application pool Create a dedicated application pool for the sole use of Bizagi
for the IIS set to use Diagnostics:
the v4.0 .NET
framework, enabling
32-bit applications
and using
Integrated mode to
manage pipelines.

In addition to the above, Bizagi Diagnostics requires at least 360MB of free disk space:

Page 417 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Downloading Bizagi Diagnostics
Download the .msi installer directly from http://resources.bizagi.com/docs/Bizagi.Diagnostics.Installer.msi.
This version of Bizagi Diagnostics requires Bizagi Studio and Automation Server versions to be 11.1.0.2561 or
higher.

Installing Bizagi Diagnostics

To install Bizagi Diagnostics, run the setup.exe installer file, with local admin rights:

Click Next in the welcome screen.

Select the installation location by specifying:

· Site: The base site at the IIS which will host the Bizagi Diagnostics web application (e.g, Default web site), as
mentioned in the prerequisites section above.
· Virtual directory: The name of the web site and virtual directory which will have the contents of the Bizagi
Diagnostics web application. It will be created as a folder in the base path of the IIS base site (e.g, C:
\inetpub\wwwroot\Bizagi.Diagnostics.Web\).

Page 418 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Application pool: The application pool at the IIS which the Bizagi Diagnostics web application will use, as
mentioned in the prerequisites section above.

Click Next when ready.

Configure the path from where Bizagi Diagnostics will read logged information.
In this path, make sure that this is where Automation Server creaties logs. This part is specified in the next section
about Configuring Bizagi Diagnostics.

When defining this path, consider:

This path may be set as a local folder shared with Automation Server servers.
For Automation Server setups using a high availability system architecture (clusters), you would have more than
one Automation Server server writing logs into this path.
If you use such a configuration, make sure that this folder can be accessed as a UNC path by Automation Server
instances (e.g, \\fileServer\logsPath\), and that it is set with adequate access rights for the service account
running Automation Server.

Page 419 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Click Next and confirm the installation by clicking Next again.
The installation procedure may take a few minutes.

Click Close when done.

Page 420 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
At this point, installation is complete and you should be able to verify that the Bizagi Diagnostics website has been
created at your IIS base site:

Additional services are installed by default using the HTTP port number 9200, such as an Elastic service.

Configuring Bizagi Diagnostics

Page 421 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Once you have installed Bizagi Diagnostics, its web application becomes active.
You still need to carry out configuration aspects to make sure that your Automation Server logs into the path Bizagi
Diagnostic reads from.

To do so, edit the configuration file for each component (Work portal and Scheduler service) in each Automation
Server server of your setup.
Explicitly define that each component logs details and specify into which path.

Edit the web.config file of your Bizagi Work portal (by default at C:\Bizagi\Projects\[your_project]\WebApplication)
for each node to include these two lines inside of the <appSettings> element:

<add key="DiagnosticsEnabled" value="true"/>

<add key="DiagnosticsStorageName" value="[Diagnostics_readFrom_path]
\[instance_prefix]"/>

· [Diagnostics_readFrom_path]: Specify the folder you already configured to read from --during Bizagi
Diagnostics installation.
For the Automation Server access, this may be a UNC path (e.g, \\fileServer\logsPath\).
· [instance_prefix]: This is not a sub-folder definition but a prefix you define to mark each different
component in a unique manner. This way, logs read by Bizagi Diagnostics know from which component they
come. You can use W01 for a Work portal of node #1 in a cluster setup, and W02 for node #2, and so on.
Similarly, you can use S01 for a Scheduler service of node #1 in a cluster setup and S02 for node #2, and so on.
Note that DiagnosticsEnabled determines if the logs become active for this component (possible values are true or
false).

Save changes when done.

Changes in this file do not require a service restart.

Edit the BizAgi.Scheduler.Services.exe.config file of your Scheduler service (by default at C:

\Bizagi\Projects\[your_project]\Scheduler) for each node so that you include the same lines as before and one
additional line using the <add key="RaiseSettingsService" value="false"/> key, in the <appSettings> element and
provide appropriate values in them, as described before.

Keys for the Scheduler are:

<add key="DiagnosticsEnabled" value="true"/>
<add key="DiagnosticsStorageName" value="[Diagnostics_readFrom_path]
\[instance_prefix]"/>
<add key="RaiseSettingsService" value="false"/>

The Scheduler's configuration file should look like the image below:

Page 422 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Save your changes when done.
Changes in this file may require restarting the Scheduler from the Windows services panel, which takes up a few
seconds and doesn't interrupt Automation Server operations.

At this point, Bizagi Diagnostics is all set, and you can start to use it, as described in Using Bizagi Diagnostics.

To view options that allow using additional storage options for server events, refer to Advanced options when
recording server events.

Troubleshooting
Bizagi Diagnostics relies on additional services such as ElasticSearch and LogStash.
A successful Bizagi Diagnostics operation should be able to rely on an operational Elastic Search monitor running at
http://localhost:9200/_plugin/HQ.

The Bizagi Diagnostics service automatically starts up, restarts and watches over these other services. This means
that the Bizagi Diagnostics service should be up and running (verifiable at the Windows services panel).

Page 423 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
If this service does not automatically start up to initialize the other services, you can execute the other services' .bat
files (and review their .config files) manually at:
· ElasticSearch: Executable file at C:\BizagiDiagnosticsTool\ELK\elasticsearch\bin\elasticsearch.bat.
· LogStash: Executable file at C:\BizagiDiagnosticsTool\ELK\logstash\bin\logstash.bat, which should be run using
logstash -f logstash.conf

Advanced options when recording server events

Overview
When setting options in each Bizagi Work portal or Scheduler service, you can define whether they record server
events and other options on how they do so (such as which storage is used), as described in Setting up Bizagi
Diagnostics.

Available options
The following options are keys at either the web.config or BizAgi.Scheduler.Services.exe.config files, to determine
how events are recorded for Bizagi Diagnostics.
Add these keys as:
<add key="[key_Name]" value="[key_value]"/>

KEY NAME DESCRIPTION FOR POSSIBLE KEY VALUE DEFAULT VALUE

Page 424 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 DiagnosticsEnabled Enables collection of server events (possible values are true and false
false).

DiagnosticsStorageNa Defines the name for storage. (none)

me

Using Bizagi Diagnostics

Overview
Bizagi Diagnostics is a toolkit that provides monitoring options for Automation Server operations in a Test or
Production environment.
The following section illustrates how to use Bizagi Diagnostics once it has been set up (as described at Setting up
Bizagi Diagnostics).

Using Bizagi Diagnostics

Get started by clicking the Bizagi Diagnostics shortcut created upon installation. You can also, in a browser go to
the URL of the installed Bizagi Diagnostics web application --http://[your_server]/[Bizagi_diagnostics_website]/).
The shortcut automatically opens your default browser and load the Bizagi Diagnostics web application's overview
page (this may take a minute or so).

The page presents several options in the left hand panel, while letting you define a time frame to monitor in the
upper part.
The general layout of the Bizagi Diagnostics web application is explained below, along with further details regarding
each option.

General layout
The main information you need to provide to start monitoring your Automation Server operation, is found in the
upper part where you select:
· A time frame which will apply for all displayed information. The Bizagi Diagnostics web application shows you the
events of that time frame (e.g, 1 minute, 5 minutes, 30 minutes, 1 hour, 3 hours, 6 hours, etc). You can also give
the time frame with a specific start and end time in the Custom date tab.

Page 425 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· An auto-refresh setting to determine If the Bizagi Diagnostics web application should display the latest
information constantly. If you turn on the auto-refresh setting, while having a 5-minute time frame setting, you will
constantly monitor the most recent five minutes of Automation Server reported operations).

You can set auto-refresh to apply every second, every 5, 15 or 30 seconds, or at intervals of 1 or 5 minutes.
If want to leave auto-refresh turned off, you can use the Refresh button to manually update information.

After you set the parameters to indicate what to monitor, each option on the left hand panel present different views
for the reported Automation Server server events.

These views and charts are displayed in the main work area.

Page 426 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Details on each option are below.

Zooming in and out

At any time, in any chart, you can zoom in by defining a smaller time frame with your mouse. Draw a square to
frame the portion you want to see in more detail:

Sharing charts
At any time, in any chart, you can produce a hyperlink and share the same view with other users.
The hyperlink includes filtering options you are using for that chart:

Overview
The overview option provides a first impression that summarizes the general performance of Automation Server.

Page 427 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
It displays three charts:
· Average duration per request: The average time in milliseconds it takes to process requests(for the pre-defined
time frame, shown in the chart as the horizontal axis).
The duration is presented in four measurements:
o Total duration: This is the sum of the other three measurements, and it is highlighted in pale blue.
o Database time: Time spent in database engine tasks such as running SQL queries or procedures; and it is
highlighted in dark gray.
o Bizagi time: Time spent running logic or other Bizagi tasks; it is highlighted in pale green.
o External time: Time spent waiting for external systems to complete their tasks (e.g when Bizagi invokes interfaces).
It is highlighted in orange.

Page 428 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Since Automation Server provides a Work portal which is accessed through a browser as a web application, a
request in Bizagi includes actions that produce an HTTP request to send to the Bizagi server, and which in turn,
require that Automation Server process and reply to each request.

This means that a request as considered by these charts, includes whenever a new case is created, or an activity is
completed, as well as other HTTP requests fired by the Work portal as needed by Bizagi.

· Bizagi Apdex indicator: A standard application performance index that indicates under which conditions
Automation Server is operating (for the pre-defined time frame, shown in the chart as the horizontal axis).
Scoring is assigned as excellent, good, regular or bad (calculated as a standard Apdex score from 0 to 1).
Whenever Automation Server starts up or is restarted, the Apdex may show that Bizagi may take a minute or so to
reach a state of optimal performance.

· Error rate (%): The percentage of reported errors compared to successful requests for the pre-defined time
frame, shown in the chart as the horizontal axis.

Watch for, follow up on, and resolve any errors presented, and aim at having an error rate close as possible to 0%.

Page 429 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Discover
The discover option displays one chart to narrow down average duration for certain types of server events, and for
specific data.

Use it to dig into system activity by filtering the collected information and then clicking Apply changes.

Filtering options are described in the table below.

Page 430 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 OPTION DESCRIPTION

Show (duration) Define if you want to display only reports which exceed a certain
amount of time in milliseconds (by using the slider).
You can also define if you wish to filter by total duration, by
database time, Bizagi time, or by external time (duration/time
definitions apply the same as in the average duration per
request chart).

Stack by Classify results and show details inlayers (stacked) by:

· Bizagi operation: the type of operation executed by Bizagi (e.g,
clicking Save, Next, or creating a new process).
· Process: the different processes of your project.
· Server instance: the different servers of your cluster.
· Source: the different Automation Server components such as
the Web application or the Scheduler service.
· Task name: the different activities in your project's processes.
· User: the different end users accessing your Work portal.

Event type Allows you to define if you want the be able to filter information
by seeing below a list of events.
· Bizagi operation: Events associated to the regular operations
run by Bizagi such as clicking Save, Next, or creating a new
process.
· Get jobs: Events associated to custom jobs run by the
Scheduler.
· Query: Events associated with running queries at the
database.
· Request: Events associated with the regular operations run by
Bizagi in overall requests.
· Thread: Events associated with whenever the Scheduler fires
new threads for programmed tasks.

Once you define this setting, you can narrow down each bit of
information that can be displayed in the chart. For example, for
Query type events, you can select Web application or
Scheduler and click Apply changes:

To select or unselect bits of information regarding events,

consider the definitions above at the Stack by filters section, in
addition to these:

Page 431 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 · Case number: List the process instances (i.e cases) which are
reported.
· SQL: List the SQL statement or queries which are executed by
Bizagi.
An in-depth look at SQL statements which show a significant
delay, may indicate that some tables need database tuning.
Have your DBA review the statistics and indexes where there
seem to be delays.
· URL: Lists the URL of the invoked REST services.

When viewing the chart, you can use top-down analysis options located in the upper right part (by default this is
minimized), to total information (as percentage, average or count):

It is often important to review the number of counts for events which show a slow response time.
A lower number of counts for those events, may indicate that a SQL query or invoked URL is part of the resources
Automation Server loads upon application startup or restart (in which case, it could be considered normal for
those resources to present a much longer delay when compared to transactional operations which occur at a
much greater scale).

Similarly, the lower part (by default minimized), shows a table with details of the recorded events that compose the
information of the chart.
This table includes: Server instance, source component, event type, timestamp, the different duration measures
(total duration, database time, Bizagi time, external time) and significant tags:

Page 432 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Health
The health option displays the overall health status of all Automation Server components reporting to Bizagi
Diagnostics.
A diagram illustraties your Bizagi system architecture with more than one Web server or Scheduler service being
active when applicable.

The diagram shows average availability (server uptime for the Work portal or Scheduler service) for the pre-defined
time frame.
Similarly, average time to the database is displayed for the Work portal or Scheduler service.
You can hover the mouse pointer on each Work portal instance (Web servers), and click Check health to run an
immediate check on its associated resources availability:

Page 433 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You can hover the mouse pointer on each Work portal instance (Web server) and click Detail to see its reported
health status in terms of availability and latency:

Hover the mouse pointer on a Scheduler service instances, and click Detail to see its reported health status in terms
of availability and latency.

Users
The users option shows the number of users working simultaneously (for the pre-defined time frame, shown in the
chart as the horizontal axis).

Page 434 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Errors
The errors option lists, and provides in depth details for, all reported errors.

This view has a chart in the upper part to display the total number of errors (for the pre-defined time frame, shown
in the chart as the horizontal axis), while showing details of those reported errors: the case instance, source,
timestamp, the error exception, and diagnostic tags.

Traces
The traces option lists all custom traces written in scripting expressions by means of the CHelper.trace() method.

Page 435 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You can browse the traces according to the timestamp, server instance, source (Web application or Scheduler),
category (name of the trace) or logged data.

To make the most of this view, we recommend that your team agrees on a standard nomenclature for your traces
(e.g, possibly including the case identifier in its file name).

Settings
The settings option lets you to change settings uniformly for all of your Automation Server components to define
which server events are reported into logs.

For more information about this option, refer to General pointers and tuning tips.

General pointers and tuning tips

Overview
When monitoring and interpreting results in Bizagi Diagnostics, make sure you consider the following general
pointers and tuning tips.
For introductory information about how to use Bizagi Diagnostics, refer to Using Bizagi Diagnostics.

General pointers
Consider the underlying concepts in Bizagi regarding how it optimizes its operations.

Page 436 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
1. Application startup or restart presents different response times
When Automation Server starts up (or has been restarted from its Web server), it will load a significant amount of
resources.
This means that the Apdex indicator may show a slower response time whenever Automation Server is initializing,
and that this is normal behavior.

2. Recycling application resources

Based on the above premise, note that you may monitor and configure adequately how often resources are
recycled by your Web server (e.g settings regarding pool cycling in the IIS), to achieve an optimal configuration
where Automation Server resource recycling or restart does not significantly affect your operations.

Tuning tips
Consider the following tips and optimization parameters.

1. Allocated memory for Bizagi Diagnostics

For Automation Server projects which process a really large number of cases and activities on a daily basis
(implying large volumes of information in logs), you may modify the memory allocated to Bizagi Diagnostics.
To do so, open the configuration file for the Diagnostics executable application which is located at C:
\BizagiDiagnosticsTool\Bizagi.Diagnostics.Service\Bizagi.Diagnostics.Service.exe.config.

Modify the value for the ELK_Xmx (maximum) key which uses a default memory of 2147483648 bytes (2GB)
according to your criteria and server characteristics.

2. Filter the events that are logged, or when to do so

In the Settings options in the Bizagi Diagnostics web application, you can define which Bizagi server events are
recorded by logs, for all components of every Automation Server server.
Turn off those you do not identify as relevant for your needs, or define a threshold (in milliseconds) that limits when
to record such events (to record only those exceeding the threshold duration):

Page 437 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
After changing a setting, click Update.
Use the following table as a reference regarding the list of Bizagi server events.

BIZAGI SERVER EVENT DESCRIPTION

Library rules execution Applies to whenever Bizagi executes library rules (i.e,
those which are frequently reused by being well-
defined functions that receive inputs and outputs).

Web requests Applies to requests that are solely web requests (HTTP).

Activate workitem Applies whenever a new BPMN shape instance is made

available by the logic behind the workflow.
BPMN shape instances include activities, Sub-Processes,
events and gateways.

External service call Applies to whenever Bizagi invokes an interface via the
WS Connector.

Case processing (save and next) Applies to requests that are solely produced when the
user clicks Next or Save in an activity's user interface.

Jobs processing Applies to whenever custom jobs run.

Custom traces Applies to tracing features included by logic (i.e,

scripting expressions using the CHelper.trace()
method).

Business rules Applies to whenever Bizagi executes rules (e.g, scripting

expressions).

Build forms Applies to whenever Bizagi loads user activities and

displays their forms.

SQL Queries Applies to running SQL queries as part of any request.

3. Define the best event recollection and storage system to employ

Page 438 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
In addition for each Bizagi Work portal or Scheduler service you can define whether and how they record server
events (e.g, which storage is used).
These options can be helpful according to how busy your system is, or which options you can consider best.
For instance, when using a File system, make sure the rate and filesize under which files are being created is
appropriate for your environment.
To view all available options and to learn how to use additional possibilities, refer to Advanced options when
recording server events.

Database maintenance

Overview
An important task for project maintenance and administration of the Bizagi System is to perform regular
maintenance to the database, to keep the system working at an appropriate performance level.
Each database engine by itself (SQL Server, Oracle) provides the necessary tools for such maintenance, including
ways to pro-activly monitor, run diagnostics (e.g, profiler tools) and perform tuning tasks.
For more information, refer to System administration.

Monitoring and tuning guidelines

We recommend that the DBA:

1. Perform continuous monitoring over the database performance

The database engine itself provides the necessary tools and log files so you can monitor, run diagnostics, and
interpret results so you can perform tuning tasks.
Through pro-active monitoring you can anticipate undesirable situations such as table scans, database locks or
delays, and detect situations which may require database tuning.
For instance, a table scan may suggest that queries/statistics are not tuned, and that maintenance of indexes is
needed (adding new ones, redefining existing ones).
Relevant aspects to monitor, either to review your configuration or the characteristics of the underlying
hardware/infrastructure, include: potential bottlenecks that may arise due to lack of memory, from waits in disk
reads and writes, or due to high network traffic

If the DBA detects that the database engine is not performing adequately (not executing queries in a timely
fashion), you can scale up the database server at any time (or scale it out when using an active-active cluster
scheme such as Oracle RAC).

The following metrics are recommended:

Page 439 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
PhysicalDisk(_Total)\Avg. Disk sec/Read
PhysicalDisk(_Total)\Avg. Disk sec/Write
Average writing timers when using the Disk. It should not be greater than 20ms for hard drives or 5ms for SSD
drives.

Processor(_Total)\% Processor Time

Indicates the percentage of processor use, the ideal use should be between 30% and 80%. When it is above it
indicates that more processing resources are required and can lead to waiting times that can slow the operation of
the application.

Memory\Available MBytes
It indicates the memory available on the database server, if the memory level is low it indicates that the database
does not have enough memory space and starts to perform operations with virtual disk memory, which makes the
database slow.

Paging File(_Total)\% Usage

This indicator is linked to the available memory and the maximum memory allocated to SQL Server, and indicates
whether data is being processed on disk instead of memory.

System\Processor Queue Length

Indicates if there are processes that have to wait for CPU resources, if a number greater than 0 is presented, it
indicates that the processors or cores are not sufficient for the processing of the requested operations.

Network interface\Bytes total/sec

It allows to monitor the network interfaces, if it stays above 80% the applications can have issues in the network
traffic.

SQLServer:Access Methods\Forwarded Records/sec

It lets you know how fragmented are the tables that do not have a clustered index (heap tables) when the
fragmentation is high makes pointers are created that execute I / O operations that can slow the operation.

SQLServer:Access Methods\Page Splits/sec

It allows to know if the tables are constantly fragmented in indicates that there is division pages and constant
movement of rows and this is an operation that could be optimized.

SQLServer:Buffer Manager\Buffer cache hit ratio

It is an indicator that measures the successes of the cache in data processing. A high number indicates that high
memory usage is being made and I / O operations are reduced.

SQLServer:Buffer Manager\Page life expectancy

It allows monitoring if the lifetime of the pages in the cache, that is if the data in the cache is released very quickly
because other data is required to be loaded. If this indicator is less than 300, there may be query problems that
process a lot of data and more memory is required.

SQLServer:SQL Statistics\SQL Compilations/sec

SQLServer:SQL Statistics\SQL Re-Compilations/sec
These counters are incremented when SQL Server has to compile or recompile the query plans because the cached
plan is no longer valid or there is no cached plan for this query, this increases the processor consumption of the
database.

SQLServer:General Statistics\Processes blocked

It allows measuring the level of blockages that occur in the database and if this counter tends to increase with
respect to a baseline it indicates that there are many escalations from row locks to page locks and can reach table
locks.

SQLServer:SQL Statistics\Batch Requests/sec

Page 440 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
It allows measuring the level of transactions that are being executed in the database. This counter should be kept in
a normal range of daily operation and if variations are evidenced, it should be investigated if there are occasional
processes that generate that load.

2. Carry out database tuning regularly and according to best practices

For processes expected to produce a large number of cases or process a large number of activities per day, we
recommend database tuning at least once a weekl.
Best practices include performing tuning during non-working hours, and planning ahead (keeping in mind that such
tasks can take some significant time), as well as following recommendations provided by the database engine
vendor.

Tuning includes:
· Verifying the database integrity.
· Updating database statistics.
· Reorganizing and maintaining indexes (recreate highly fragmented indexes or reorganize them according to the
order of the queried columns when using compound indexes).
· Performing shrinks to the database.
· Monitoring database filegroups so that their configuration (size, increment, maximum size, drive used, etc) is
most appropriate to the way they grow.
According to the hardware characteristics of your database nodes (i.e number of hard disks, number of processors
or cores), you can configure the data files and logs for enhanced performance by scaling them out.
For instance, you could benefit from parallel I/O operations when using multiple drives with a dedicated drive to
separate data files and filegroups (i.e placing log files in its own volume, placing tempdb in their own volume, or
having a data file with the most worked on transactional tables in its own volume the one with the best speed).
Regarding tempdb, we suggest that you configure it using multiple data files and filegroups pre-sized equally to
avoid auto-growth (using one data file per CPU).
When pre-sizing, consider: 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.

Within Bizagi's model, pay close attention to the growth behavior of the following tables:
· Those related to storage of daily work: Workitem, Workitemcl, Wfcase, and Wfcasecl.
· Additional stables, according to the characteristics of your project: Asynchwiretry and Asynchworkitem.
· Those storing logs: AttribLog, EntityLog, Wistatelog, Transitionlog, Factlog, Casestatelog, Authlog, Attribcharlog,
Assignationlog, Joblog (especially if your project involves job execution in a frequent manner),
Alarmjobrecipientlog (especially if your project involves alarms in a frequent manner), Wfcaseabortreason
(especially if in your project cases are manually cancelled frequently) and Reassignlog (especially if in your project,
cases are manually reassigned frequently).
Note that tables storing logs may be partitioned into a separate filegroup.

Include in your plans and tuning, additional business entities which are expected to store large volumes of
information and to grow significantly.
According to what observe, you may choose to review the fragmentation of information (ifilegroups in SQL Server
or tablespaces in Oracle).

Carry out database tuning right after executing maintenance actions by Bizagi (e.g, such as the maintenance tasks
done by the Scheduler, or further options as per delivered in additional tools like Archiving).

3. Follow Bizagi guidelines on indexes creation

When creating or reorganizing indexes:
· You can create non-clustered indexes.
· You can create indexes on tables which are definitions of your project (i.e, business entities which are not actually
part of Bizagi's meta model).

Page 441 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· As a general recommendation for databases, it is not useful to create indexes on columns which have a small set
of possible values (e.g, typically such as boolean or bit type columns).
· Do create indexes in an automatic manner (without prior analysis).
This means not relying on the un-assisted index creation tasks of software such as Database Engine Tuning Advisor
(SQL Server), because the DBA should evaluate such indexes adequately.
Apart from a cost-benefit analysis, you can evaluate use of indexes within the query execution plan and based on
use statistics (consider index seeks, index scans, index lookups or index updates).

4. Make sure adequate concurrency settings when using SQL Server

Make sure you have the required management for concurrency enabled in Bizagi's database.
Verify that your Bizagi database uses snapshot isolation. This means:
· Allow Snapshot isolation: True (ALLOW_SNAPSHOT_ISOLATION ON)
· Is Read-committed snapshot isolation on: True (READ_COMMITTED_SNAPSHOT ON)
When using these 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).

Page 442 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 These guidelines provide a starting point as well as useful recommendations for monitoring tasks, database
tuning and diagnostics.
However, these guidelines do not cover every task a DBA needs to carry out regarding database maintenance
(the information provided is illustrative and not exhaustive).

You also need to carry out additional database tuning tasks, both those encouraged by the database engine
vendor, and those you identify based on use of specialized tools and reviews of logs and traces.

5. Make sure the system user is enabled

The domain\admon account is the system user employed internally by Bizagi and created by default.
Do not disable this user since it is needed to perform automatic tasks related to timers or scheduled jobs. We
recommend that you check that this user is enabled in the database.
We strongly recommend that you edit this user's setting so that it does not have rights to access administration
options at the Work portal.
For this, you can exclude this user from those authorized to manage your Bizagi system (i.e this user should not be
able to manage users or modify values in Bizagi such as parameter entities, abort cases, etc).

6. Make sure adequate database access rights

Make sure that credentials used for both the Work portal and Scheduler instances are set to use credentials with
adequate access rights, as instructed and configured during initial set up.
The sample image below displays those rights needed when using SQL Server.

Page 443 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The server roles specified for this login must include: public.

Page 444 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The login must include the following user mapping items for that specific database: db_datareader, db_datawriter,
public, rlBA_SQL_BizagiWebApp and rlBA_SQL_ExecuteBizagiSPs.

Page 445 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 The db_datareader, db_datawriter, public, rlBA_SQL_BizagiWebApp and rlBA_SQL_ExecuteBizagiSPs user
mappings apply for your project's database. This means that you need to apply these mappings once your Bizagi
production environment database has been created.

Double-check that this login is not locked out:

Page 446 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Troubleshooting and diagnostics
When you need to troubleshoot and diagnose an issue occurring at the database, you may choose to:
· Rely on a special Bizagi tool for this purpose. For more information about this option, refer to Bizagi Diagnostics.
· Rely on specialized tools of your database engine, such as the Profiler tool for SQL Server.
For recommended guidelines on its use, refer to Profiler recommendations.

Profiler recommendations

Overview
When you need to troubleshoot and diagnose to follow up a specific issue on your SQL Server, you can use
profiling tools as provided by the database engine vendor itself.
When using SQL Server, you can rely on its Profiler tool as available in the SQL Server Management Studio.

You can rely on a specialized tool for diagnostics.

For more information refer to Bizagi Diagnostics.

Recommendations

Page 447 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
1. Do not execute the profiler tools from within the database server directly.

2. Similarly and when applicable, run a profiler trace on the database at times when the system is not extremely
busy.
It may be useful to run a profiler as well during busy hours depending on the issue, but avoid affecting the system's
performance and plan this accordingly (taking necessary precautions).

3. Filter the profiler appropriately.

4. Capture information from the profiler by enabling the relevant (and only those strictly needed) events.
For instance, for SQL Server you may consider RPC:Completed and TSQL-SQL:BatchCompleted.

5. Capture information from the profiler by enabling the relevant (and only those strictly needed) columns of
information.
Analyze which aspects are key for reviewing database performance in your project.
For instance, for SQL Server you may want to consider: CPU usage, number of write and read instructions, duration,
and start and end timestamps.

6. You can also use filters to narrow down the traces to what is really important.
For instance, you may want to record: only those transactions having a duration greater than a given threshold (i.e,
3 seconds), or only those transactions affecting a really large number of records.

Additional notes
In addition to database tuning and monitoring, consider monitoring tasks for other elements of your system
architecture that may interfere with the adequate working of your database (such as domain configuration when
used by your database cluster setup, the state of the network between your database servers and other elements of
your system architecture such as the Bizagi server or the SAN, etc).
For more information refer to Monitoring.

We do not recommended that you use antivirus software to scans physical database files.
This may generate locks and delays for applications persisting information into the database.

Environment settings and administration

Overview
Environment administration is about ensuring that you can manage your live environments (Production, Test, and
possibly others like Staging) so that you can make sure their adequate operation, and tune any parameters needed
for B2B integration with your systems, or as part of the business definitions.

Further information
Refer to the chapters in this section for more information about managing settings of your Bizagi system
environment.
Among such settings you will be able to configure business parameters and variables involved in your Bizagi
processes, including those relevant to your corporate systems which are integrated to the processes.

To carry out these tasks, two applications are available:

· Asynchronous Activities Console.
· Management Console.

Page 448 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Asynchronous Activities Console

Overview
When there are integration points in the processes where a Service-type task is used (to either invoke a Web or
REST service or to use custom code for an advanced business rule -though the Component Library), Bizagi allows
these types of tasks to be configured for asynchronous execution.

When you define a BPMN service task as an asynchronous activity, Bizagi lets you set a number of retry attempts, in
case the activity's integration actions (usually, an invocation to an external service) fail to respond within a given
threshold.
When an asynchronous activity fails (i.e. an external application' service is not operational, there are connectivity
issues, etc) and surpasses the number of predefined retries, Bizagi lets an administrator review, follow-up/diagnose
and manually retry such operations.

Before you move on

Such retries and asynchronous treatment, are all configured by you from the definition of the BPMN shape (in the
process design in the Development environment):

The image above, shows the configuration parameters for an asynchronous activity, as it is defined when you model
a process.

In the administration options for any asynchronous activities, Bizagi will store a log that records which process
instances (cases) failed to complete specific activities. The log records the corresponding an error message.
Through this console, most importantly, the administrator can manually retry failed activities.

Asynchronous Activities Console.

To access this feature, click the Admin menu in Bizagi Work Portal.
Open the bi category Click Asynchronous Activities Console in the displayed menu options.

Page 449 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This option lets the business administrator decide which Items to retry, individually or in groups, and to view the
retry log, and to cancel cases (should this be necessary).

You can review a table of all Failed Asynchronous Activities showing information such as: A log with execution details
(error message), the case number to which the Activity belongs, the Activity's name, the number of retries so far, the
date in which the Activity was first attempted, and the latest retry date.

Retry an Item
To manually retry an Asynchronous Activity, select the Asynchronous Activities tab and click the icon under Retry
now column for the corresponding row.

Page 450 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Retry Specific Items
To retry more than one item at once, select the items to be retried in the Asynchronous Activities tab and then click
the Enable Asynchronous Activities button.
These items will be marked for automatic retry, which is carried out by the Scheduler.

Retry Items in a Group

Bizagi lets you retry, grouped by Process or Activity, all the items that have failed.
This retry is not performed immediately, it is executed by the Scheduler.

For this, select the Grouped by Activity tab.

Click Enable in the Delegate retry to Scheduler column, to have the the Scheduler retry in batch those grouped
activities in batches.

Page 451 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You can enable grouped Activities per Process.

See Retry Log

To see the retry log which has execution details and the error message, click the icon under the Log column.

In the Asynchronous Activities Log, you will find the history for the retried attempts' date and specific error
messages.

Management Console

Overview
The Management Console is the feature of Automation Server you use to administer Production or Test
environments and perform maintenance activities such as following up Scheduled jobs, changing the SMTP Server
for notifications, setting execution traces, reviewing connection parameters configured for integrations with external
systems, and managing licenses and clustering in your Production environment, amongst others).
The Management Console is installed with Automation Server so you can manage projects in Production
environments, but, is also installed with Bizagi Studio so you can manage projects in Development and Test
environments.

Prerequisites

Page 452 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
to use the console you need to fulfill the following prerequisites:
· A user opening the Management Console must have the administrator role in the server where the console is
installed.
· The user must have reading permissions in the database.
· If you need to use start /stop or reset features for the scheduler, the user must be an administrator.

To open the Management Console, launch it as an administrator from the shortcut access or from its installation
path (by default at C:\Program Files\BizAgi\BizAgi Studio\MC\BizAgiMC.exe).

User Interface
When you open the Management Console, the splash screen offers shortcuts for common options.

Page 453 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You can quickly:
· Create a new project.
· Open an existing project.
· Manage your registered projects.
· Access our documentation and guides to get started with Bizagi.
· Install free process templates from our Process Xchange.
· Administer your Production environment licenses.

Some of these options are also available in Bizagi Studio.

Management Options
Once you open your Production or Test environment project, you can review or administer the environment's
configuration.

General options
Options presented in the ribbon are:

Ribbon tab Option Description

File New Create a new project

Open existing project

Open an existing project

Projects Manage your registered projects (upgrade them,

disjoin to them, etc).
For more information refer to Registered projects.

Page 454 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Visualize Bex File Launch the package visualizer to explore objects
included on the .bex file. For more details refer to
Package Visualizer.

Home Offers quick-access options See the menu options sections below for description
presented according to the of the specific options in your project's
Module selected. implementation.

Configuration Environment Shows the current options which you can edit for this
environment.
For more information, refer to Environment
Configuration.

Tracing Turn on the different trace files for Bizagi's execution.

For more information, refer to Error control and
diagnostics.

Delete Cases Delete all existing cases in the current environment

(for Development or Test only).

Admin Password Change the Admon user password. If the password is

not explicitly specified, the Admon user password will
be left blank.

Data Synchronization Export data from the Development environment and

import this data a target environment.

Help Help Browse our official documentation or download it as a

PDF.

Support Forums Directs you to our support site, where you can use the
tickets platform or the free feedback forums.

Process Xchange Directs you to our free Process Xchange where you
can browse and install our available process
templates.

Feedback Directs you to our free feedback forums.

Tell a friend Share information about Bizagi with your friends.

Release Notes Directs you to the official documentation Release

Notes of you Bizagi version.

License Administration Manage your Production environment licenses.

For more information, refer to Licenses.

About Shows the current Bizagi version of your project.

Module options
Options in modules lets you manage: The Scheduler and its jobs, external systems, security settings, organizational
user group definitions and a clustered environment.

Page 455 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Scheduler
This module presents options to manage the Scheduler and its jobs.
The Scheduler is a service created in each Bizagi project, to carry out jobs such as: sending alarms, triggering timers
(activating timed delays), executing replication, and running custom jobs and Asynchronous Activities.
For more information about these options, refer to Manage Scheduled Jobs.

To use the Stop and Start/Restart options, the user opening the Management Console must be part of the
administration group of the server where the main scheduler is installed, because the scheduler is a windows
service, and the user must have permission to change its properties.

Systems
This module presents options to review or reconfigure settings in external systems integrated to the solution.
Such external systems include data providers for replication and virtualization, interfaces for Web or REST services
invocations, and ECM repositories.

For more information about these options, refer to External systems administration.

Organization
This module presents options for managing the Working Time Schema and User groups, defined in Bizagi Studio
during development.
· Working Time Schema: to access this option right-click the Organization icon and select Working Time Schema. A
wizard displays where you can manage schedules. You can edit other Organization features in the Bizagi Studio
and then deployed changes to production.
· User groups: Use the Management Console to include users in or exclude them from groups, by clicking the
Properties option at the top.
If new user groups are needed, or existing ones need to be changed, manage them in the Bizagi Studio and then
deploy them.

Page 456 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Changes in this module in the Production environment will not be persisted in the Development environment. We
recommend that you perform changes in both environments to keep them synchronized.

Security
This module presents options to manage the Authentication, Authorization and LDAP configurations.
In a first deployment, the configuration of these options will be taken to Production. After that, they will be in read-
only mode in the Development environment.

Perform authentication and LDAP configuration changes separately for each environment after the first deployment.
Perform required changes for Authorization options in the Development environment and then deploy them to
Production.

Server Management
This module is presented only in a Production environment.
It lets you manage nodes configuration for a clustered-Production environment, or move your current Production
server.

For more information, refer to Server Management.

Recreate environment (from database)

Overview
This option lets you to recreate a Bizagi production environment from an existing database.
Through it, Bizagi will automatically create your project's Work Portal and Scheduler on an underlying .NET platform
(with an IIS web application).

This is a useful option especially when the Bizagi server in which your project was set up, has suffered any damage
due to an external reason (i.e useful in a business continuity plan), as you can use a running database service of
your project (or a stored backup of it), to restore your Bizagi system to a previous state.

Using this option does not automatically activate an existing license.

Therefore, have the license at hand, and contact Bizagi support if you require any additional help.

Before you start

Page 457 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
If you do not have a database service of your project up and running, but have a full database backup, you first
need to restore that backup in the database server.
The procedure described below starts from having your project's database up and running, so that a new Bizagi
server can connect to it.

Procedure
To use the Recreate from database option, follow these steps:

1. Install Automation Server in the new target server

Install Automation Server in the machine which will be the new Bizagi server.
The server requires access to the database server (where has the database to recreate from).

Install Automation Server with the Bizagi version that matches the version on which your Production environment
is running.

2. Open the Management Console

Open the Management Console in the recently installed machine. In the Welcome to Bizagi window, select the All
Projects option.

3. Use the Recreate from database option

Click the Recreate from database icon:

Page 458 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Bizagi will launch a wizard for this procedure.
In the wizard window, enter the connection details to your Production database.

Page 459 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
In this window, enter the following information (as you would when creating a new project).

If you are using a SQL Server database, enter:

· Server: The name of the Database Server containing the SQL Server instance.
· Database: The name of your project. Bizagi will create a database with this name.
· Login name: A login account to access the SQL Server instance
· Password: The password for the specified Login name.

If you are using an Oracle database, enter the following for the Login as Bizagi Admon information:
· Service: Access to your Oracle instance, specified as "databaseServer:port/serviceName".
· Password: Password for the BizagiAdmon user.

Enter the following for access to the existing database (user schema):
· User name: The name of the existing Bizagi user schema.
· Password: Password for the specified user name.
· Confirm Password: The same password specified above.

Click Next to start recreating the environment. Bizagi will prompt for confirmation.

Bizagi automatically creates the Work Portal and Scheduler service (as when creating a local new project).
Remember that to perform such tasks, you must launch this option with an authorized account which is a member
of the Administrators group for the server.

A message will appear when the operation has been completed. Click Finish to close it.
At this point, your new Bizagi server is set up and connected to that database.

Page 460 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Bizagi parameters configuration

Overview
The environment configuration determines the way in which sending email, the Scheduler, uploads and logging
options are configured.
This option is found in the Configuration Tab in the Management Console.

Environment configuration option

Environment Configuration has three main options:
· Popular
· Advanced
· Custom

Page 461 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Before the first deployment, you configure ALL environments in Development in the Bizagi Studio. The first
deployment take the configuration to each environment. After that, make changes to Environment Configurations
using the Management Console for each environment.
If you want changes to be a permanent, part of the process design, make them in the development environment
as well.

Popular
From this option you can configure the parameters for sending email for each environment (Development, Test,
Production).

Page 462 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The parameters to be configured are:

OPTION DESCRIPTION

Notifications options

Enable Email Allows Bizagi to send emails, or prevents it. Select this option to permit sending e-mails.
If it is not selected, emails will be ignored.

SMTP Server Defines the name of the SMTP server. The SMTP can be local (localhost) for specific
testing purposes in the Development environment.
For Testing and Production environments the server must be the company's server from
where e-mails are sent.

SMTP Server Account Defines the SMTP account (or address) used to send e-mails. It must be a valid e-mail
address on the SMTP server.
If the local server (localhost) is used, the e-mail address may be a non-valid one. If a real
SMTP server is used, the address must belong to the domain.

Send Email Copy to Defines an e-mail account to which a copy of all mails sent by the application will be sent

Page 463 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 OPTION DESCRIPTION

Send Email BCC to Defines an e-mail account to which a BLIND copy of all mails sent by the application will
be sent

Email integration

Enable lookup email Enables the possibility to retrieve emails from the configured account and Complete tasks
via email, without entering the Work Portal.

Connection type Depending of your company's requirements the available options are Exchange, POP3
and IMAP.

Enable SSL Defines whether Bizagi uses SSL to connect to your server. We recommend that you
enforce use of SSL.
This option depends on your Mail Server configuration, and it is available when the
connection type is POP3 or IMAP.

Exchange connections already enforce the use of HTTPS.

Port Defines the connection port to your Mail Server. This option is available when the
connection type is POP3 or IMAP.

Account Defines the account that will receive email replies sent by end users.

Mailbox Service / · When Exchange is selected the Mailbox service receives the Exchange Web Service
Host URL, which is an .asmx URL. The default URL for this service is https://
[MailServer]/EWS/Exchange.asmx. Click here for more information about EWS and how
to manage it,
· When POP3 or IMAP are enabled, defines the server's name or IP of your Mail Server

Username Defines a valid user name within your mail server to perform the connection.

Password The account password.

We recommend using an exclusive account to retrieve incoming messages for email integration. Bizagi will read
all incoming messages and will mark them as read.

For traces and troubleshooting, errors are recorded in the Window's Event viewer.

Advanced
From this option you can configure the parameters of Advanced features for each environment (Development, Test,
Production).

Page 464 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The parameters that can be configured are:

OPTION DESCRIPTION

SCHEDULER OPTION

Interval Configures how often (in hours, minutes and seconds) the Scheduler service
checks whether there are pending jobs.

UPLOADS OPTIONS

Upload Path Define the physical Directory where files uploaded by the client are stored.

The value for this property may be a local folder or an external path to a
location on a remote server. For remote servers, the path must be \\[IP Address
or Server Name]\[Folder]\. Make sure you have write permissions on the folder
in the server.

The default directory in Bizagi .NET is C:\BizAgi\Projects\[Project name]\Docs.

Upload Max File Size Defines the maximum allowed size in bytes of files to be uploaded.

Page 465 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 OPTION DESCRIPTION

Use this table to convert to bytes the most common units of measurement for
data storage:
MEASUREMEN BYTES
T

1 KB (Kilobyte) 1,024

1 MB 1,048,576
(Megabyte)

1 GB 1,073,741,82
(Gigabyte) 4

SOA OPTION

SOA Business Key Enforcement The option to un-select this checkbox, is available for Bizagi .NET.
If selected, and you use the SOA layer, Bizagi displays an exception when
attempting to register a business key pointing to either a parameter or master
entity that does not exist in Bizagi.
If the option is not selected the business key is saved as null.

LOG OPTIONS

Enable job logging Enables the logging of information on every job execution

Enable entity logs Enables the logging of information on the entities, and the logs of changes in
user's configuration

Enable M-M relationship log When this is selected Bizagi creates a log (Attriblog) in the database when there
are any changes (relating or un-relating) in M-M (multiple-to-multiple)
relationships

ENTITIES OPTIONS

(1) Attributes Length Maximum Parameter entities in the Work Portal are handled in Cache if the number of
Threshold AND (2) Parameter attributes in the entity is less than the first parameter AND the number of
Entities Instances Cache records is less than the second parameter.
Threshold
Parameter entities that have more attributes or more records than the
thresholds will be loaded on demand (accessing the DB).

These parameters refine the application's performance when there is a large

volume of data.

WEB SERVICES INTERFACES OPTIONS

Timeout Configure a timeout for synchronous Web Services. If the value specified is less
than or equal to zero, it is ignored, and Bizagi waits for a reply with success or
failure, no matter how long it takes. Since this can cause blockages we suggests
setting a value.

Logging Threshold Bizagi logs interfaces that last more than this time.

CANCEL NOTIFICATION OPTION

Disable cancel notifications When this option is selected the Cancel notifications will not be sent. Cancel
notifications are sent to all users who have pending tasks in a case that is

Page 466 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 OPTION DESCRIPTION

canceled in the Work Portal.

OPERATIONAL DATA STORE

ODS ODS (Bizagi Operational Data Store) is an optional mechanism that improves
Bizagi server's overall availability (enhances performance and reliability as well).

Provider Type ODS connection configuration.

Custom
Here you can see project parameters for the different environments.

To guarantee correct performance of all environments, Custom Parameters cannot be edited or deleted once they
have been deployed.

Security administration

Overview
Bizagi lets you use the Management Console to manage project security settings.

Page 467 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You can do this separately in each of the project's environments, and especially to perform changes on live
environments (production or test environment).

Open the Management Console to access this configuration in the Security module:

Settings you can manage include the authentication type used (Authentication), access control settings
(Authorization), and LDAP import settings.

Authentication settings
You can edit the type of authentication used by the project, and further parameters for the specific type of
authentication.

Authentication types available are:

Page 468 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Bizagi Authentication: Allows Bizagi to handle authentication itself (domain, users and their passwords are
stored in Bizagi).
· LDAP Authentication: Uses an LDAP server (i.e Active Directory) to verify information entered in the login page
(username, password and domain).
If you use authentication against an LDAP server, Bizagi does not store passwords.
· Federated Authentication: Uses an identity provider that authenticates the user and facilitates Single Sign-On
capabilities through federated services.
If you use federated authentication, Bizagi does not store passwords. Since authentication in Bizagi is entrusted to
the Identity provider, it needs to comply with SAML 2.0.
· Windows Authentication: Lets Bizagi validate users automatically against domains and Windows machines.
The Work Portal delegates authentication to the Windows machine on the client side (Bizagi does not store
passwords).
You can also have Bizagi take the Windows session credentials automatically and avoid a login page.
Windows authentication does not work for mobile devices if Anonymous Authentication is disabled. When you
enable the Anonymous Authentication. The Bizagi login page does not appear.
· Custom Authentication: Lets an external application handle authentication.
With custom authentication, you develop your own component which overrides the methods in Bizagi's
Authentication component.
The component you develop can rely on any APIs or other third-party components and connections to authenticate
the user (i.e. validate against a MySQL database, XML files, a legacy system's database, etc).
· Mixed Authentication: Allows using two different types of authentication for users from different domains. One
of the types must be Bizagi Authentication, and the other type may be either Windows or Custom Authentication.

Note these important points:

1. Authentication run on execution requires that any user wanting to log in to Bizagi is previously
imported/created in Bizagi's database (even though, with certain authentication types, further information such as
the password is not stored in Bizagi itself).

2. With any type of authentication, the default domain\admon system user should be kept as enabled, though this
user should not be assigned to a specific end user and should not be granted rights to use Work portal menus
and options.
Instead, we recommend that you define a user account as your business administrator, with privileges to run the
solution's administration (i.e modify parameter entity values, and manage your users, licenses, cases, etc).

Further authentication parameters to modify, according to the specific authentication type are:

Authentication Option Description

type

Defines the number of minutes an account remains locked out due

to reaching Maximum number of failed login attempts (and
Account lockout having set Enable account lockout for failed login attempts),
duration before automatically being unlocked.
This duration must be greater to or equal than Failed login
attempts time-out.
Bizagi
Defines the body of the mail to be sent to the administrator when
a user requests the unlocking of an account (when using Enable
E-mail for an account
account unlock request e-mails to admin and specifying E-mail of
unlock request - Body
admin).
Use with E-mail for an account unlock request - Subject.

Page 469 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Defines the subject of the mail to send to the administrator when a
E-mail for an account
user requests unlocking of an account (when using Enable account
unlock request -
unlock request e-mails to admin and specifying E-mail of admin).
Subject
Use with E-mail for an account unlock request - Body.

Defines the body of the mail to send to a user when the account is
E-mail for an active
created and set as active.
account - Body
Use with E-mail for an active account - Subject.

Defines the subject of the mail to send to a user when the account
E-mail for an active
is created and set as active.
account - Subject
Use with E-mail for an active account - Body.

Defines the body of the mail to be sent when the user requests a
E-mail for password
password reminder.
reminder - Body
Use with E-mail for password reminder - Subject.

Defines the subject of the mail to send when the user requests a
E-mail for password
password reminder.
reminder - Subject
Use with E-mail for password reminder - Body.

Defines the e-mail of the administrator of accounts in charge of

E-mail of admin receiving E-mail for an account unlock request (when using
Enable account unlock request e-mails to admin).

Enable account Sets whether accounts should be locked out when a maximum
lockout for failed login number of failed login attempts is reached (to use with Maximum
attempts number of failed login attempts).

Sets whether e-mails are sent when a user requests an account

Enable account unlock
unlock.
request e-mails to
Use with E-mail for an account unlock request, and E-mail of
admin
admin.

Enable authentication Sets whether an audit log is recorded with all authentication
logging in database events.

Enable multiple Sets whether more than one simultaneous session is allowed for
sessions per account the same account.

Applies only to the Development and Test environments.

Sets whether users can login to the Work portal without inputting
the passwords of accounts (a quick login through a drop-down list
Enable quick login displaying valid login accounts).
The drop-down list shows the first 100 active users (from the 101th
user, accounts need to be typed into a text field).
To use for unit tests or quick prototyping purposes (this setting is
not valid for a production environment).

Sets whether users can establish a secret question and answer to

Enable use of a secret
be able to avoid an account lockout when the password is
question
forgotten.

Sets whether a user must change the password after the first
Require password
login.
change after the first
Consider using this option or setting an explicit number of days
login
for Password minimum age.

Page 470 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Enforce password Defines the number of unique passwords an account must have
history before reusing an older one.

Enforce use of capital

Sets whether passwords must contain at least one capital letter..
letters in passwords

Sets whether passwords must contain at least one letter.

Enforce use of letters
Consider using Enforce use of capital letters in password and
in passwords
Enforce use of lowercase in password instead.

Enforce use of
Sets whether passwords must contain at least one number.
numbers in passwords

Enforce use of small Sets whether if passwords must contain at least one lowercase
letters in passwords small letter.

Enforce use of special

Sets whether passwords must contain at least one non
characters in
alphanumeric characters.
passwords

Enforce validation of
Sets whether passwords are allowed to contain character
sequences in
sequences (e.g: abc or 12).
passwords

Defines the number of minutes after which failed login attempts

time-out.
Failed login attempts
The counter that stores this number of attempts is reset after this
time-out
time frame, provided that the Maximum number of failed login
attempts is not reached.

Defines the maximum number of days before an unused account is

Idle account duration
locked out (unused accounts are those which have not had activity
before lockout
in that time frame).

Defines the time in minutes after which an idle session expires; in

which the user would have to authenticate their login again.
Idle sessions time-out If you wish to increment this time-out to more than 60 minutes (not
recommended), you need to edit the default settings for your web
server (directly at the IIS).

Maximum length of Defines the maximum number of characters for passwords (use
passwords zero if a maximum length is not desired).

Defines a maximum number of login attempts before an account is

Maximum number of locked out.
failed login attempts Applies when Enable account lockout for failed login attempts is
active.

Defines the minimum number of characters for passwords.

Minimum length of
Consider using this option or setting an explicit number of days
passwords
for Enable password change after the first login.

Defines the maximum number of days during which a password

Password maximum
can be used before it must be changed (i.e, the expiration time of
age
passwords).

Password minimum Defines the minimum number of days during which a password
age must be used before it is available for a change.

Page 471 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 SLA for an account Defines the expected service time (in hours) to process an account
unlock request unlock request.

LDAP AUTHOPTIONS_LDAP_
The path to access the LDAP Server (using the LDAP URL format).
Path

Applies if you already have configured Bizagi to synchronize with

AUTHOPTIONS_LDAP_ your Active Directory users.
UseIntegration If this is the scenario, turn this option on, to use the same LDAP
URL and settings from the LDAP synchronization settings.

Custom The name of the components assembly that performs

Custom Authentication
authentication. This components must be present in the Web
Component
application bin or in the GAC.

The name of the class that performs custom authentication within

Custom Authentication
the component specified. Include the namespace of that class (set
Class
as Namespace.Class).

Mixed The name of the domain for users who will be authenticated using
Bizagi Domain
Bizagi Authentication.

Other Authentication Select which other type of authentication will be used (Windows or
type Custom).

Authorization settings
You can edit the authorization settings to modify restrictions on which end users can modify or view certain
information and use administration options in the project.
Access rights to the different elements of the Work Portal are managed through the definition of roles and user
groups.

Page 472 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
In the Authorization component you can manage access to the following items:

MENU DESCRIPTION

Analysis Sets access to specific process information in the various

Process Analysis Tools.

If access is denied for a specific process, you can access

the Reports menu, but cannot view that process in the
Business Activities Monitoring BAM, Sensors Analytics
and Process and Task Analytics.

Applications Sets access to applications. These permissions are

granted for each application individually.

If permission is denied for a specific application, then

you cannot create new cases for any processes that
belong to that application or view cases related to such
processes in your Inbox.

You can still be assigned to tasks of a process that

belong to a restricted application, despite not having
access rights to the application. For this reason take
care when implementing this restriction.

Entities Sets administration privileges for Parameter entities in

the Work Portal. These permissions are granted for each
entity individually.

The administration privileges that can be set are:

· Full Control: Permits total administration of an entity.

You can create new records of the specified entity and
view and modify existing entities.

· View Data: You can only view records of the entity.

Changes to data will not be permitted.

· Modify: You can view and modify the records of the

entity, but cannot create new records.

· Create: You can create new records for the entity, but
cannot modify the existing records.

Manage Manages Alarms, Asynchronous Work Items, Cases,

Default Users and Profiles.

New Cases Set permission to create new cases. These permissions

are granted for each process individually.

If permission is denied for a specific Process, you cannot

create new cases of that Process; however, you may still
be assigned to activities belonging to such a restricted
process.

Pages Controls access to the menu and sub-menu pages of the

Work Portal. These permissions are granted for each
page individually.

Page 473 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 IMPORTANT: In the Analysis menu, the permissions
applied to All Reports cascade down to all sub-menus.
If access is denied in All Reports you cannot access any
of its features or lower level directories (sub-menus).

Policies Sets access to policies. These permissions are granted

for each policy individually.

If access is denied for a specific policy, the restricted

policy is not visible in the Business Policies menu of the
Work Portal; consequently, cannot gain access to it.

Queries Sets access to case queries. These permissions are

granted for each query individually.

If access is denied for a specific query, the related form

of the restricted query is not visible in the Queries menu
of the Work Portal.

Vocabularies Sets access for vocabulary management. These

permissions are granted for each definition individually.

If access is denied for a specific definition, the

vocabulary definition is not visible in the Business Policies
menu of the Work Portal; consequently, you cannot
modify it.

LDAP import settings

You can edit the connection and configuration parameters for importing of users from your LDAP system.

Page 474 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
When editing specifics on the connection to your LDAP and how the synchronization of users will be carried out (i.e
scheduled for what time frame), consider these settings:

Setting Description

Connection LDAP URL The URL path to access the LDAP server (LDAP URL format).

Domain\username A username and its domain, to be used as the authenticated user

performing the synchronization.

Password The password for the domain's authenticated user performing the
synchronization.

Synchronization hour An hour of the day in which the Scheduler will perform the LDAP
synchronization.
Allowed values for this field are 0 to 23.

Import Filter Input a filter to import only the proper accounts into your project
settings (according to an LDAP attribute criteria).
We strongly recommend that you use and set a filtering condition to
import the proper set of users (especially when testing the
configuration).
View more information about filter options at LDAP attributes.

Domain The domain name to which the users will be registered in Bizagi's
user entity (WFUser).

Page 475 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 User account identifier The LDAP attribute which identifies in a UNIQUE manner each
account. For example, sAMAccountName is the common LDAP
attribute corresponding to a user's account name.

When editing the attribute mappings (which set how information incoming from your LDAP is updated in Bizagi
users), you can add, edit or delete mapping rows under the definition of the Attribute mapping tab:

When editing the default values taken by some of the fields of information of users in Bizagi, you can add, edit or
delete rows under the definition of the Default values tab:

Page 476 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Do NOT specify that the enabled attribute is set to true, unless you are completely certain that your current
license support the number of imported users.
If the number of active users is greater than the number of licensed users, the Work Portal will stop working.

You can test this configuration (i.e. especially recommended if you changed critical aspects such as the LDAP filter),
and see the records found at Test results:

Page 477 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Testing the configuration does not imply that an immediate synchronization is carried out at Bizagi's database.
This is only for testing purposes and not persisted, since the Scheduler service will be in charge of executing your
final configuration.

Important
You can initially define the options in the Security module for the Authentication options and LDAP synchronization in
your Bizagi project, by using the Development environment for the Production environment (that is, using LDAP or
any other configuration related to the Work Portal's authentication method).

After your project is deployed to Production, these settings for that environment can no longer be edited directly in
the Development environment (they must be edited from the Management Console).
For the Test environment, values can be redefined in the Development environment (through Bizagi Studio), so that
a new deployment overwrites those values in the test environment.
You need to use the Management Console in the Production environment to edit defined Authentication and LDAP
settings.

This does not include Authorization configurations, which can be managed in Production directly through the
Management Console, and are always overwritten in Production with the incoming values from Development
when you execute a deployment.

Scheduled jobs administration

Overview
In the Bizagi Management Console, use the Scheduler module to directly administer Jobs which the Scheduler
service runs.
The following options are available for the Scheduler module.

Scheduler status
The Scheduler's icon indicate this service's status (gray when stopped, crimson when started).

You can start, restart or stop the Scheduler service directly from these options.
To do this, right click the Scheduler icon and select the action (Start, Restart, Stop). You can also select an action in
the Main menu area.

To use the Status options, the user opening the Management Console must be part of the administration group
of the server where the main scheduler is installed, because the scheduler is a windows service, and the user must
have permission to change its properties.

Page 478 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The scheduler MUST BE in started status in order any scheduled jobs.

Scheduled Jobs administration

Scheduled jobs are subdivided as described in this table:

Scheduled Job type Description

User Jobs Sets of steps that can be run according to a schedule:

run once by specifying a specific date, or run

Page 479 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 periodically during a given period of time. The status of
these jobs can be consulted in this category.

System Jobs Bizagi performs tasks automatically to make sure

proper system status. This category stores the jobs
related to system maintenance tasks.
We do not recommend that you manipulate the
information of system jobs (they are listed for tracking
and error diagnostics purposes).

Wait Jobs Scheduled jobs that are related to Process Activities.

In this category we find such jobs as timers and
Asynchronous Activities, and can consult their status.

Alarm Jobs Alarms are messages sent to different target groups

when an activity is about to expire, expires or has
already expired. In this scheduler category, the jobs
related to configured alarms are stored.

Notice that disregarding the classification above, all jobs appear under two lists: those waiting for execution, and
those successfully executed.

Waits retries and administration

You can manage a waiting job and choose to enable it for immediate execution.

Should any waiting job fail (or require transaction rollbacks), it will be still listed in a waiting status.

Within a job's administration options you can also view its execution log. To review a waiting job, double-click it:

Page 480 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Option Description

Job Schedules See the details of scheduled executions (planned jobs).

Job Execution Logs See the log of previous executions.

Enable Job to run Click this button to automatically enable a waiting job
and set it for immediate execution. The time will be set
to 10 minutes before the current time to be executed
the next time the scheduler runs.

Replication Management
You can manage and reconfigure the schedules for Replication in your project.
Within these options you can also disable scheduled executions.

Page 481 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Replication administration console
You can manage a waiting job and choose to enable it for immediate execution.
This option presents the following console and options:

Option Description

Replication Logs See the log of previous Replication synchronization

executions.

Schedule Now Click this button to set the Replication for immediate
execution.

Page 482 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Replication Schedule properties
You can review or edit the current settings for the scheduled execution.
This option presents the properties of the Replication Schedule.

For the setup presented in this tab, you can define the periodicity and frequency of execution according to the
options in the table below:

Schedule option Description

Enable Schedule for this Replication Mark this option for Bizagi to execute data replication from the external
source.

Periodicity Mark Daily, Weekly or Monthly to define how frequently Bizagi will
execute the Replication schema.

Every [...] day(s) This modifier further defines the interval selected in the above-
mentioned Periodicity option as follows.
· Daily option: Enter the number of days between repetitions of the
execution. Its default value is 1.

· Weekly option: Enter the number of weeks between repetitions of the

execution. Also, specify on which weekdays this schema will be
executed.

Page 483 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 · Monthly option: Enter the number of months between repetitions of
the execution. Additionally, select the day of the month in which this
schema will be executed.

Daily frequency Define if the execution happens once a day (and at which time), or if it
should be executed at a certain time interval (minutes or hours).

Beginning Set a starting date for this schema to begin its execution.

How to fine tune the Bizagi Scheduler in Cluster Environments

Overview
Configuring Bizagi Scheduler for better performance depends on each environment's configuration. It is dependent
on three factors: the client's infrastructure, parallelism, and the client's modeling. The best practice when tuning your
Bizagi Scheduler is to include performance check tasks that work together with load tests. This allows Scheduler
configuration fine-tuning to obtain the best combination in which the performance is optimal.

The following document presents a brief explanation of the keys used to do a Scheduler fine tuning. Furthermore, it
gives you details about the master and slave schedulers and details on how you can tune up the performance for
your Production environment.

Master and slave Scheduler

Take into account the following definitions for Master and Slave Scheduler.
· A Master scheduler is the scheduler which coordinates the tasks executed per each slave scheduler and runs
additional tasks such as the maintenance tasks. It is mandatory to have one and only one Master scheduler
configured.
· A Slave scheduler is the scheduler which processes an assigned task.

Configuration files
To fine tune the Bizagi scheduler, locate these files:

· Locate the web.config file located in C:\Bizagi\Projects\[ProjectName]\WebApplication and open it using the text
editor of your choice.

· Locate the BizAgi.Scheduler.Services.exe.config files located in C:\Bizagi\Projects\[ProjectName]\Scheduler folder

of every scheduler.

Page 484 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Add the configuration keys required to fine tune your Bizagi Scheduler in the <appsettings> key. Example:
<add key="AsyncTaskWorkingSetSize" value="10"/>

Configuration keys
According to the infrastructure of your project, take into account the following minimum configuration:

Configuration Key Description Default /Suggested

Value

ID_STACK_SIZE Add this key in the The default value is 50

web.config and and for production
BizAgi.Scheduler.Services. environments, it is
exe.config files of each recommended to increase
scheduler. The key reduces it to 500.
the locks on business IDs This value should never be
assignation during high decreased and each
rates of case creation. scheduler must have the
same value.

AsynchTaskWorkingSetSi Add this key in the The default value is 50.

ze BizAgi.Scheduler.Services.
exe.config files of each
scheduler. This key defines
Threaded Scheduler
the number of
configuration
asynchronous workitems
to be retrieved from the
database to be processed
per thread.

SchedulerAsyncProcessor Add this key in the The suggested value is

IntervalInMillis BizAgi.Scheduler.Services. 500.
exe.config files of each
scheduler. This key sets
the time in milliseconds
that define the threads at
internal scheduler
processor to wait for the
next execution of the

Page 485 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 asynchronous tasks when
the
BizagiSchedulerInterval
was executed.

JobWorkingSetSize Add this key in the The suggested value is 10.

BizAgi.Scheduler.Services.
exe.config files of each
scheduler. This key defines
the number of tasks of the
stack that will be provided
to be executed.

SchedulerMaxJobWaitInt Add this key in the The suggested value is 1.

erval BizAgi.Scheduler.Services.
exe.config files of each
scheduler. This key defines
the number of wait
execution time when the
jobs max number is
reached.

LaunchThreadForLog Add this key in the The suggested value is 1.

BizAgi.Scheduler.Services.
exe.config files of each
scheduler. This key defines
you need an extra thread
to improve the logging.

MaxThreadsForCustomJo Add this key in the The default value is 2.

bs BizAgi.Scheduler.Services. Take into account that this
exe.config files of each number CANNOT exceed
scheduler. This key defines the number of processor
the maximum number of cores. For example, if you
threads to run the custom have two quad-core
jobs. processors, the maximum
number should be 16.

MaxThreadsForJobs Add this key in the The default value is 2.

BizAgi.Scheduler.Services. Take into account that this
exe.config files of each number CANNOT exceed
scheduler. This key defines the number of processor
Enable a threaded option
the maximum number of cores. For example, if you
for each function
threads to run the jobs. have two quad-core
processors, the maximum
number should be 16.

MaxThreadsForAsyncEcm Add this key in the The default value is 2.

BizAgi.Scheduler.Services. Take into account that this
exe.config files of each number CANNOT exceed
scheduler. This key defines the number of processor
the maximum cores. For example, if you
number of threads to run have two quad-core
the ECM when the processors, the maximum
asynchronous feature is number should be 16.
active.

Page 486 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 MaxThreadsForAsynchW Add this key in the The default value is 10.
orkitems BizAgi.Scheduler.Services. Take into account that this
exe.config files of each number CANNOT exceed
scheduler. This key defines the number of processor
the maximum number of cores. For example, if you
threads to run the have two quad-core
asynchronous tasks. processors, the maximum
number should be 16.

BizagiSchedulerInterval Add this key in the The default value is 30.

BizAgi.Scheduler.Services. This key should be
exe.config files of each increased when
Scheduler execution scheduler. This key defines AsynchTaskWorkingSetSi
interval the time (in seconds) used ze increases. Increase this
by Bizagi to process the value by adding 15.
workitems retrieved from
the database.

DisableAsynchCaseClosin Add this key in the The default value is 0. Set

g BizAgi.Scheduler.Services. 0 for the Master scheduler
exe.config files of each and 1 for the Slave
scheduler. This key is used scheduler. It is mandatory
to name the primary to have one and only one
scheduler and ensure that Master scheduler
this scheduler will be the configured.
only one which runs the
maintenance tasks.
MASTER / SLAVE DisableInterfaceErrorLog Add this key in the The default value is 0. Set
ger BizAgi.Scheduler.Services. 0 for the Master scheduler
exe.config files of each and 1 for the Slave
scheduler. This key is used scheduler. It is mandatory
to enable the interface to have one and only one
error logger only on the Master scheduler
primary scheduler and configured.
ensures that this scheduler
will be the only one which
log all the interface errors.

Tuning up the Scheduler

The tuning of the values for the present keys must be performed according to the results of the performance
testing phase of your project. Follow these recommendations to tune up the performance:

· It is recommended to have an independent machine for the Schedulers.

· The ideal performance happens when the number of asynchronous workitems (MaxThreadsForAsynchWorkitems
key) is processed in the time frame defined by Bizagi Scheduler Interval (BizagiSchedulerInterval key). Increase
the AsynchTaskWorkingSetSize and BizagiSchedulerInterval key values until your asynchronous tasks are
processed in an optimal time.
· If you reach the maximum value for the MaxThreadsForAsynchWorkitems key, it is recommended to add another
scheduler using the default values and then, increase the values until you have the ideal performance.

It is recommended to perform continuous monitoring of your infrastructure. If you find any increase in terms of
Memory or CPU usage, you have to take the decision if you want to tune the schedulers or perform changes over

Page 487 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 the infrastructure to be able to support the increased demand of resources.

Scheduler 2.0

Overview
In large projects that demand high performance, and availability for the execution of a considerable number of
jobs, you have the possibility to upgrade the Scheduler version. You can update the Bizagi Scheduler to increase the
performance using multithreading capabilities, enhance reliability, and execute queued jobs considering a priority.
The new Scheduler, also called Scheduler 2.0, has the following characteristics:

· Jobs performed by the Scheduler 2.0 are always executed using queues; this avoids clogs or deadlocks of those
jobs.
· Jobs are queued using priority.
· Updating the Scheduler to the 2.0 version is transparent to end-users.
· After upgrading the Scheduler, there is no further configuration required in any Scheduler.

The following document presents the configuration procedure to upgrade the Scheduler to the 2.0 version and a
description of priorities handled by the Scheduler.

The Scheduler 2.0 is available from version 11.2.2 for On-premises projects and is compatible with version 1.0
because you can upgrade or downgrade anytime.

Before you start

Stop the Application Server and the Scheduler service. If you have a clustered architecture, stop both elements in all
nodes.

It is very important to stop all your servers and schedulers's services before the upgrade. Not doing this can
affect running jobs and they might not be executed or lost.

Upgrading Procedure
1. Configure Management Console’s setting file
Enable the update key in the Management Console. To do this open the Management Console’s
appsettings XML located in C:\ProgramData\Bizagi\Enterprise\BizagiMC

Page 488 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Add the configuration key in the <appsettings> tag:
<add key="EnableSchedulerUpgradeOption" value="true" />

2. Upgrade the Scheduler from the Management Console

Open the Management Console, select the Scheduler module and right click the Scheduler node then click
Upgrade, Bizagi displays the upgrading window:

Windows user opening the Management Console must be part of the administration group of the server where
the main Scheduler is installed. Additionally, you must run the Management Console as an administrator.

Page 489 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Select the Upgrade to Scheduler 2.0 option and click Execute. The updating procedure can take up to ten
minutes.

3. Check if the Scheduler is updated:

To check if the Scheduler is updated to the 2.0 version, execute the following query in the database:

IF EXISTS (SELECT TOP 1 * FROM BIZAGIINFO WHERE BAInfo = 'SchedulerVersion')

SELECT BAValue FROM BIZAGIINFO WHERE BAInfo = 'SchedulerVersion'
ELSE
SELECT 1;
The query returns 2, as in the version of the Scheduler.

4. Start the Scheduler service and application server in all your nodes. Then use the Workportal as usual.

Downgrade
It is possible to downgrade the Scheduler at any time if you notice unexpected behaviors in the execution of jobs,
parallelism issues or compromised application stability after the upgrade.

After upgrading, we recommend profiling and reviewing growth and deadlock metrics of the following tables in
your database:
· WFCASE
· WFCASECL

Page 490 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· WORKITEM
· WORKITEMCL
· BASCOPE
· BASCOPELOG
· CURRENTASSIGNEE

If you find any anomalies you can downgrade the Scheduler following these steps:

1. Stop the application server and Scheduler services in all your server nodes.
2. Review if the appsettings key is enabled.

Open the Management Console’s appsettings XML file and check if the Upgrade Option key is enabled:

<add key="EnableSchedulerUpgradeOption" value="true" />

3. Open the Management Console, select the Scheduler module and right click the Scheduler node, Bizagi displays
the upgrading window. Uncheck the Upgrade to Scheduler 2.0 option and click Execute.
4. You can review the version of the Scheduler using the database query. It returns 1, as in the version of the
Scheduler.

Downgrading the Scheduler does not affect the execution of running jobs after the downgrade.

Jobs Priority
The Scheduler 2.0 executes jobs considering their priority. Priority is defined with a number from 1 (Highest) to 5
(lowest). The priority can be set depending on the job type and is defined as follows:

Job Type Description Priority

Business The following It is predefined as 1 and cannot be changed.

Processes jobs elements
configured in
Bizagi Studio or
the Workportal:
· Timers
· Alerts
· User jobs

Asynchronous Invocation and You can define the priority on the task properties set in the model. If a
activity jobs retries of Web Service task has priority 0 is considered as a job with priority 3 (Normal).
Services,
Connectors or
Bots in Services
tasks or Bots
tasks as
Asynchronous
Activities
executed by the
Scheduler.

Page 491 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 System jobs Jobs executed by They are executed based on each Scheduler’s load in small batches. That is,
the Scheduler for when the system recognizes low load in each Scheduler, it executes the
system system job. Programmed jobs are queued with the same priority at the time
maintenance as they are scheduled.
described at
Scheduled jobs
administrator ,
LDAP
synchronization
and replication
jobs.

Tuning the Scheduler 2.0

The Scheduler 2.0 handles automatically the logic to execute jobs the fastest and efficient way possible . The
Scheduler 2.0 executes jobs based on the priority and load of each Scheduler. This version uses multithreading
capabilities of the CPU and executes multiple jobs considering the priority and job type. Additionally, jobs are
queued. That is, the Scheduler never clogs jobs. If by any reason a job is not executed successfully, it is queued and
later retried considering the priority. Therefore no tuning is needed.

The Scheduler 1.0 has the option to fine tune the performance using keys, refer to How to fine tune the Bizagi
Scheduler. In the Scheduler 2.0 version, these keys are obviated. Any configuration set on these keys has no impact
upon the Scheduler 2.0 performance, and it remains using the queuing logic previously described.

Managing external systems

Overview
Bizagi lets you use the Management Console to manage the information of external systems and applications
integrated in the processes.
Manage this information (Interfaces and ECM parameters, connected databases through Replication and
Virtualization, etc) separately for each of the project's different environments.
The options presented next, are available through the Management Console.
For general information about this tool, refer to Management Console.

Administration of external systems

Opening the Management Console and, locate the External Systems module which presents your configured
integrated systems:

Page 492 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
For further information on how to manage the values, refer to the sections below:
· Connectors administration: To edit connection parameters (typically authentication credentials) involved in the use
of a Bizagi connector.
· SAP administration: To edit connection parameters to your SAP system integrated through the use of Bizagi SAP
Connector.
· Excel administrator: To edit connection parameters to your Excel connector.
· Web services administration: To edit values set in external services invoked from Bizagi processes.
· Data sources administration: To follow up or edit values set for connected databases (Replicated or Virtualized
entities).

Managing integrated Connectors

Overview
Connectors in Bizagi are portable modules that allow you to extend functionality by integrating with other systems
or applications.
Bizagi lets you to manage the connectors installed in your project, for a testing or production environment. You can
manage the values used in their connection (authentication parameters), as described at External systems
administration.

Bizagi presents these integration features for connectivity with other systems, which are already included in every
project: SAP Connector and its generic Web services connector.
These two connectors are managed using the options in the Management Console for their specific use.

Managing connectors
Administration tasks which you can carry out for your installed connectors are changing values for authentication
parameters. To do so, click the External Systems module and locate Connectors.

Page 493 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Expand the details of the installed connector and the version you want to edit, and right-click system configuration
instance to edit its values:

You can edit values such as the description of the connector, and its global attributes, it presents a set of these.

Authentication parameters
The parameters used by each connector depend on what that connector does and uses (especially if it is of the
Custom type). You need to know the credentials involved in its use before committing any changes.
The following parameters illustrate parameters typically used by supported authentication methods in Assisted REST
connectors (Basic, Digest, OAuth).

Page 494 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Basic Authentication
Basic authentication typically use username and password:

Digest Authentication
Digest authentication typically use username and password:

OAuth2 Authentication
OAuth2 authentications use different parameters according to its authentication sub-type.

i. Client credentials grant:

Page 495 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 ii. Resource owner credentials grant:

Managing integrated SAP systems

Overview
With the SAP-certified Bizagi SAP connector, you can integrate your SAP ERP systems from Bizagi processes.
Bizagi lets you manage information of the external systems and applications integrated in the Processes for testing
or production environment, as described at External systems administration.

SAP connection parameters

Edit the connection parameters of your SAP system by locating the SAP connector item in the External systems
module.
Right-click the properties of your given SAP connector configuration:

Page 496 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
If any of these parameters changes in your SAP system, you can edit them in Bizagi for your specific environment
(test or production).

These parameters are relevant to your integration with SAP:

· Application Server Host: The IP address or name of your server hosting your SAP system.
· Client: The number of the client accessing the SAP system.
· Idle timeout: The timeout in seconds for idle connections.
By default, you can assign a value of 600.
· Language: The 2-letter ISO code that represents the language setting (as input when accessing SAP through SAP
Logon).
· Peak connections limit: The maximum number of connections you allow through the SAP connector.
By default, you can assign a value of 10 connections.
· Pool size: The number of connections that will be handled for reuse.
By default, you can assign a value of 5.

Managing integrated Excel connector

Overview
With the Excel connector, you can integrate your Excel Spreadsheets with a Bizagi process.
Bizagi lets you manage information of the external systems and applications integrated with the processes for
testing or production environment, as described at External systems administration.

Excel connection parameters

Edit the connection parameters of your Excel integration by locating the Excel connector node in the Systems
module.
Select the connector version that you want to edit. Right-click it and select the properties option.

Page 497 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
A new window will appear where you can see the configuration of this version of the Excel Connector. Here you can
also see the sequences of steps and the configuration of each step. Most fields in this view are read-only. The only
exception is the Choose an Excel file button.

When you click it a file chooser lets you select the new spreadsheet where the actions execute in your test and
production environment.

Page 498 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Managing integrated Web services

Overview
Interface configuration refers to using Bizagi's Web services connector, to integrate with SOAP or REST services.
Bizagi lets you manage the parameters used by the integration points of your processes in a testing or production
environment, as described at External systems administration.

Through the options presented in the Systems module view, in the Development environment you can define new
interfaces which are integrated to your Bizagi Processes, or edit the details of existing ones (to manage testing or
production environments).

The interfaces listed in a system, include those invoking a SOAP web service and those invoking REST services.
Interfaces for SOAP web services are identified with this icon:
Interfaces for REST services are identified with this icon:

Editing an existing interface

Once an interface has been defined and configured in a Process, you can edit its information. Similarly as in the
interface creation, you can edit or include authentication credentials (for HTTP basic authentication), and manage the
Service's URL.

To locate these set interfaces, go to the Module view and click on the External Systems module.
To edit an existing interface, right-click at the given interface and click on its Properties option:

The following window appears:

Page 499 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
By default, the new interface is treated as a SOAP web service interface (Service Type = SOAP).

Editing REST services URLs has certain considerations for Base URL management.
For more information about the considerations, see REST services interfaces.

The following fields are available:

· Interface Name: The unique name for this interface which must not contain blank spaces (mandatory).
· Service Type: Possible values are SOAP or REST. When you choose REST as the service type, there is no field to
specify the service's method.

Page 500 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Interface properties table: A set of values for configuring the project's environments (Development, Test or
Production). This set includes:

Property Description

Web service URL The URL to access the service. For REST services, this is the Base URL.

Username When the service requires HTTP basic authentication, this username is required for
service access.

Password When the service requires HTTP basic authentication, this password is required for
service access.

Domain When the service requires HTTP basic authentication, this domain is optional to
complement the username, for service access.

Logging Threshold (In The time in seconds of an expected service threshold for the interface.
Secs) If the invocation exceeds this time execution, then the system records a trace line in the
.csv log at .\Temporary\SOA\Log\ path of your project (by default, one file per web
service, as C:\Bizagi\Projects\[your_project]\Temporary\SOA\Log\[your_interface]
Log_1.csv).
This is helpful for monitoring, since each invocation that exceeds the threshold or
produces a timeout records details of: DateTime, ErrorDescription, idCase,
Task_Name, URL, Method_Name, and InterfaceTime(MM:ss:mmm).

The default value is set to 30 seconds. so that it will always records execution details
when an invocation exceeds this time.

Time-out (In Secs) The time in seconds which defines when to time out any attempt to invoke the
interface.
If the invocation exceeds this definition in execution, the invocation throws an error that
is recorded in a trace line in the .csv log at the .\Temporary\SOA\Log\ path of your
project (by default, one file per web service, as C:\Bizagi\Projects\[your_project]
\Temporary\SOA\Log\[your_interface]Log_1.csv).
This is helpful for monitoring since each invocation that exceeds the threshold or
having produces a timeout records details of: DateTime, ErrorDescription, idCase,
Task_Name, URL, Method_Name, and InterfaceTime(MM:ss:mmm).

By default, the value is -1, which means that interfaces do not have an initial definition
of when to timeout.
The invocation times out according to this setting or the one defined for the activity if
the invocation is done from an asynchronous activity (whichever has the lowest timeout
definition).

Port Name Provide a specific port name when there is the need to execute a SOAP web service
that offers different service ports (i.e. SOAP 1.1, SOAP 2.0, etc.).
This port name can be configured separately according to each environment (i.e
Development, Test, Production).

Provide the port name exactly as specified at the end of the service's WSDL definition:

Page 501 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Max Buffer Size Increment this value if you need to send a lot of information to your Web service (i.e a
large file) that would normally exceed the default limit.
Corresponds to the attribute maxBufferSize of the bindings element of the
Windows Communication Foundation (WCF) configuration file. Sets the maximum size
of the SOAP headers.

Max Buffer Pool Size Increment this value if you need to send a lot of information to your Web service (i.e a
large file) that would normally exceed the default limit of sent information.
Corresponds to the attribute maxBufferPoolSize of the bindings element of the
Windows Communication Foundation (WCF) configuration file. Sets the maximum
amount of memory (in bytes) allocated.

Max String Content Increment this value if you need to send a lot of information to your Web service (i.e a
Length large file) that would normally exceed the default limit of sent information.
Corresponds to the attribute maxStringContentLength of the readerQuotas
element of the Windows Communication Foundation (WCF) configuration file. Sets the
maximum string length of the response.

Max Array Length Increment this value if you need to send a lot of information to your Web service (i.e a
large file) that would normally exceed the default limit of sent information.
Corresponds to the attribute maxArrayLength of the readerQuotas element of
the Windows Communication Foundation (WCF) configuration file. Sets the maximum
allowed array length.

Max Bytes Per Read Increment this value if you need to send a lot of information to your Web service (i.e a
large file) that would normally exceed the default limit of sent information.
Corresponds to the attribute maxBytesPerRead of the readerQuotas element of
the Windows Communication Foundation (WCF) configuration file. Sets the maximum
allowed bytes returned for each read.

Max Name Table Char Increment this value if you need to send a lot of information to your Web service (i.e a
count large file) that would normally exceed the default limit of sent information.
Corresponds to the attribute maxNameTableCharCout of the readerQuotas
element of the Windows Communication Foundation (WCF) configuration file. Sets the
maximum characters allowed in a table name.

The values and data types of the attributes of Microsoft's Windows Communication Foundation (WCF) as
explained above (parameters such as: max buffer size, max buffer pool size, max string content length, max array
length, max bytes per read, and max name table char count), are set in the XML configuration file as shown
below:

Page 502 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 This is the structure that Bizagi builds for the Web Service invocation.

· Advanced Web services security:

Click this button to configure the type of security you want to use to authenticate and invoke your web service.

This definition differs from the basic authentication credentials specified in the above properties (username,
password, domain) because it is used for Bizagi to access the WSDL and physical resources used by the web service
definition, while the definition in this configuration determines the security involved at runtime for the web service
itself.

Possible definitions you can edit and manage for an interface already set in your environment are:

Option Description Specification

Plain Header Token Sends the user's token (usernameToken) within the SOAP According to the technical
header message, according to the WS-Security standard. definition at:
https://www.oasis-
open.org/committees/downlo
ad.php/16782/wss-v1.1-spec-
os-UsernameTokenProfile.pdf

Secure Conversation Sends the user token according to the spec, by According to the technical
Header Token considering an appropriate certificate installed at the definition at:
client. http://docs.oasis-
open.org/ws-sx/ws-
secureconversation/200512

Page 503 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Basic HTTP Sends the credentials which apply when the service's According to the technical
Authentication end-point is protected (at a basic authentication level). definition at:
http://www.ietf.org/rfc/rfc2617
By default, Bizagi attempts to use Basic HTTP .txt
Authentication if no security definition is specified, and if
you are relying on basic authentication to protect the
service's resources (using the set credentials at the other
properties: username, domain and password).

· Do not generate proxy in execution (generate now):

Bizagi generates a proxy definition (a .cs and .dll file) when running on a .NET platform, for any external Web
services that are integrated in the processes.
By default, this will be done the very first time that the service is invoked in execution.

By generating a proxy at design time (in Bizagi Studio), you choose to use this definition on execution instead of
generating a newer one.
This option is useful when the setup of your Web services in a production environment has major security
restrictions (its definition resources such as the WSDL and related schemas are not easily accessed).

With this option, you can generate the proxy from a WSDL configured in another environment (e.g, the Development
environment).
To do this, use rely on the Use and generate from field to select the environment where the proxy will be generated.

For this feature to work, make sure that the WSDL involved to generate the proxy is the same one used in the
execution.

Managing integrated data sources

Overview
Data Replication and Data Virtualization in Bizagi let you to integrate external data sources in a seamless way into
your Bizagi processes.
Bizagi lets you manage the parameters used by the integration points of your processes in a testing or production
environment, as described at External systems administration.

Managing connectivity
Review or modify the connection settings to your integrated data sources, by following these steps:

1. Go to the Systems module (or refresh this view).

This displays your integrated system used for either Data Virtualization or Data Replication, under the External
Systems node.

Locate the System you configured for your integrated data sources. In this example, the system is called
Employees.

Page 504 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. Navigate the tree to find your configured providers.
All your configured providers are shown. Drill down to review the virtualized or replicated entities.

3. To display the connection settings, right click the provider you wish to review or modify, and select the properties
option.

Page 505 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
A window appears to display the connection details of the provider. On its upper ribbon, click the Development
Properties tab. There you can review or modify connection details.

Verifying scheduled execution

Once Data Replication is set in your project, you can verify that its execution synchronizes the values for Parameter
Entities with matching values from your external table's columns.
Review a scheduled Replication execution, follow these steps:

1. Go to the Systems module (or refresh this view).

This displays the integrated system used for Data Replication.

Expand the node elements, and browse your configuration to find the Replication Schema (it is in the particular
system, the Providers node, the specific provider, the Replicated Entities node, and finally the Default Replication
Class).

2. Right-click the Schema and select Replication Schema Properties:

Page 506 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
In the window that appears select the Replication Logs tab to display the date and time of replication executions.
For any replication showing an error instead of Success status, in the Execution Result column, you can see the Error
status, and its corresponding cause (message).

Page 507 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
When the Replication Schema has successful executed, you can look for the replicated entities values under the
Parameter Entities in Bizagi.
This option is used from Bizagi Work portal, in Entities administration.

3. In addition to this log, and to have job repetition run again, use the Replicate Now... option for your replicated
entities to start their synchronization immediately:

Page 508 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Diagnosing errors in integrated systems

Overview
During the development process (automation-of-processes stage), and in the Production environment, there are
situations when you need to trace or debug execution.

Bizagi lets you trace errors in the Processes Workflows (for control and diagnosis of issues) so administrators can
check whether the business rules, validations, interfaces invocations, or even the Process needs to be tuned up.

Tracing configuration
For a project's error control and diagnostic options, Bizagi presents its Tracing Configuration.

Page 509 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
This is a powerful option to help you detect and understand behaviors that require adjustment, and to make sure
the process you are testing works as expected.
Do not leave traces enabled, and only be turn them on to gather details when processes are not working as
expected.

In addition to Bizagi traces, can also review your server's log when using Automation Server.
In Windows OS, Bizagi writes event logs to the server (. You can review the log using the event viewer.

How does tracing work?

Traces monitor the Process at various levels, such as: the Process and its Activities, the business rules, validations
and business policies, interfaces invocations, and forms controls.
In other words, you can trace the entire Process and the objects and components that make up the Work Portal.

To enable and configure tracing, you can enable each object/component separately and set a filter so that the
generated logs include the level of details that you want (warnings and errors, or errors only).

The steps to accomplish this are:

Page 510 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
1. Decide which traces to enable (for the different objects and components).
2. Define their trace detail.

In addition to the trace detail, we recommend that you to view the events logs of your server if you are using
WebSphere, Weblogic, JBoss or IIS. The logs will help you find error details whenever you are debugging your
processes.

1. Decide which traces to enable

Use the Management Console to enable traces in a Test or Production environment.

The trace feature for debugging purposes (e.g traces for expressions) is mainly oriented to the Development
environment.
We strongly recommend that you exploit this feature while testing the Processes so that you only need to use it in
the Production environment when strictly necessary.
For example, when an external web service has changed and no preparations were made for this scenario, it can
be useful to enable traces in the Production environment to help detect unplanned behaviors.

Select the Tracing configuration window to see the available objects and components:

Page 511 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
It is important to plan which traces you wish to enable.
The following table describes the possibilities regarding the logs for these objects and components:

ELEMENT DESCRIPTION

Authentication Logs when a user is being authenticated in the System

(User Request) and when the System is validating a
Request Session (Validation of Request Session). Details
such as date, level, trace name, trace type and sub-

Page 512 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 type, type and sub-type of authentication and message,
are added to the log file.

Connectors / WS Connector Logs when an external interface is invoked. This option

traces requests and responses.
For more information about tracing Web service
invocations, refer to Web services error control and
diagnostics.

Connectors / SAP Logs when an SAP BAPI is invoked. This option traces
Import and Export parameters.
For more information about tracing SAP BAPI
invocations, refer to SAP error control and diagnostics.

Connectors / External Connectors Logs when a Connector Action is executed. This option
traces input, output, data transformation and connector
logic of the Connector.

EntityManager Logs the execution of EntityManager activity (database

access).

LDAP Logs the execution synchronization of LDAP users into

Bizagi.

Render (Control) Logs the construction of a form in the Work Portal

(rendering forms and their controls).

Rules Logs the execution and evaluation of business rules and

policies.

When the Custom sub-item is selected, it logs the user-

defined traces which are manually included in Business
Rules using the CHelper.trace function.

Scheduler Logs the execution of the Scheduler's jobs.

Workflow Logs when a transaction begins, when the information

is saved in the database, when a case is created and
the execution of each shape.

When the Assignment sub-item is selected, it logs the

assignment rules execution as well.

The following image illustrates all types of traces in Bizagi:

Page 513 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. Define the trace details
To decide what alerts to trace (the detail level), in the selected Tracing option in the Standard Menu, click the trace
type and select its detail level (Error, Warning, All).

Page 514 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
By default, None is selected (an empty box is shown) for all trace objects/components.

When Error is selected, the trace file only logs errors.

When Warning is selected, the trace file logs both warnings and errors.
When All is selected, the trace file logs: warnings, errors and step-by-step information about the executed
commands.

You can select a trace detail configuration for each trace type and its subtypes.

After saving changes on these items, you may need to restart your Work portal service (e.g. IISreset command in
IIS).

Trace locations
Once enabled, traces are saved as plain text files on the Bizagi Server.

They are located, according to the specific web and application server used as the Bizagi Server.

ELEMENTS LOCATION

Authentication C:\Bizagi\Projects\[project_name]\Trace\

Page 515 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 EntityManager

LDAP

Render (Control)

Rules

Scheduler

Workflow

Connectors / WS Connector C:\Bizagi\Projects\[project_name]\Temporary\SOA\

For Asynchronous SOA Interfaces configured to retry on

fail, the traces of each retry are located in:

C:\Bizagi\Projects\[project_name]
\Temporary\Scheduler\SOA\

Connectors / SAP C:\Bizagi\Projects\[project_name]\Temporary\SAP\

Connectors - External Connectors Logs for inputs and outputs:

C:\Bizagi\Projects\[project_name]
\Temporary\Connectors\

Log for the connectors' framework:

[Bizagi_installation_path]
\ConnectorsService\framework\Logs\Connectors\[proje
ct_name]\
Bizagi's default installation path, which is usually at C:
\Program Files\Bizagi\Bizagi Studio

Examples and more information

Refer to the following for examples and detailed information for the most common traces.

Work Portal (web application) trace

The Work Portal trace logs the details of executions for the Web application.
These logs are found in the .\Trace folder as split logs named BATrace_Web_[date].log.

The following example illustrates the logged information in these files:

Page 516 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Scheduler trace
The Scheduler trace logs the details of executions carried out by this thread.
These logs are found in the .\Trace folder as split logs named BATrace_Scheduler_[date].log.

The following example illustrates the logged information in these files:

Expression traces (Business rules)

For this option, in addition to activating the corresponding trace option and levels, you need to include a trace
command line in the code of each Expression (business rule) you want to trace.
This approach will record in a separate log, any customized information that the user wants to trace within the rule.
For more information refer to Validating my business rules.

Authentication traces
When you integrate a SAML-compliant Identity provider for Bizagi to delegate authentication to it, logged detail you
may review, includes:
· USERREQUEST: Provides a message for the information sent from Bizagi to the Identity provider (regarding the
user's request to log in).
· VALIDATESESSIONREQUEST: Provides a message for the response from the identity provider received by Bizagi.

The following image illustrates an example of an authentication tracing file:

Connector traces
· For more information about tracing Web service invocations, refer to Diagnosing Web services errors.
· For more information about tracing Connectors invocations, refer to Connectors Web services errors.
· For more information about tracing SAP BAPI invocations, refer to SAP Web services errors.

Diagnosing Web services errors

Overview
When configuring Web service invocations in Bizagi, you can rely on several features for error control and
diagnostics.
One of these features is using Traces whenever you detect there is an issue with the Web service invocation, and
you wish to retrieve further detail.

Web Services traces

When you are debugging a Web service invocation (in Development environments) or wish to retrieve further details
about a failed invocation, youcan turn on the WS Connector traces.

Page 517 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Interface traces can be enabled from either Bizagi Studio or the Management Console but we strongly
recommend that you enable them temporarily only when you need them, and afterward, disable them.
Changes in this configuration will probably require a reset for your Work portal services.

These traces can help you track down at which point the execution fail, since there are six points where details are
logged and you can diagnose a problem at your Web service (target's invocation) or when transformations were
being applied to the information.

Types of traces
The following traces are logged in chronological order:

Chronologica Trace type Description

l order

1 Request Writes an XML-structured log with the business information

retrieved from Bizagi.
Its name has the following convention:
[case_identifier]_BizAgiSOARequest_[timestamp].json

Page 518 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 The timestamp is set as yyyyMMddHHmm.

2 Request transformed Wirtes an XML-structured log with the result of an applied

transformation (either a custom XSLT or out-of-the-box
mapping functions), to the business information retrieved from
Bizagi.
Its name has the following convention:
[case_identifier]
_BizAgiSOARequestTransformed_[timestamp].json
The timestamp is set as yyyyMMddHHmm.

3 SOAP Message body - Applies for invocations to SOAP Web services (RESTful services
Request not included).

Writes information in a log with details regarding the invocation,

including information sent in the request.
Its information is logged in a file with the following naming
convention:
SOAP_TraceVersion02_[timestamp].svclog
The timestamp is set as yyyyMMddHHmm.

In earlier Bizagi versions, it logs the XML body content of the

information just as it is sent to the external system and without
the SOAP header information.

4 SOAP Message body - Applies to invocations to SOAP Web services (RESTful services
Response not included).

Writes information in a log with details regarding the invocation,

including information received from the response.
The information is logged in a file with the following naming
convention:
SOAP_TraceVersion02_[timestamp].svclog
The timestamp is set as yyyyMMddHHmm.

In earlier Bizagi versions, it logs the XML body content of the

information just as it is received from the external system and
without the information contained in the SOAP header.

5 Response Writes an XML-structured log with the returned business

information, just as returned by the web service.
Its name has the following convention:
[case_identifier]_BizAgiSOAResponse_[timestamp].json
The timestamp is set as yyyyMMddHHmm.

6 Response transformed Writes an XML-structured log with the result of an applied

transformation (either a custom XSLT or by means of out-of-
the-box mapping functions), to the business information
returned by the web service.
Its name has the following convention:
[case_identifier]
_BizAgiSOAResponseTransformed_[timestamp].json
The timestamp is set as yyyyMMddHHmm.

Two additional traces are available to help verify how the inputs and outputs were mapped when configuring the
integration.

Page 519 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Trace type Description

Request mapping JSON Useful mainly on production environments, as it is the immediate way to
verify how the mapping was configured.

Writes a JSON-structured log with information of how the mapping is

done for the input parameters (including any transformation functions).
Its name has the following convention:
[case_identifier]_BizAgiSOARequestMapping_[timestamp].json
The timestamp is set as yyyyMMddHHmm.

Response mapping JSON Useful mainly on production environments, as it is the immediate way to
verify how the mapping was configured.

Writes a JSON-structured log with information of how the mapping is

done for the output parameters (involving transformation functions).
Its name has the following convention:
[case_identifier]_BizAgiSOAResponseMapping_[timestamp].json
The timestamp is set as yyyyMMddHHmm.

Additional measure oriented to error control

We strongly recommended that you also define the service's expected time, so that you can explicitly assign both: a
timeout for the service, and a logging threshold.
· The logging threshold parameter for interfaces writes a log to alert you about interfaces whose invocations are
delaying more than expected. In this way, you can perform early diagnostics on your Web service and any
additional variables affecting its performance.
· The timeout thrown in a service invocation is due to the service delaying more than its timeout definition.
For a service invoked in an asynchronous activity, the timeout definition is taken from the minimum time set from
either: the timeout property set for the asynchronous task, or the timeout property set for the specific interface
(through interfaces administration in the systems module).

For more information about these two2 options, refer to Interfaces administration.

How to trace your Web service?

With the following steps, we will illustrate how to use the interface invocations trace to detect and diagnose issues in
external Web services invocations.

1. Detect the error

As a most common practice, you may find that your Web service is invoked from an Asynchronous Activity.
Should the invocation fail, further error detail can be viewed from the Admin menu, in the Asynchronous Activities
console option.

Page 520 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. Setup trace configuration
Through the Tracing options, enable all interfaces traces.

3. Re-run the interface invocation (to log the error details)

Retry the invocation of the interface to generate a log with error details.

On your Bizagi server, browse into the SOA interfaces traces folder (in this .NET example, the location would be C:
\Bizagi\Projects\[project_name]\SOA).

You will not have all the files recorded.

For example, if an error occurs in the extraction of data from Bizagi, only the first file (Request mapping) appears
because the error occurred before the request was made.

4. Validate the traces to identify the error

Validate information contained in the traces.

If you find that all of the files are there, and the error seems to be when Bizagi calls the Web service, you can review
the SOAP_TraceVersion02_[timestamp].svclog or send it to our support team.

Page 521 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You can view this log can be viewed with the SvcTraceViewer provided by Microsoft within its 4.0 .NET framework.

Diagnosing Connectors errors

Overview
When configuring Connectors in Bizagi, you can rely on several features for error control and diagnostics.
One of these features is the use of Traces whenever you detect there is an issue with the execution of the Connector,
and you want to retrieve further details.

Before tracing your connectors, make sure that the Connector Service is up and running. Otherwise, the connector
does not run, and thus, it does not generate traces.

Page 522 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Connector traces
When you are debugging a Connector execution (in Development environments) or want to retrieve further details
about a failed execution, you can turn on the External connectors traces.

Page 523 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Connectors traces can be enabled anytime, but we strongly recommend that you enable them temporarily when
you need them and disable them again when you are done.
Changes in this configuration will probably require a reset in your Work portal services.

Enabling these traces is useful to track down, after an error in the application, the exact point where the error
occurred. There are five points where details are logged and you can diagnose whether there is a problem when
executing your Connector, or when transformations were being applied to the information.

Types of traces
The following traces are logged:

Chronological order Trace type Description

1 Inputs Writes a JSON file with the inputs sent

to the Connector before the execution
of its logic.
Its name has the following convention:
[timestamp]_[case_identifier]
_IN0_[Connector name]_[action
name].json
The timestamp is set as
yyyyMMddHHmmss.

2 Inputs transformed Writes a JSON file with the inputs sent

to the Connector after the execution
of its logic.
Its name has the following convention:
[timestamp]_[case_identifier]
_IN1_[Connector name]_[action
name].json
The timestamp is set as
yyyyMMddHHmmss.

3 Outputs Writes a JSON file with the outputs

received from the external system
before any transformation done by
Bizagi.
Its name has the following convention:
[timestamp]_[case_identifier]
_OU0_[Connector name]_[action
name].json
The timestamp is set as
yyyyMMddHHmmss.

4 Outputs transformed Writes a JSON file with the outputs

received from the external system
after all transformations done by
Bizagi.
Its name has the following convention:
[timestamp]_[case_identifier]
_OU1_[Connector name]_[action
name].json

Page 524 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 The timestamp is set as
yyyyMMddHHmmss.

5 Connector logic Leaves four .log files:

Connector log
· [connector name].[connector
name].log stores all the LOG
commands found during the
Connector logic execution. More
information about these commands
can be found in this article.
Service logs
· bz-facade.log stores the history of
methods invoked by the Connector
Service.
· facade-exceptions.log stores the
errors raised by asynchronous
functions. For example, error in the
callback of a REST request.
· [connector name]-bz-ctrl.log stores
the logs of the connector service
controller.

Note that timestamp is set as

yyyyMMddHHmm.

Additional measures for error control

We strongly recommend that you define the service's expected time, so that you can explicitly assign both: a
timeout for the service, and a logging threshold.
These properties can be set at the specific interface's properties:
· The logging threshold parameter for interfaces writes a log to alert you about interfaces whose invocations are
delaying more than expected. In this way, you can perform early diagnostics on your Web service and any
additional variables affecting its performance.
· The timeout thrown in a service invocation is due to the service delaying more than its timeout definition.
For a service invoked in an asynchronous activity, the timeout definition is taken from the minimum time set from
either: the timeout property set for the asynchronous task, or the timeout property set for the specific interface
(through interfaces administration in the systems module).

How to trace your Web service

In the following steps, we illustrate how to use the interface invocations trace to detect and diagnose issues in
external Web services invocations.

1. Detect the error

As a most common practice, your Web service may be invoked from an Asynchronous Activity.
Should the invocation fail, you can review error details from the Admin menu, in the Asynchronous Activities
Console option.

Page 525 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. Setup the trace configuration
Through the Tracing options, enable all the Interface traces.

3. Re-run the interface invocation (to log the error detail)

Retry the invocation of the interface to have a log with details on the faliure.

Browse into your Bizagi Server and into the Connectors traces folders (in this .NET example, the locations are
typically C:\Bizagi\Projects\[project_name]\Temporary\Connectors and C:\Program Files\Bizagi\Bizagi
Studio\ConnectorsService\framework\Logs\Connectors\[project_name]).

You may not have all files recorded.

For example, if an error occurs in the transformation of inputs from Bizagi, only the first file (Inputs) appears
because the error occurred before the transformation was made.

4. Validate the traces to identify the error

Review information contained in the traces.

Service Connector monitor

When you install Bizagi, additional to the Connector service, a Windows scheduled task is installed, that constantly
monitors the activity of the Connector service, and register in logs if the service is running. If not, this task tries to
reset the service, so it can be running up again.

Scheduled task
When you open the Task Scheduler in the Windows server where Bizagi is installed, you can find the Connector
Monitor folder, in the Task Scheduler Library.

Page 526 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
What this task does, is executing a dummy connector, that verifies that the Connector service is up and running
correctly. This task is set to be executed every three minutes, as follows:

Page 527 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 We do not recommend reducing the repetition time because it can affect the performance of the Connector
service.

The logs associated with this task are stored in the following path:

Bizagi Studio: C:\Program Files\Bizagi\Bizagi Studio\ConnectorsService

Bizagi Engine: C:\Program Files\Bizagi\Engine\ConnectorsService

Here you find the file Monitor.text:

Connectors in Bizagi relay on the Node.js framework, so it is important to monitor that no only the Windows service
is running, but also that the framework works correctly. So this task executes two monitor tasks: The first reviews
the status of the Connector windows service, the second reviews that the node.js framework works correctly.

Each record in the Monitor log has the following structure:

[TimeStamp] _ [Component] _ [Message]

Time Stamp: WeekDay dd/mm/yyyy HH:mm:ss:ms

Component: Monitor.bat is the result of the windows service request. Flow monitor.bat is the request to the node.js
framework.

Diagnosing SAP errors

Overview
When configuring SAP's BAPI invocations in Bizagi, you can rely on several features for error control and
diagnostics.
One of these features is the use of Traces when you detect there is an issue with the SAP BAPI invocation, and you
want to retrieve further detail.

Page 528 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
SAP traces
When you are debugging a SAP BAPI invocation (in Development environments) or want to retrieve further details
about a failed invocation, you can turn on the SAP traces.

You can enable Interfaces traces at any time, but we strongly recommend that you enable them only when they
are needed and afterward disable them.
Changes in this configuration require a reset in your Work portal services.

Enabling these traces helps you track down, after an error in the application, the exact point where the error has
happened. There are four points where details are logged and you can diagnose if there is a problem with your
SAP BAPI (target's invocation), or when transformations were being applied to the information.

Types of traces
The following traces are logged in chronological order.

Chronologica Trace type Description

l order

Page 529 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 1 Import Writes aa XML-structured log with information of how the
mapping is done for the Import parameters (involving
transformation functions).
The following naming convention is followed:
BizagiSAPImport[timestamp].xml
The timestamp is set as yyyyMMddHHmm.

2 Import Transformed Writes an XML-structured log with the business information

retrieved from Bizagi.
The following convention is followed:
BizagiSAPImportTransformed[timestamp].xml
The timestamp is set as yyyyMMddHHmm.

3 Export Writes an XML-structured log with information of how the

mapping is done for the Export parameters (involving
transformation functions).
The following naming convention is followed:
BizagiSAPExportTransformed[timestamp].xml
The timestamp is set as yyyyMMddHHmm.

4 Export Transformed Writes a XML-structured log with the business information

incoming from the SAP BAPIs export.
The following naming convention is followed:
BizagiSAPExportTransformed[timestamp].xml
The timestamp is set as yyyyMMddHHmm.

Bizagi versions (software upgrades)

Overview
Bizagi generates new versions periodically which include important improvements along with great new features.
We strongly recommend that you upgrade your projects to the newest release, so that you can enjoy all the benefits
of Bizagi new features, enhancements, major improvements and bug fixes (maintenance).

The newest versions for all Bizagi editions are available for download directly at www.bizagi.com.

Page 530 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You can also get Bizagi Studio prompts about new version releases if your installation settings are configured to
check for updates.

Bizagi versions
Bizagi versions are identified following this pattern:
[major_version_number].[minor_version_number].[update_number].[build_number]

In the Work portal, you can check which version of Automation Server you are using by clicking About:

Page 531 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The version should match the major and minor version that you use in your development environment to build your
processes:

When you open Bizagi Studio you will see a noticee about a new release, whenever a new minor version is available.
To learn the procedure to upgrade your Bizagi project to the latest Bizagi 11.2.4 release, refer to Upgrading the
minor version.

Otherwise and if you will be performing an upgrade that shifts to a new major version, then you need to assess
such upgrade as a migration procedure.

Upgrading the minor version

Overview
Bizagi generates new versions periodically which include important improvements along with great new features, as
described at Bizagi versions.
We strongly recommend that you upgrade your projects to the newest release, so that you can enjoy all the benefits
of new Bizagi features, enhancements, major improvements and bug fixes (maintenance).
This section details how to carry out a software upgrade of your Bizagi version.
This procedure is applicable only when upgrading to the newest minor version (while in the same major release).

You must upgrade to this release from a Bizagi project already using a 11.2.0 version or higher.
If you have a lower version please contact Support.

Before you start

Before upgrading your project, keep in mid the following:

Projects using WS-Federation authentication

To keep compatibility with our cloud-based service, Automation Service, the updates to the 11.2.4 version does not
change the Web.config file with the WS-Federation configuration. Before updating your project, change the
authentication type to Bizagi. After you successfully update your project, configure the WS-Federation authentication
type again.

Page 532 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Make backups
Create a database backup file and copies of the folders and files by default at C:\BizAgi\Projects\[your_project]
\WebApplication and
C:\BizAgi\Projects\[your_project]\Scheduler\.

Although we recommend that you create your own backups of the project's environments, Bizagi automatically
generates a backup of: the database, the Scheduler and the files used by the Work Portal before performing the
upgrade.
In the event of a failure to upgrade, Bizagi rolls back to and restores the state of the environment by relying on
these backups.

If you need these backup files, they are stored in the backup path (in a SQL Server local setup, this would be: C:
\Bizagi\Projects\[your_project]\Backups), as shown in the image below:

When you use the SQL Server Database remotely, the path for backups is usually set on the database server as: C:
\Program Files (x86)\Microsoft SQL Server\[MSSQL_instance]\MSSQL\Backup\.
In projects using Oracle as the Database, the backup path is as defined for that given Oracle instance (during initial
project configuration) is the property BA_BACKUP_PATH.

Upgrade the development environment first

Always upgrade the development environment first.
We recommend that you perform unit tests in the Development environment after you have completed the upgrade
to verify that existing processes behave as expected.
Once this is done, upgrade and perform user-acceptance tests for your Test environment.

After verifying that processes work as they should in both the development and the test environment, and
depending on how critical your processes are, you may create a production-replica environment.
In Production-replica environment you can perform an upgrade and test your Production environment processes
with live instances.

Page 533 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
After ensuring that the production-replica environment processes and instances function as they should, upgrade
your real Production environment.

A Production-replica environment is a Bizagi project which has the production backup restored into it.
It is not the real Production environment because Production parameters and other relevant information have not
been modified to reflect the environment's location (for instance, the actual e-mail addresses of users, the SMTP
Server or other URLs involved in integration points in the production, etc).

Confirm that all environments use the same Bizagi version

If you have not yet deployed your project into a production environment, you may disregard this consideration.

If your project has been already published into a production environment, upgrading your project in the
development environment will eventually require that you also upgrade your project in the Test and Production
environments.
The upgrade procedure is done separately for each environment, but you will need to plan upgrading all of them
so that they use the same version:

If you do not do this, you will not be able to carry out deployments to publish your processes.

Plan the development environment's upgrade and coordinate them with your team
A version upgrade should be carried out with advance notice and coordination, so you upgrade the Bizagi servers,
when team members are not working on the project.

Upgrade the Test and Production environments during non-working hours

A version upgrade will stop services (for approximately three minutes).

Page 534 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Do not upgrade your version if you have a pending Release Candidate to deploy into production
Before the upgrade, either apply the Release Candidate or cancel it.
If you have doubts on this steps, contact our support team.

Procedure
Here is the upgrade procedure for each environments.

1. Development environment upgrade (Bizagi Studio)

To upgrade your project to the newest release, first upgrade your Bizagi Studio installation.
If the project is configured for multiple users (in a teamwork collaboration setup), perform the Bizagi Studio and
project upgrade in the central development Bizagi Server where the project is hosted.

If your project was created using Windows Authentication, take into account that your user must have the same
permissions explained in Creating a project using Windows Authentication.

1.1. Uninstall Bizagi Studio, using your computer's control panel option:

At this point your server may ask for a reboot.

1.2. Download and install the newest version of Bizagi Studio.

Page 535 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
After the upgrade completes reboot the server.

1.3. Upgrade your development environment project:

· Open Bizagi Studio and open the project.

Select it from the list of projects displayed in the window:

Page 536 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
If the project is not listed, select the All Projects option:

Page 537 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Confirm by clicking Yes when prompted about the project's upgrade:

Coordinate with team members and alert them in advance that you will be upgrading the project.
In this way you also make sure that no other team member is currently working on the project or has Bizagi Studio
opened.

· When the upgrade is finished your project opens in Bizagi Studio.

At this point your project has been upgraded to the new version.

Page 538 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Have all team members upgrade their Bizagi Studio installation.

At this point, you may proceed to run tests on the processes you have implemented in the development
environment.

· Keep in mind that after upgrading the Bizagi Studio version, you should always reboot the host server.
· If you haven't checked your project's metadata with our support team already, perform a backup of your
project. Then create a ticket in our Support website and send your backup. This is so the Support Team can
check your project's metadata thoroughly to help you with a smooth migration on your other environments.

2. Test environment upgrade

Once you have verified that your processes behave as expected in the development environment, you can upgrade
your other environments (first test, then the production replica environment if you use it, and finally, production).

Upgrade each environment following a similar procedure you used to update the Development environment, and
with the same recommendations.
The overall procedure would be:
· Make backups and plan and coordinate the upgrade.
· Install the Automation Server release that matches the version of Bizagi Studio used by your development
environment.

To install a newer release, first uninstall the current version, as described at Uninstall. Then install the newer version.
After uninstalling or installing, you may need to reboot your server.

Page 539 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Once the newer version has been installed, upgrade the project using the Management Console.
In the Management Console you are presented with a similar procedure to what you used to upgrade the project
with Bizagi Studio.

Page 540 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Verify that your processes behave as expected.

3. Production environment upgrade

Complete this step only after confirming that user-acceptance tests had satisfactory results in your test environment.
This procedure is the same as performed for the test environment.
The same procedure also applies for a production-replica if you decide to set up such an environment.

Once again, upgrading this environment involves:

· Make backups and plan and coordinate the upgrade.
· Install the Automation Server release that matches the Bizagi Studio version used by your Development
environment (by uninstalling the current version and then installing the newer one. and performing any required
reboot).
· Upgrade the project in the environment, using the Management Console.

Uninstall

Overview
You can uninstall Automation Server from your server by simply running the uninstall procedure managed by the
OS.
This is nessesary when upgrading the version of your Automation Server (to uninstall the old version before
installing the newer one).

Procedure
In Windows open Programs and Features, click Control Panel, click Programs, and then select Uninstall a program.

Page 541 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
In Windows 8 and Windows 10 you can type Control in the Search bar, select Control Panel, and then select
Programs and features.

Page 542 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Select Automation Server, click Uninstall.

Administrator permissions may be require.d If you're prompted for an administrator password or confirmation,
type the password or provide confirmation.

Page 543 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Continuous improvement and incremental deployments

Overview
As part of continuous process improvement, Bizagi allows the evolution of your processes as your business
evolves.
Sometimes this involves making changes to business data, business rules, or interfaces, or even changing the flow
of the Process itself.

Depending on the necessary changes, we recommend that you generate new versions of processes when they have
been already deployed to Production.
This is a safe way to make changes without compromising the information of the current cases being executed in
the Production environment.

However, publishing minor modifications to existing processes is also possible, so that the current cases can take
advantage of those changes and adjustments.
This section describes when it is best to create new versions for existing processes, and how to handle minor
changes when required for an existing process.

Continuous improvement
Note that you always make changes in the Development environment to a process that is already in the Production
environment, and then move the changes to Production, once they are satisfactory by executing a deployment.

Changes you must do in the Development environment include: new workflow Tasks or transitions, form additions or
changes to existing forms, business rules changes, and new performers or integration definitions.

Page 544 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
You can carry out changes to management tasks and configurations directly in the Production Work Portal. Such
management tasks include: editing business policies, users administration tasks and authorization configuration, and
administration for the SMTP server or ECM systems.

We recommend that you always make use of the Test environment to deploy and test your updated processes
before deploying them to Production.
This way, you can check and adjust your processes so that they perform as you need them to.

Incremental deployments
For continuous improvement of your processes and for deployments to an existing Production environment, take
into account the following considerations in your Development environment:

1. Objects in Production must remain in Development

Once a process is deployed to the Production environment (or is currently marked as a Release Candidate in the
Test environment), do not delete any objects used by that process version in the Development environment.

This covers: entities, attributes and relationships, forms, business rules, performer assignments (assignment rules),
systems, and organization definitions.

Similarly, it is not possible to modify the Name property of objects already used in Production.
This behavior is restricted to guarantee the stability of the Production environment in a subsequent deployment.

Page 545 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. Synchronizing data from another environment
It is a common and recommended practice to create users and use cases in your authoring environment. If you have
done so, and the information you have used in the development environment is real data that you need to have in
your target environment, the easiest way to transfer that information without having to create it once again is to
perform a Data Synchronization. In such procedure, you can handpick which data elements to export into a .bdex
file which can then be imported into your target environment.

The data elements that can be considered are Parameter entities managed in production, and Users with their
associations.

3. Versioning processes
Once a process is deployed to the Production environment (or is currently marked as Release Candidate in the Test
environment), its current version is locked so that it is not possible to edit the workflow model for that specific
version.

The process' version cannot be edited using the process Wizard's step 1 (addition, edition or deletion of shapes or
transitions is not possible).

If you wish to make this type of major changes to a workflow model, create a new version of the process (and its
sub-processes).

Page 546 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
On the other hand, you may choose not to create a new version of the process if the required changes are minor:

· Adding a new attribute or entity.

· Adding or editing current business rules (Action Events, performers assignments, Web or REST services'
invocations).
· Creating a new query form or entity query.

A new version is not required if changes can be made through the process Wizard from steps 2 and later. Editing
possibilities for existing objects using process Wizard steps 2 and later are detailed in the next section.

Changes made in the current version (without creating a new one), would apply in the Production environment to
existing cases.
Thus it is important to carry out proper tests and proceed cautiously for both new cases and existing ones; to
avoid consistency errors for the deployed processes.

View further information about the guidelines and recommendations for a new version of a process.

4. Editing options for objects in Production

Once a process is deployed to the Production environment or is currently marked as Release Candidate in the Test
environment, Bizagi Studio (the Development environment) limits the editing possibilities for the objects used by that
process version.
This is restricted in order to guarantee the stability of the Production environment in a subsequent deployment.

This means that for a process version already deployed in a Production environment or marked as a Release
Candidate, the best practice is to create a new process version to address new requirements and adjustments
(oriented to continuous improvement), if the modifications required are "big changes".

Page 547 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
However, you can make minor changes to processes (and their objects) which are already in Production (and have
the existing cases take those changes). To edit objects which are already being used in Production, refer to the
possible options in the table below:

OBJECT OPTIONS

Entities and Attributes Entities and attributes (including relationships) are not
editable in their: name, type, or source.
Only their display name can be edited.

Forms Forms may not be edited (adding, modifying or

deleting fields, or those fields' expressions, validations
or actions is not possible).
However, forms may be cloned or versioned, and you
can define which form version is the current form for an
Activity.

Expressions (Boolean and scripting type) The code may be edited (along with the display name
or description property).
Proper cautions should be taken as you are dealing
with "live code".

Custom Functions The code and description property may be edited.

Widgets The code and description property may be edited.

Performer Definitions (Assignation Rules) All properties and definitions are editable for Work
allocation (assignment rules of Tasks may be changed).

Organization Definitions Only the display name of the elements defined for the
organization may be edited (e.g., display name for
existing Areas, Roles, Skills, User groups).

Holiday Schemas Only the description of the defined holiday schemas

may be edited.

Security settings Changes for Authentication and LDAP should be done

directly in the Production environment through the
Management Console.
Changes done in development regarding Authorization
settings will always be taken to the Production
environment, and overwrite the Production
environment's configuration.

Email messages New messages (using the multiple messages feature) in

an e-mail message configuration may be included.
Existing messages in the multiple messages feature
cannot be removed.
In a message, its subject, recipient ("To", "CC", and
"BCC"), and body content may be edited.
The conditions to send an e-mail may be edited but not
deleted.

Letters The contents may be edited.

Interface invocations Web services invocations may be reconfigured through

the interfaces wizard.
Minor changes in an existing interface (those which do
not require new mappings) can be done directly in the

Page 548 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 Production environment through the Management
Console.

Dimensions All properties exept the Name may be edited.

Component Library The registered assembly/jar file can be changed.

Custom Jobs Only new Job Steps and Schedules may be added to an
existing Custom Job.

For any other change which is not possible for an existing object in Production, creating a new process version and
using a new object will be necessary.

5. New business keys

When defining new business keys, make sure that the data in Production complies with the new restriction.
Otherwise, applying the business key in Production will throw an error during the deployment procedure (to protect
your Production environment and make sure its data integrity).
For example, if you have an entity called "Product", do not define that its column ProductName as a business key if
you see that in the Production environment there is more than one Product record which has the same
ProductName. If, for instance, the ProductName column has multiple instances of the value "Credit" its values are
not unique. The column cannot be used as a business key.
Click for more information about Predefining business keys.

6. Previous configurations must remain compatible

Do not alter any of the required configurations involved in your previous deployments.

This means that your database instance should not change its collation (applies to SQL Server) or the configured
character set (applies to Oracle).

If you need to move your Production server to a different server, do so by using the Server management options
presented by Bizagi in its Management Console.
Click for more information about Server management through the Management Console.

Guidelines for a new version of a process

Overview
Managing process versions gives you flexibility implement improvements that result from performance analysis of
your processes and the company’s continuous improvement process.

Developments and improvements proposed for the processes in Production must be evaluated before
implementing them to see whether they require the creation of a new version of the process to guarantee the
compatibility of the functions in Production, that is, open cases must end with the version of the process they were
created in.

When to create a new version

In-flight process instances will keep running in the version in which they were created. When a new version of a
process is taken to Production, new instances will be created in the new version.

The following table lists some common scenarios of required adjustments to processes in Production.

NEW VERSION REQUIRED NEW VERSION NOT REQUIRED

Any change in the process flow: include or delete

shapes in a process flow, change names of shapes,

Page 549 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 change task duration, automatic notifications, etc.

Include or delete attributes (or controls in forms) that Include or delete attributes with no relevant information
will be evaluated later in a business rule. in forms, or with information that will not be evaluated
in a business rule.

Change rules that will be evaluated at a certain point of Change rules that have no impact (will not produce
the process and can produce errors for in-flight cases. errors) on in-flight processes.

Changes to On Enter, On Exit, On Save actions or Changes to On Enter, On Exit, On Save actions that do
business rules that determine the routing of the not affect process logic.
process workflow.

Sub-process configuration

New path added to the process after Inclusive or

Exclusive Gateways.

Recommendations
Perform these steps before generating a new version of a process:

1. Evaluate if you need a new version of a process according to the guidelines above or whether you can edit in the
Production environment directly, as described at Continuous improvement and development after a deployment.

2. Bizagi lets you to clone a process to start a new process based on a the existing one.
If you need to improve the latest (newest) version of a process, create a newer version of the latest version.
Consider cloning a process to create a new one, that is based on common things with the original.

3. Make sure your process is not checked-out by any user before creating a new process version. For more
information, refer to Process in Expert View.

4. We recommend that you make backups of the database before creating a new process version.

Considerations
1. Bizagi duplicates components such as Forms, Policies, Expressions, Vocabulary, Templates and elements in every
process version/copy created.
2. Bizagi shares the same definition for Global Vocabulary, Expressions and Policies between different process
versions/copies. Thus, they will not be copied.
3. When you clone a process that has multiple versions, Bizagi only clones the latest version; previous versions will
be ignored.
4. During creation of a new version or during cloning of a process, end users cannot use the Work Portal because
all services will be stopped.

Creating a new version of a process

1. In the Expert View right-click on the version of the process you want to version.
Select New Version.

Page 550 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
2. A new window displays the structure of the application that contains the process. Select the exact version of the
process or processes that will be generated as a new version.

3. If you select the Include sub-processes, this lets you create new versions of the Sub-processes.

Page 551 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
The new process version will use the new Sub-processes and the new forms version to preserve the previous
versions intact.

4. Click New Version to start creating the new version of the process.
A warning message appears. Click OK

A window displays the status of the process.

As soon as the process is finished you see a confirmation message. You are now ready to work on your new version
through the Wizard view.

Only objects related to the process are copied: Phases, Activities, Transitions, Intermediate Event, Forms, Rules
etc. Shared objects like: Entities (Attributes), Entity Forms are not copied.

If the process fails, an error window displays a message about the problem. Correct the error and start again.

Keeping the wizard organized

Once you've created several versions of your processes, your process drop-down list in the Wizard view can get
very cluttered and hard to navigate.

Page 552 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
To avoid this Bizagi lets you hide all the inactive version of a process. Simply click the option Hide inactive process
versions.

This will change the color of the slider to green and eliminate all the inactive process versions of the Recent Process
list.

Page 553 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Running Bizagi with Docker for Test Environments
Overview
This section explains how to use Bizagi on Docker for testing purposes. The use of Docker is not intended as a
Production environment.

Docker allows you to test drive Bizagi and distribute it easily when needed, by running the Bizagi application on a
container. A container is a unit of software that packages all the libraries and elements of an application to runs it
quicker, easier and in a reliable way, regardless of the infrastructure you have in place. The usage of a container
ensures that the application works uniformly despite of your server.

When you run Bizagi using Docker, you only need to package the Web Application. After it has been packaged, you
can distribute it to other users, who will have the exact same installation.

The following diagram shows this architecture.

Page 554 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
Prerequisites
· To execute Bizagi in Docker, you need to have installed both Bizagi Studio and Docker. When installing Docker,
make sure you check the Use windows containers instead of Linux containers check-box.

· Having access to Internet.

· 11 GB free hard disk space for a complete installation and configuration.
· Docker must be up and running.
· A Bizagi project created. For more information about how to create a Bizagi project, refer to creating a new
project.
· Do not use localhost to refer to your machine. Instead, use its host name.

Page 555 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· Bizagi Scheduler and the Connector services are not included in the package, packaging Bizagi with Docker does
not support tasks related to the scheduler nor Connectors.

Restriction
A Docker container keeps the files while the container is running. Thus, the traces and uploads file are available
while the container is running.

Journeys
The following journeys are available when using Docker.

Installation and configuration of a Bizagi BPM project in Docker

Follow the next steps to install and configure a Bizagi Project using Docker.

1. Copy the WebApplication folder located in your project's folder. The project's folder is normally located at path
%SystemDrive%\Bizagi\Projects\[Your_Project].

2. Create a new folder called docker anywhere in your disk and paste the folder copied in the previous step.

Page 556 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
3. Download the Docker file from this link and save it in the same location where you pasted the WebApplication
folder.

Page 557 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
4. Open a new command prompt window with administrator privileges and run the following command:

docker image build docker

Page 558 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
 The first time you run this command, it may take many minutes/hours according to your Internet Connection.

5. Run the following command to list the images:

docker images

6. The first time you create an image, it does not have a tag defined. Add a tag to your image running the following
command:

docker image tag [IMAGE ID] [TAG]

Where:
· [IMAGE ID]: Id of your image, this ID is displayed in the third column after running the command explained in
step 5.
· [TAG]: The name you want to use a tag name. The tag must be lowercase.

Running Bizagi image in Docker

Use the following command to run your Bizagi image in Docker.

docker run -d -p [PORT]:80 [TAG]

Where:
· [PORT]: An available port number in your host.

Page 559 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
· [TAG]: The tag of your image.

You may need to allow Docker to access your firewall. Do not block it, otherwise, the procedure does not work.

Then, open a browser and enter the following URL: http://[HOST_NAME]:[PORT].

The port is the one you defined in the execution of the command to start the image.

Applying fixes to your Bizagi image in Docker

When you need to apply fixes due to bug fixing or improvements, you need to recreate the image with the new
changes performed in Bizagi Studio. It is strongly suggested to save a backup of the WebApplication folder in case
you need to roll back.
Perform the following steps.

Page 560 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi
1. Replace the new content of the WebApplication folder (%SystemDrive%\Bizagi\Projects\[Your_Project]) in the
docker folder previously created.

2. Recreate the image following the procedure to install and configure the image from step four.

When you set the tag name for the fix, make sure that the name used has not been assigned to another image in
Docker.

Page 561 | Bizagi User Guide - A Digital Business Platform Copyright © 2020 Bizagi