Preconditions and requirements
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.
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.
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.
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 user information 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:
•If your Production environment runs a higher version of Bizagi than your Development environment you can still deploy your process. For example, you can upload an element created in Bizagi 11.0 to your Production environment in 11.1.1 but you can't upload an element created in Bizagi 11.1.2.
•If your Production environment is in 11.2 or higher you must update the development version to 11.2 since from this version onwards you can only import 11.2 elements.
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:
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:
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.
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.