<< Click to Display Table of Contents >> Navigation:  Low-code Process Automation > Studio Cloud - Authoring environment > Deployment  > Previous considerations and requirements > 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.

 

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.

 

 

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 environments. Select one environment to manage (insert, edit or disable) the entity values.

 

 

For every deployment, only the values of parameter entities which are managed in the Development environment are updated and taken into the Production environment. If you want to deploy values of entities managed in the production environment you have to synchronize data.

 

 

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

 

 

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

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.

 

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.

 

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 existing values.

 

 

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

 

 

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.

 

 

New users must be added manually, by synchronization, or importing them from the development or test 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.

 

Personas

A Persona 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 Persona entity is not selected manually as part of the package by selecting an object, and has no dependencies with any deployed process, the Persona is not deployed. To sum up a Persona is deployed when:

 

•An attribute of the Persona entity is used in a process being deployed.

•When is selected manually in the deployment options.

 

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

 

 

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.

 

 

Last Updated 2/27/2023 11:15:36 AM