Deployed Objects

<< Click to Display Table of Contents >>

Navigation:  Bizagi Engine > Bizagi system administration > Deployment of processes and new versions > Previous considerations and requirements >

Deployed Objects

The Deployment in Bizagi publishes Processes versions and other metadata for the project.

When deploying or having done previous deployments, it is critical to consider the following aspects:

 

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 will identify 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 if any other additional objects should be included as well, when deploying Processes.

 

note_pin

Elements which are defined as a global elements (e.g, scripting functions or business rules at the Application level) do not belong to a specific Process and therefore these are not automatically detected by the Dependency engine.

To ensure you deploy such elements along with Processes that use them, you would need to manually relate them by using the Relate objects option.

 

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) were already published in a production environment with that feature deactivated.

Similarly, you may not deactivate such features if these attributes (or entities) were published in a production environment with that feature activated.

 

Attribute features whose activation/deactivation cannot be changed after being deployed 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 same attribute to stop using that feature.

Instead and if you do need to change its definition, you will need to stop using that attribute (and disable the replication scheme when using replication), to 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 if that particular entity is designed to be managed either in the Production environment or the Development environment.

 

Therefore, it is recommended to review in depth which parameter entity's values require deployed into Production.

 

Notice that a parameter entity cannot be managed in both Development and Production environment; it is necessary to select one environment to manage (insert, edit or disable) the entity values.

 

ParameterAdministration

 

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.

 

note_pin

For replicated entities, deployment will only copy the replication schema. Data will be copied into the entity according to your synchronization settings.

 

4. Production settings

Take into account that there are several modules in a Bizagi project.

For each module, there are different settings and their configuration may have different values for each of the different environments in a project (Development, Test, and Production).

 

The environment values presented in Bizagi Studio for the Test environments, have their values 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, the administration for these values has to be done directly in the target environment (by using Bizagi Management Console).

 

The previously described applies to the following modules and configurations:

 

4.1 Environment options

In the Development environment, you may initially set the values for the Environment options that will apply for the Test and Production environment.

For Production environment, this can be defined for the first deployment to that environment.

 

Environment

 

Once this configuration is applied to Production, those parameters and definitions will no longer be editable (through Bizagi Studio) in the Development environment.

Therefore, modifications for those values will need to be done separately for the environment (by using the Management Console).

 

Click for more information about Environment configuration.

 

4.2 Interfaces Properties (Systems)

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

 

Once that interface has been taken to the Production environment, the values for that environment 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 those values.

 

 

Interfaces

 

Summarizing, for Interfaces already deployed to Production, any edition to their property values needs to be done directly in that environment (by using the Management Console).

 

 

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 taken to the Production environment, the values for that environment 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 those values.

 

 

Providers

 

Summarizing, for Providers (used in Virtualization and Replication features) already deployed to Production, any edition to their property values needs to be done directly in that environment (by using the Management Console).

 

 

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 taken to the Production environment, the values for that environment 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 those values.

 

Summarizing, for ECM system-configuration which are already deployed to Production, any edition to their property values needs to be done directly in that environment (by using the Management Console).

This same concept applies to the folders definition in the ECM integration.

 

 

4.5 Authentication and LDAP settings

The options presented in the Security module for the Authentication options and LDAP synchronization in your Bizagi project, may be initially defined in the Development environment for the Production environment (that is, using LDAP or any other configuration related to the Work Portal's authentication method).

 

Once after your project has been deployed to Production, the settings for that Production environment should be edited by using the Management Console (these may no longer be edited directly in 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 those values.

 

Security

 

Summarizing, changes in the Authentication, LDAP and Authorization already defined in Production, needs to be done directly in that environment (by using the Management Console), while changes in Authentication and Authorization in the development environment are always deployed to Test environments.

 

 

 

4.6 Users (WFUser values)

For the first deployment to the Production environment, the users created in the Development environment (WFUSER system entity values) can be taken to that environment, as an optional possibility to populate Production users.

 

After the first deployment, users administration in Production is done separately through the Work Portal's users administration options.

For the Test environment, users can be always be taken from the Development environment within each new deployment.

 

 

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 done only in the Development environment.

 

Although this includes defining User groups as well, these in particular can be edited directly in the Production environment.

Editing User groups implies including or removing users for that particular User group (but it will not be possible to create new User groups or delete existing ones in the Production environment).

 

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 to be also deployed.

 

Any experience related objects defined will be taken for deployment automatically as long as they are being used by any process (i.e. Actions). Nonetheless, it is highly advisable to manually check all objects are to be deployed.

 

The next table lists experience objects and suggests the ones that should be individually selected additionally for the deployment to be complete.

 

Object

Variant

Related objects

Collections (Shown in My Stuff)

Indirect Collections

Every related context.

Direct Collections

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 available" context

The related Stakeholder

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.

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

 

note_pin

Please be aware that the use of the sentences getValueAsCollection and getXPath within an expression does not ensure 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.usingAttrib("Entity Name","Attribute Name");