Deployed Objects

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Automation Server configuration and administration guide > Initial project configuration > Deployment of processes and new versions > 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.

 

note_pin

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.

 

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.

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

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.

 

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.

 

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.

 

Interfaces

 

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.

 

Providers

 

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.

 

Security

 

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 can include users created in the Development environment (WFUSER system entity values)m if you want to us them to quickly create Production users.

 

After the first deployment, perform user administration in the Production environment by using its Work Portal's user administration options.

For the Test environment, users can be always be deployed from the Development environment as part of 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 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.

 

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.

 

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 in My Stuff)

Indirect Collection

Every related context.

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 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");