Exporting processes

<< Click to Display Table of Contents >>

Navigation:  From Studio to Cloud >

Exporting processes

Overview

The following section is step number 3 to accomplish a process deployment, as described at From Studio to Cloud.

By using the Export Process option available in the assisted process wizard, Bizagi will extract implementation details of automated processes to create a file that can be installed into Bizagi Cloud environments (i.e testing or production).

 

Required profile

It is recommended that the person in charge of this step is the project leader, so that this person meets the following profile:

1. Has know-how and understands the concepts involved in a process deployment with Bizagi (i.e, which objects are taken from development, is familiar with the steps associated to performing deployments).

2. Has an understanding of the business implementation: This means knowing about the processes and its purpose, data model, versions, integration points, security  and authentication settings, other environment settings (e.g, policies, alarms, parameter entity values), and general workings. 1

3. Has planned, coordinated and scheduled the deployment, and communicated this to other team members in the project.

 

Recall that this person does NOT need to be technically skilled in the sense that no programming is needed, and no IT-related tasks are involved in process deployments given that all steps are done via a self-service UI oriented to the business.

At this point, such person only needs access to the development environment (via Bizagi Studio).

 

Deployment package

Exporting processes is a step that is all about end up creating a file known as a deployment package.

To create such package, go to the seventh step of Bizagi Studio's Process Wizard, and select the Export .bex file option.

 

export_1

 

You are presented with a window having all options needed to customize the content of the package, as described below.

 

ExportUI

 

What you need to do

In a summary, creating a deployment package is done by:

1.Selecting those processes (their versions) you want to deploy.

2.Optionally, binding additional objects so that these are also included within the package.

3.Optionally, including components from the Experience design.

4.Optionally, relying on advanced options to deploy preset environment values or not.

5.Generating the deployment package.

 

Procedure

The images used from this point on illustrate the creation of a deployment package though an example having information from 1 process only.

 

1. Selecting those processes (their versions) you want to deploy.

Tick the check boxes of all process' versions you want to include.

Notice you will find processes sorted out as per the applications these belong to (according to your defined processes' architecture and hierarchy).

The example below simply considers the Ticket Reassignation process in its 1.0 version:

 

Export1_check

 

 

Notice this is intended for you to leave out those processes which are still under development.

 

2. Optionally, binding additional objects so that these are also included within the package.

Note that this step is strictly optional, in case you want to force that the package includes certain objects such as specific entities, query forms or business rules.

Before moving on, it is important to clarify that when creating a package, Bizagi already engages its dependencies engine so it validates that all objects (such as entities, forms or rules) being used by selected processes, get to be already included within that package.

Similarly, Bizagi will identify which objects in the development environment are NOT being used by the selected processes so that these aren't included in the package.

 

This means that you should only need to do this step, in those scenarios where you want to bind certain objects, which may not be necessarily used by the processes themselves, but you want to mark them as dependent to the processes so that these get carried along when creating the package (as a one-time only treatment).

 

 

In order to include additional objects, right-click that same process' versions and click on Define process dependencies.

 

Export1_patchA

 

Using this option is basically browsing from 3 available object categories: Entities, Query forms or Business rules. And ticking the check boxes of specific objects in those categories that you want to include in the deployment:

 

RelateObjects_QueryForms

 

Note that regarding Business rules, all library rules get to be automatically included in the package.

Click Ok when done.

 

note_pin

Keep into account that using functions such as getValueAsCollection and getXPath within a business rule, will not guarantee that the attributes involved in those functions get automatically included in the package.

Therefore, you may need to force the deployment to take an entity and its attributes, or possibly rely on explicitly including the following function so that your business rule becomes aware that such given attribute is dependent on that business rule:

 

CHelper.usingAttrib("Entity Name","Attribute Name"); 

 

3. Optionally, including components from the Experience design.

Note that this step is strictly optional, in case you are using the Experience design features oriented to Stakeholders in Bizagi.

If so, you may click Experience components to make sure that such components are also forced into the package:

 

Export1_Expdesign

 

Note that this option is there because Experience design components are decoupled from processes per sé, and can be deployed separately without being necessarily bound to a specific process.

To explicitly include such components, ensure you tick the check boxes of those you want to deploy:

 

advanced_components

 

 

The table below lists all available components and indicates those which should be selected.

 

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

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

 

Click Ok when done.

 

4. Optionally, relying on advanced options to deploy preset environment values or not.

Note that this step is strictly optional, in case that you want to modify the default treatment of certain records that Bizagi includes in the package.

This treatment is specially applicable for the very first deployment.

Recall that once an environment (i.e testing or production) has deployed processes in it, it will no longer be a first deployment but an incremental deployment.

 

Click Advanced to make sure that you can review what records go into the package:

 

Export1_advanced

 

When presented with these different options, ensure you leave ticked those check boxes of records you want to include in the deployment (and leave unmarked those that you don't want to deploy):

 

AdvancedOptions

 

The table below lists the options while providing a guide on when to include them.

 

OPTION

WHEN TO USE IT?

Include environment parameter values

Values given per environments. We recommend making sure that all parameter values (such as the SMTP server, interfaces URL, etc.) correspond to their environment configuration.

Include user jobs

If your project uses custom jobs, make sure this option is chosen.

Include organization

Choose organization's items to be included in the package..

Include authentication options.

This option includes the authentication definition for this project. These options can also be managed through the Environment Console per Environment.

Include records of parameter entities managed in production

Include parameter entities's values managed in production the first time a package is created to deploy the values entered in the Development Environment.

 

Click Ok when done.

 

5. Generating the deployment package.

Once done with all previous steps, click on Export to generate the deployment package:

 

Export1_export

 

The deployment package has a .bex file extension.

Such package will be saved into a local path (you will be prompted for its package name and location):

 

BexLocation

 

 

When done, you will be notified:

 

BexSuccess

 

At this point you may close the Window or you may choose to review the full list of objects and records that were exported into the package by relying on the Tasks after export options (in case you want to generate a new one with changes):

 

AfterExport

 

What should I do next?

Once you have the .bex package, proceed to deploy it to your chosen cloud environment.

For information about the next step, refer to Importing processes.