Deployment de los objetos

<< Click to Display Table of Contents >>

Navigation:  Bizagi Engine > Administración del Sistema Bizagi > Deployment de procesos y nuevas versiones > Consideraciones y requerimientos >

Deployment de los objetos

El Deployment de Bizagi publica los Procesos y metadata adicional del proyecto.

Al realizar un deployment or al haber realizado ya uno anterior, es importante considerar el tratamiento y características de este procedimiento.

 

1. Validaciones del motor de dependencias

Bizagi cuenta con un motor de dependencias el cual detecta las Entidades, formas, reglas de negocio, etc, que están siendo utilizadas por los Procesos involucrados en el Deployment.

De esta manera, Bizagi incluye la información y objetos relevantes de manera automática en el Deployment.

 

De manera similar, Bizagi identifica esas Entidades, formas, reglas de negocio, etc, en el ambiente de desarrollo que no están siendo utilizadas, sea por ningún objeto o no están siendo utilizadas por los Procesos seleccionados en el Deployment.

Estos que no se utilizan, no son incluidos por Bizagi en el Deployment.

Sin embargo, también es posible como una opción avanzada, forzar de manera manual que un objeto adicional se incluya en el Deployment.

 

note_pin

Los elementos que se definen de manera global (p.e, funciones scripting o expresiones a nivel de la Entidad de Aplicación) no pertenecen a los Procesos en sí, y por lo tanto, no son detectados para ser incluidos en el Deployment por el motor de Dependencias.

Para asegurarse de publicar estos elementos en el Deployment, junto con los Procesos que los utilizan, debe asegurarse de manualmente relacionar los elementos usando la opción de Relacionar objetos.

 

2. Funcionalidades a nivel de atributos que no se pueden cambiar

Existen ciertas funcionalidades del producto para atributos (o entidades), las cuales no se pueden activar una vez que dichos atributos (o entidades) hayan sido publicados ya en un ambiente de producción con la funcionalidad desactivada.

De manera similar, no se podrá desactivar esta funcionalidad para atributos (o entidades) que ya estén en el ambiente de producción con la funcionalidad activada.

 

Las funcionalidades a nivel de atributos que no permite cambios (desactivación o activación posterior) son:

La encripción a nivel de base de datos.

La Virtualización de datos o Replicación de datos.

 

Esto significa que si su atributo del ambiente de producción ya utiliza encripción a nivel de base de datos o está siendo replicado o virtualizado, no podrá cambiar esta definición para este mismo atributo.

En cambio y si requiere cambiar su funcionalidad, deberá dejar de utilizar ese atributo (y detener el esquema de replicación cuando se usa la replicación de datos), y crear una nueva verisón de proceso que utilice un nuevo atributo en su lugar.

 

 

 

3. Administración de Entidades de Parametrización

Cada Entidad de Parametrización tiene propiedades avanzadas, dentro de las cuales se define si la Entidad está diseñada para que sus valores se administren directamente en el ambiente de producción (o si por el contrario, sus valores se definen únicamente desde el ambiente de desarrollo).

 

Por lo tanto, se recomienda revisar detalladamente esta definición para las Entidades de Parametrización que se van a incluir en el Deployment.

 

Nótese que es necesario ser consciente de esta definición, ya que es exclusivo si la administración de sus valores (ingresar, modificar o deshabilitarlos) debe hacerse en desarrollo o en producción.

 

ParameterAdministration

 

Solamente para el primer Deployment, se presenta la opción de decidir si los valores de las Entidades de Parametrización se deben incluir, de manera que se lleven de desarrollo a producción sin importar la propiedad mencionada anteriormente.

En los Deployments posteriores, (cuando el ambiente de producción ya exista), sólo los valores de las Entidades de Parametrización que sean administrables en desarrollo serán actualizados en el ambiente de producción.

 

Para más información sobre esta propiedad, consulte Dónde administrar las Entidades de Parametrización.

 

note_pin

Para las entidades replicadas, sólo se realizará el Deployment del Esquema de Replicación. Los datos serán copiados de acuerdo a la configuración de la sincronización.

 

4. Configuración en producción

Tenga en cuenta que existen diferentes configuraciones asociadas a los distintos Experto de un proyecto Bizagi.

Para cada módulo, los diferentes valores se manejan por el Deployment con un tratamiento es especial.

 

Es posible definir los valores para el ambiente de pruebas siempre desde Bizagi Studio.

Esto implica que estos valores se actualizan en el ambiente de pruebas siempre al momento de hacer Deployment.

 

Para el ambiente de producción, se definen los valores inicialmente cuando todavía este ambiente no existe, (no se ha realizado Deployment a producción).

Para los Deployment posteriores, la administración de estos valores se realiza directamente sobre el ambiente específico (usando Bizagi Management Console).

 

Este concepto y tratamiento aplica para los siguientes Experto y configuraciones:

 

4.1 Opciones de entorno

En el ambiente de desarrollo, es posible definir los valores iniciales que debe tomar el ambiente de pruebas o producción en cuanto a la configuración de las Opciones de entorno.

Para el ambiente de producción, esto solamente es definible antes del primer Deployment.

 

Environment

 

Esto se debe a que una vez que esta configuración sea llevada a producción, la edición de estos valores debe hacerse directamente sobre el ambiente (usando Bizagi Management Console).

 

Para más información sobre esta configuración específicamente, consulte Configuración de entorno.

 

 

4.2 Propiedades de interfaces (Sistemas)

Cuando se define una interfaz para la invocación de un servicio Web o REST, se definen inicialmente los valores para dicha configuración (por ejemplo, la URL, el método, las credenciales autorizadas, etc).

 

Una vez que ya se haya hecho un Deployment a producción, esta configuración no es editable desde el ambiente de desarrollo (debe realizarse de manera separada a través del Management Console).

Para el ambiente de pruebas, los valores si se pueden redefinir nuevamente desde el ambiente de desarrollo (a través de Bizagi Studio) para que el Deployment los actualice.

 

 

Interfaces

 

En resumen, cambios en la configuración de invocación a servicios externos Web o REST, que ya está en producción, deben hacerse directamente sobre ese ambiente.

 

 

4.3 Propiedades de Proveedores de datos (Sistemas)

Cuando se crea un nuevo Proveedor de datos (para la Virtualización o Replicación), se definen sus parámetros iniciales (de conexión, como la cadena o el login con permisos) para los demás ambientes: pruebas y producción.

Una vez que ya se haya hecho un Deployment a producción, esta configuración no es editable desde el ambiente de desarrollo (debe realizarse de manera separada a través del Management Console).

Para el ambiente de pruebas, los valores si se pueden redefinir nuevamente desde el ambiente de desarrollo (a través de Bizagi Studio) para que el Deployment los actualice.

 

 

 

Providers

 

En resumen, cambios en la configuración de sistemas con Proveedores de datos, que ya está en producción, debe hacerse directamente sobre ese ambiente.

 

4.4 Propiedades ECM (Sistemas)

Al crear un nuevo repositorio, se definen las propiedades de la carpeta y del mismo, para cada ambiente.

Una vez que esta configuración ya ha sido llevada a producción, los valores de configuración para este repositorio no son editables desde el ambiente de desarrollo (deben hacerse directamente en el ambiente a través del Management Console).

Para el ambiente de pruebas, los valores si se pueden redefinir nuevamente desde el ambiente de desarrollo (a través de Bizagi Studio) para que el Deployment los actualice.

 

En resumen, cambios en la configuración de sistemas ECM que ya está en producción, debe hacerse directamente sobre ese ambiente.

El mismo concepto aplica para la definición de carpetas en la integración ECM.

 

 

4.5 Autenticación y configuración con LDAP

Las opciones presentadas en el módulo de Seguridad tienen un manejo especial.

La configuración de Autenticación, sincronización con LDAP y Autorización, se definen inicialmente en el ambiente de desarrollo (por ejemplo, el método de Autenticación usado en el Portal de Trabajo o si se importan usuarios desde un Servidor LDAP).

 

Una vez que ya se haya hecho un Deployment a producción, esta configuración no es editable desde el ambiente de desarrollo (debe realizarse de manera separada a través del Management Console).

Para el ambiente de pruebas, los valores si se pueden redefinir nuevamente desde el ambiente de desarrollo (a través de Bizagi Studio) para que el Deployment los actualice.

 

Security

 

En resumen, los cambios en la configuración de Autenticación, LDAP y Autorización que ya estén en producción, debe cambiarse directamente sobre ese ambiente.

Mientras que para el ambiente de pruebas, la configuración de Autenticación y Autorización siempre se sobreescribe desde Desarrollo.

 

 

4.6 Usuarios (WFUser)

Solamente para el primer Deployment al ambiente de producción, se presenta la opción de incluir los usuarios que se hayan creado en el ambiente de desarrollo (hacia producción).

 

Después del primer Deployment, la administración de usuarios en producción se realiza de manera separada (independientemente a través de las opciones del Portal de Trabajo).

 

Para los Deployments al ambiente de pruebas, siempre se presenta la opción de incluir los usuarios desde desarrollo.

 

 

4.7 Grupos de usuarios (Desde la definición de Organización)

La definición de los elementos de la Organización en un proyecto (tal como: áreas, posiciones, habilidades, roles, grupos de usuario, etc...), se realiza únicamente desde el ambiente de desarrollo.

 

Los grupos de usuario en particular, a pesar de que son definidos desde desarrollo, se pueden configurar directamente en el ambiente producción solo para incluir o excluir usuarios.

Esta edición no incluye la redefinición, eliminación, o creación de grupos de usuario.

 

5 Componentes de Experiencia

Cualquier componente definido que esté relacionado a la experiencia será llevado automáticamente a deployment, siempre y cuando estén siendo usados por algún proceso. Sin embargo, es altamente aconsejado que sean seleccionados manualmente todos los objetos que se requieren en el deployment.

 

Debido a que la Transformación Digital permite la interacción entre múltiples objetos no relacionados, al hacer deployment de dichos componentes no relacionados es necesario seleccionar explícitamente cada componente de la experiencia a ser considerado en el deployment. Puede usar la siguiente tabla para considerar cada componente relacionado con el diseño de experiencia:

 

Objeto

Variación

Componentes relacionados

Colecciones (Mis Cosas)

Colecciones Indirectas

Todas las entidades relacionadas. Éstas son automáticamente consideradas en el deployment.

Todo contexto relacionado.

Colecciones Directas

La entidad relacionada.

Los procesos relacionados si el botón Agregar está configurado.

Los Stakeholders y sus contextos relacionados, si el botón Agregar está configurado.

El proceso iniciado cuando el botón Agregar está configurado (en caso que inicie un proceso).

Toda entidad usada en la expresión de visibilidad. (Si es usada en la configuración del botón Agregar).

Acciones

Proceso

Todo proceso relacionado.

Todo contexto relacionado.

Toda entidad usada en la visibilidad de la expresión. (Si se usa).

La entidad donde la acción está definida.

El proceso donde la acción puede ser iniciada.

Forma

La entidad donde la acción es definida, ésto también incluirá la forma a iniciar.

Cada contexto relacionado.

Toda entidad usada en la expresión de visibilidad. (Si se usa)

Los procesos donde la acción puede ser iniciada.

Expresión

La expresión a iniciar.

La entidad donde la acción es definida.

Cada contexto relacionado.

Cada entidad usada en la expresión de visibilidad (Si es usada).

El proceso donde la acción puede ser iniciada.

Contextos

Cualquiera, a excepción de "Siempre disponible"

El Stakeholder relacionado, si no está siendo relacionado mediante sus atributos a un proceso.

Búsquedas


El Stakeholder relacionado, si no está siendo relacionado mediante sus atributos a un proceso.

La entidad en la cual buscar (Ésto incluirá la forma de la búsqueda).

Los contextos relacionados..

Relevante para mí


El Stakeholder relacionado, si no está siendo relacionado mediante sus atributos a un proceso.

El proceso relacionado.

El contexto relacionado.

Disparadores

Proceso

La entidad donde el disparador fue definido.

Toda entidad necesaria para que la expresión de la condición funcione apropiadamente.

El proceso a ser iniciado.

Expresión

La entidad donde el disparador ha sido definido.

Toda entidad necesaria para que la expresión de condición y la expresión iniciada funcionen apropiadamente.

Constructores

Proceso

La entidad donde el constructor ha sido definido.

El proceso relacionado.

Todo contexto relacionado

Toda entidad usada en la expresión de visibilidad (Si es usada).

Forma

La entidad donde el constructor ha sido definido.

La expresión relacionada.

Todo contexto relacionado.

Toda entidad usada en la expresión de visibilidad (Si es usada).

 

note_pin

Por favor, tenga en cuenta que el uso de las expresiones getValueAsCollection y getXPath en una expresión no aseguran que el atributo sea tomado en cuenta al hacer deployment. Es, por lo tanto, necesario agregar la siguiente línea en su expresión en caso que algún atributo de una entidad no esté siendo considerado en su deployment.

 

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