During process automation, you may find yourself in a situation where you need to share your processes with other Studio users. Bizagi helps you share your processes along with their business rules, parametric values, forms and other settings, with the options available in the Import/Export menu, in your development environment.
What you need to do
To share your processes, you need to follow these steps.
Once your process are ready to share, head to the Export/Import menu and select the Share Processes option.
A window appears where you can select the processes and their versions you want to share.
In the Experience tab, you can select the experience components you want to include in the the .btex file.
To add an optional description, click Description and type in a brief description for the shared package.
Select the processes you want to share.
Then, if the selected processes have experience components, select them in the Experience tab to include them in the file.
Once finished, click Export to generate the .btex file. If you selected the add password option , 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.
Select a name and location for the generated file.
When the export finishes, a window appears showing that the procedure was successful.
You can check the contents of the exported package by clicking View Package. Another window appears where you can navigate the contents.
To finish, close all the windows.
You can now share your processes through the .btex file you've just created.
When you receive the shared package file, head to the Export/Import menu and select the Processes option under the Import category.
A window appears with the import wizard. Click the Browse button to navigate to the shared .btex file.
Select the package you want to import and click Open.
If the .btex file was generated with a password, a window will appear requesting it.
With this, all the process information is displayed on the window.
You can view the objects you are importing by clicking View process object to import. A window appears with all the objects inside the file.
Additionally, you can view the package description when you click View description. A window appears with the package's description.
After you've checked the package's information, click Apply package to import it. Once Bizagi is done importing, a message appears informing so.
To finish, close all windows.
After this, the shared processes are part of your project.
•We strongly recommend that you select the Enable metadata validations option when you import a shared process. This validation detects two of the most common errors that occur during an import:
oReferences to objects that don't exist in the catalog: When an imported object has a reference to an object that doesn't exist in the package or in the target database this validation is triggered.
oProcesses without an associated version: When objects like rules or experience elements don't have an associated process version, this validation error is triggered. If this happens, you must review your export configuration and make sure you selected an associated version for these objects.
These validations are important because they reduce errors substantially.
•You can export processes in the following scenarios: within the same Bizagi Studio version or from a lower to a higher version. It is not possible to export processes from a higher to a lower version.
•What is exported: all process objects used in the exported package:
oThe Applications of the process chosen and all of its components such as forms, all entities and its components, business rules, vocabularies, component Library, Document Templates (including configuration & uploaded documents), Assemblies, Providers, External Systems, Connectors, Widgets and Custom columns.
oThe package will also contain Organization related information used in the processes chosen: user properties, user groups, Areas, Roles, Skills, Locations, Positions, Work Calendar, Holidays schema
oWhen you export a parameter entity, it will include its attributes and values.
•What is not exported: global objects and configuration information.
oThe package exported does not contain case information (data). It shares metadata.
o it does not contain Environment configuration (including Custom parameters, even if they are used in business rules), Business configuration, Authentication configuration, LDAP configuration, OAuth2 Server Application, Themes, Web Pages (Cases Monitor, Search, Process Admin, Licenses, Stakeholder Admin, Graphic Query, Analysis Queries, BAM, Entity Admin), Custom Jobs, Studio security definition, Sites Metadata, Live processes definition nor Automatic notifications customizations.
Collision scenarios that stop the import
Keeping data consistency is one of Bizagi's main priorities.
Before we proceed it is important to clarify a term: GUID. A GUID is an acronyom that stands for Globally Unique Identifier. Bizagi uses GUIDs internally for every single object, to identify them uniquely from the rest.
There might be cases when importing a process generates a collision. Collisions are packages that cannot be imported for one of the following scenarios:
1. An imported process presents data inconsistency. Possible scenarios that trigger this effect, include, but are not limited to:
oExperience objects that start a process that is missing in the target project.
oMissing attributes in forms.
oRules referencing attributes not included in the package or target project (you can import Rules with replicated names).
2. Processes with different GUIDs and the same names
For example: Project 1 and Project 2 are created independently with a process with the same name. Let's say Vacations. When exporting a package from Project 1 it will generate collision when imported into Project 2. Thus, it will not be imported.
3. Entities with different GUIDs and the same name.
For example: Project 1 and Project 2 are created independently with an entity with the same name. Let’s say the entity is called Customer. When exporting a package that includes the entity Customer from Project 1, it will generate collision when imported into Project 2.
4. Facts (relationships) and attributes with different GUIDs, with the same name and the same parent object.
For example: We have a Base project and Project derived from it (it can be a backup for example). They will both have the entity Customer. In this case both projects have the entity with the same GUID (unique identifier), and the same name. Two developers, one in each project create a new attribute with the same name on the Customer entity, let’s say Address. When exporting a package from the derived Project and taking it to the Base project it will generate a collision.
When metadata in the target project is kept unchanged
When there are entities, facts and attributes with the same GUID, what is contained in the package imported is ignored and what is in the target project is kept.
When there is a Parameter entity that is managed in development, that is present in both source and target project, and in the target project there are new records of such entity, importing the entity will not remove these new values. This is an important note as is differs from the regular deployment process.
For example: We have a Base project and a project derived it (it can be a backup for example). Let us say that the description of the Country entity was modified in the derived Project and a package was exported to be imported in the Base project. When importing it, the description of the target project will be maintained.
When the metadata in the target project is replaced
1. As with a deployment, existing objects in the target project are replaced with the imported package objects. This applies for:
•Rules, Library rules
•Connectors y widgets
•Working time schema and holidays
•Forms, Widgets and their localization
•Experience objects (Entity action, Stakeholder, Trigger, Indirect collection, Searches, Relevant, Default filter, Entity constructor, Context, Categories)
2. When you import the same process more than once, your latest import will create a new process version.
3. Deleted objects: if an object is deleted in the source project, it will be deleted in the target project if the import process finds the same GUID.
4. New facts and attributes of an existing entity in the destination are added.
5. For duplicate Roles, Skills, Locations, Positions, and User Groups
•If the GUID is the same in both projects, the objects will be replaced
•If the GUID is different, they are added regardless of the name. There will be two objects with the same name (but they will have different GUIDs)