Deployment de los objetos

<< Clic para mostrar Tabla de Contenidos >>

Navegación:  Automatización de Procesos con poco código > Studio Cloud -ambiente de autoría > Deployment > Requerimientos y consideraciones previas a un Deployment >

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.

No borre elementos que ya hayan sido incluidos en un Deployment, esto puede causar efectos no deseados en tiempo de ejecución.

 

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

 

Para cada implementación, solo los valores de las entidades de parámetros que se administran en el entorno de desarrollo se actualizan y se incorporan al entorno de producción. Si desea implementar valores de entidades administradas en el entorno de producción, debe sincronizar los datos.

 

note_pin

Puede cambiar dónde administra una entidad en cualquier momento y desplegarla. Sin embargo, revise cuidadosamente las consideraciones mencionadas aquí.

 

 

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.

Tan pronto como el proyecto ha sido deployed, los usuarios podrán agregar registros en las entidades paramétrica a través del Portal de Trabajo solamente si la entidad es administrable en producción. De lo contrario, los valores deberán ser agregados utilizando Bizagi Studio y luego realizar deployment a producción.

Cuando una entidad Paramétrica contiene imágenes o archivos, estos no se llevarán en el deployment. Es necesario que sean incluidos manualmente en el ambiente de desarrollo. Si necesita ayuda contacte a Soporte de Bizagi

 

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).

 

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).

 

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 sobrescribe desde Desarrollo.

 

4.6 Usuarios (WFUser)

El primer deployment a producción no incluye los usuarios. El usuario Administrador permanece como el único usuario. Para más información acerca del usuario Admon haga clic acá.

 

AdmonUser_1

 

Los nuevos usuarios deben ser incluidos manualmente, por sincronización, o importandolos desde el ambiente de desarrollo o test.

 

note_pin

Cuando realice su primer deployment a cualquier ambiente, el usuario admon podrá iniciar sesión sin ingresar credenciales hasta que se carguen otros usuarios al ambiente destino del deployment.

 

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.

 

Personas

Una Persona se incluye en un paquete de deployment siempre que cualquiera de sus atributos se use en un elemento del proceso, por ejemplo, un formulario o una regla. Por otro lado, si no se usa en un proceso, y la entidad Persona no se selecciona manualmente como parte del paquete seleccionando un objeto, y no tiene dependencias con ningún proceso implementado, la Persona no se incluye en el deployment. En resumen, una Persona se incluye en deployment cuando:

 

Un atributo de la entidad Persona se utiliza en un proceso que se despliega.

Cuando se selecciona manualmente en las opciones de deployment.

 

Cada Persona se despliega de forma independiente, siempre que cumpla alguna de las condiciones mencionadas anteriormente.

 

note_pin

Los usuarios se asocian con las Personas cuando se hace un deployment. Incluso si el usuario ya existe en el ambiente de destino.

 

Objetos

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.

Las Personas 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"

La Persona relacionado, si no está siendo relacionado mediante sus atributos a un proceso.

Búsquedas


La Persona 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í


La Persona 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.usingXPath("Entity Name","XPath");


Last Updated 2/27/2023 11:23:26 AM