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.
•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 Asistente de Personas 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 Apps, 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.
5. Reglas con GUID diferente, con el mismo nombre y el mismo padre.
Por ejemplo: Tenemos un Proyecto Base y un Proyecto derivado (puede ser copia de seguridad por ejemplo). Ambos proyectos tienen un proceso llamado “Vacaciones”. El desarrollador creó una regla en la misma Tarea del proceso “Vacaciones” en ambos proyectos, “Regla 1”. Al exportar un paquete del Proyecto derivado y llevarlo al Proyecto Base, se generará una colisión.
6. Valores de las entidades UBICACIÓN, ÁREA, POSICIÓN, ORGANIZACIÓN, ROL, ZONA HORARIA, IDIOMA, PÁGINA DE INICIO DEL USUARIO con diferente GUID y el mismo nombre (o nombre para mostrar).
Ejemplo: Tenemos un Proyecto Base y un proyecto derivado de la base (puede ser copia de seguridad por ejemplo). El usuario creó un AREA llamada "Myarea" en ambos proyectos. Al exportar un paquete del Proyecto derivado y llevarlo al Proyecto Base generará una colisión.
7. Acción de entidad con diferente GUID, mismo nombre y mismo padre en Colecciones:
Ejemplo: Tenemos un Proyecto Base y un proyecto derivado de la base (puede ser copia de seguridad por ejemplo). El usuario creó una acción de entidad con el mismo nombre en la misma colección en ambos proyectos. 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, atributos o elementos de la organización 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, Persona, 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.
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.
Last Updated 2/13/2024 10:29:32 PM