Consideraciones importantes al compartir procesos

<< Clic para mostrar Tabla de Contenidos >>

Navegación:  Bizagi Studio > Interfaz de Bizagi Studio en detalle > Ajustes avanzados > Exportar / Importar > Compartir procesos entre proyectos >

Consideraciones importantes al compartir procesos

Consideraciones importantes

Le recomendamos siempre seleccionar la opción Enable metadata validation. Esta opción detecta dos de los errores más comunes en la importación:

oReferences to objects that don't exist in the catalog: este error se genera cuando un objeto de la importación hace referencia a un elemento que no existe en el paquete o en la base de datos objetivo.

oProcesses without an associated version: este error se genera cuando objetos como reglas y elementos de Experiencia no tienen una versión del proceso asociada. Si esto sucede revise la configuración de su deployment y asegúrese de seleccionar una versión del proceso para estos objetos.

Estas validaciones son muy importantes pues reducen los errores que se pueden presentar en el desarrollo del proceso.

 

SharingProcesses13

 

 

Exportar procesos es posible en los siguientes escenarios: Entre la misma versión de Studio, de una versión menor a una mayor. No es posible de una versión mayor a una menor.

 

Qué se exporta: todos los objetos de proceso utilizados en el paquete exportado:

oLas Aplicaciones del proceso elegido y todos sus componentes, como Formas, todas las entidades y sus componentes, reglas de negocio, vocabularios, Component library, plantillas de documentos (incluida la configuración y los documentos cargados), Assemblies, Proveedores, Sistemas externos, conectores, widgets y Columnas personalizadas.

oEl paquete también contendrá información relacionada con la Organización utilizada en los procesos elegidos: propiedades de usuario, grupos de usuarios, áreas, Roles, Skills, locations, posiciones, calendario de trabajo, esquema de vacaciones.

oCuando exporta una entidad paramétrica se incluirá sus atributos y valores.

 

Mantener la consistencia de los datos es una de las prioridades de Bizagi. Como parte de esto, los atributos eliminados de una entidad no serán eliminados de la entidad destino y los atributos nuevos en la entidad fuente serán creados en la entidad destino.

Si al importar un proceso se presenta incoherencia de datos, la acción se cancela. Los posibles escenarios que desencadenan este efecto son:

oLos objetos del Diseño de Experiencia que inician un proceso el cual no existe en el proyecto de destino o en el archivo .btex.

oAtributos faltantes en los formularios migrados desde versiones anteriores de Bizagi.

oUna entidad del proyecto destino con el mismo nombre que una entidad dentro del archivo .btex.

oReglas que hacen referencia a atributos no incluidos en el proyecto destino o en el paquete (archivo .btex).

Se pueden importar reglas y otros objetos globales con nombres replicados.

 

Qué no se exporta: objetos globales e información de configuración.

oEl paquete exportado no contiene información del caso (datos). Se exporta solo metadata.

o No contiene configuración de ambiente (incluidos parámetros personalizados, incluso si se utilizan en reglas de negocio), configuración de negocio, configuración de autenticación, configuración LDAP, OAuth2ServerApplication, Temas, Páginas web, Jobs personalizados, definición de seguridad de Studio, metadata de Sites, definición de Procesos en vivo ni personalizaciones de Notificaciones automáticas.

 

 

Escenarios de colisión que detienen la importación

Mantener la integridad de los datos es una de las principales prioridades de Bizagi.

Antes de continuar, es importante aclarar un término: GUID. Un GUID es un acrónimo que significa Identificador único global. Bizagi usa GUIDs internamente para cada objeto, de manera que puede identificarlos de manera única.

 

Puede haber casos en los que la importación de un proceso genere una colisión. Las colisiones son paquetes que no se pueden importar, como en los siguientes escenarios:

 

1. Un proceso importado presenta inconsistencia de datos. Los posibles escenarios que desencadenan este efecto incluyen, entre otros:

oObjetos de Experiencia que inician un proceso y falta el proceso en el proyecto de destino.

oAtributos faltantes en formas.

oReglas que hacen referencia a atributos no incluidos en el paquete o en el proyecto de destino (puede importar Reglas con nombres replicados).

 

2. Procesos con diferentes GUIDs y los mismos nombres

Por ejemplo: Proyecto 1 y Proyecto 2 se crean de forma independiente con un proceso con el mismo nombre, digamos Vacaciones. Al exportar un paquete del Proyecto 1, generará una colisión cuando se importe al Proyecto 2. Por lo tanto, no se importará.

 

3. Entidades con diferentes GUIDs y el mismo nombre.

Por ejemplo: Proyecto 1 y Proyecto 2 se crean de forma independiente con una entidad con el mismo nombre. Digamos que la entidad Cliente. Al exportar un paquete que incluye la entidad Cliente del Proyecto 1, generará una colisión cuando se importe al Proyecto 2.

 

4. Facts (relaciones) y atributos con diferentes GUIDs, con el mismo nombre y el mismo objeto principal.

Por ejemplo: tenemos un Proyecto Base y un Proyecto derivado de ese (puede ser una copia de seguridad por ejemplo). Ambos tendrán la entidad Cliente. En este caso, ambos proyectos tienen la entidad con el mismo GUID (identificador único) y el mismo nombre. Dos desarrolladores, uno en cada proyecto, crean un nuevo atributo con el mismo nombre en la entidad Cliente, digamos Dirección. Al exportar un paquete del Proyecto derivado y llevarlo al Proyecto Base, generará una colisión.

 

Cuando la metadata en el proyecto destino se mantienen sin cambios

Cuando hay entidades, relaciones y atributos con el mismo GUIDs, lo que está contenido en el paquete importado se ignora y lo que está en el proyecto de destino se mantiene.

 

Cuando hay una entidad Paramétrica administrada en desarrollo, que está presente tanto en el proyecto de origen como en el de destino, y en el proyecto de destino hay nuevos registros de dicha entidad, la importación de la entidad no eliminará estos nuevos valores. Esta es una nota importante ya que difiere del proceso de deployment normal.

 

Por ejemplo: Tenemos un proyecto Base y un proyecto derivado del mismo (puede ser una copia de seguridad por ejemplo). Digamos que se modificó la descripción de la entidad País en el Proyecto derivado y se exportó un paquete para ser importado en el Proyecto Base. Al importarlo, se mantendrá la descripción del proyecto de destino.

 

Cuando se reemplaza la metadata en el proyecto de destino

1. Al igual que con un deployment, los objetos existentes en el proyecto de destino se reemplazan con los objetos de paquete importados. Esto aplica a:

Reglas, reglas de librería

Bibliotecas de componentes

Conectores y widgets

Dispositivos predeterminados

Esquema de horario de trabajo y vacaciones

Formas, widgets y su localización

Propiedades de usuario

Autorizaciones

Sistemas externos

Objetos de Experiencia (Acción de entidad, Stakeholder, Acciones, Colección indirecta, Búsquedas, Relevantes, Contextos, Categorías)

 

2. Cuando se importa el mismo proceso más de una vez, su última importación creará una nueva versión del proceso.

 

SharingProcesses19

 

3. Objetos eliminados: si se elimina un objeto en el proyecto de origen, se eliminará en el proyecto de destino si el proceso de importación encuentra el mismo GUID.

 

4. Se agregan nuevas relaciones y atributos de una entidad existente en el destino.

 

5. Para roles, habilidades, ubicaciones y grupos de usuarios duplicados

Si el GUID es el mismo en ambos proyectos, los objetos serán reemplazados

Si el GUID es diferente, se agregan independientemente del nombre. Habrá dos objetos con el mismo nombre.