Advanced Deployment example

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Deployment  > Advanced Deployment > How to apply a deployment package > Apply the package using executable >

Advanced Deployment example


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

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 two 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 or open it using the Export option in Bizagi Studio.

A window appears with the following options:




Option- number in the image above



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

This should refer to your Development environment.


Lists the applications in our project.


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 version, the option to manually include dependencies appears.


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


Allows to configure the exportation options.


Creates the export file (.bex).


set a password for the file (optional).


Allows you to load a template with the deployment settings previously saved so all the elements selected are marked in the current deployment.


Allows you to save a template with the current deployment settings to a JSON file to make sure that all items selected in the current deployment will be selected in subsequent deployments.

This option is a good practice for large projects so you don't have to remember what was selected for deployments to other environments.


There are some additional tasks which can be run after having generated the export file.

These are also present in the Import utilities.


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.




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.






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




Search: Cases




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.




oThe search form is automatically deployed along with the searched entity.

oThe stakeholder from which the search is available is automatically considered when the search is selected.

oThe context related had been selected previously.




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:


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




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




oThe processes where the action can be launched from.




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. If you selected the add password option AddPassword, a window will appear asking for the password to be assigned to the package, it must comply with the mentioned conditions. When a package with a password is generated, it is encrypted.




Finally, 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:


1. Run CreateImport.exe.

Its window will show the following options:




Option- number in the image above



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

This should refer to your target environment Test or Production.


Presents the option to load the .bex file.


Presents the information about how the export was configured.


Applies the imported .bex file.


2. Load the .bex export file (created in the previous step) by using the Browse button. If the .bex file was generated with a password, a window will appear requesting it.




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.

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.