Important Considerations
•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 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.
oIt 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, Persona Admin, Graphic Query, Analysis Queries, BAM, Entity Admin), Custom Jobs, Studio security definition, Apps 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 acronym 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.
5. Rules with different GUID, with the same name and same parent
For example: We have a Base Project and Project derived from the base (it can be a backup for example). Both projects have a process called “Vacations”. The developer created a rule in the same Task of the process “Vacations” in both projects, “Rule 1”. When exporting a package from the derived Project and taking it to the Base project it will generate a collision.
6. Values for Entities LOCATION, AREA, POSITION, ORGANIZATION, ROLE, TIMEZONE, LANGUAGE, USER START PAGE with different GUID and the same name (or display name).
Example: We have a Base Project and project derived from the base (it can be a backup for example). The user created an AREA called “Myarea” in both projects. When exporting a package from the derived Project and taking it to the Base project it will generate a collision.
7. Entity Action with different GUID, same name and same parent for Collections:
Example: We have a Base Project and project derived from the base (it can be a backup for example). The user created an Entity Action with the same name in the same Collection. 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, relationships, attributes, or elements of the organization 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
•Component libraries
•Connectors y widgets
•Default devices
•Working time schema and holidays
•Forms, Widgets and their localization
•User properties
•Authorizations
•External systems
•Localizations
•Experience objects (Entity action, Persona, 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. The following image explain a scenario of sharing the same process.
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).
Last Updated 2/13/2024 10:26:54 PM