Introducción
Como parte de la mejora continua en los Procesos, Bizagi ofrece la posibilidad de realizar ajustes sobre los Procesos que les permitan su evolución a medida que el mismo negocio evoluciona.
A menudo, estos ajustes involucran cambios a los datos y reglas del negocio, las interfaces predefinidas o incluso el mismo flujo del Proceso.
Dependiendo de los cambios requeridos, se recomienda generar una nueva versión del Proceso que ya se encuentra ejecutándose en producción.
Esto obedece a una manera segura de implementar cambios sin comprometer la información de los casos existentes (instancias de Proceso) en el ambiente de producción.
Por otro lado, en escenarios donde se requieren solamente cambios menores a los Procesos existentes, también es posible optar por que los casos existentes tomen ese ajuste en producción.
Esta sección ilustra a manera de guía, cuándo deben crearse nuevas versiones de Proceso y cuándo se pueden manejar los cambios menores dentro de las versiones de Proceso ya existentes.
Mejora continua
Antes que nada, recuerde que cualquier cambio estructural que se desee hacer a un Proceso en producción, debe hacerse en el ambiente de desarrollo y actualizarse por medio del Deployment.
Tipos de cambios estructurales son: nuevas transiciones y Actividades en el flujo, nuevas formas o cambios en ellas, ajustes en las reglas de negocio, nuevas asignaciones a participantes o definiciones de integración, entre otras.
Tales cambios estructurales no incluyen las tareas administrativas, las cuales si se pueden llevar a cabo directamente sobre el Portal de Trabajo en producción. Tales tareas son por ejemplo: editar políticas del negocio, la administración de usuarios y sus configuraciones de autorización, o la administración de la configuración del Servidor SMTP o de sistemas externos como ECMs, entre otras.
Tenga en cuenta que de igual manera se debe seguir el ciclo recomendado del Deployment, donde se utiliza primero el ambiente de pruebas para verificar que los Procesos se comportan adecuadamente y están listos para ser llevados a producción.
Deployments incrementales
Para Deployments posteriores al primer Deployment a Producción, y para realizar cambios enfocados en el mejoramiento de Procesos que se encuentran operativos, tenga en cuenta las siguientes recomendaciones:
1. Los objetos en producción deben conservarse siempre
Una vez que un Proceso haya sido llevado al ambiente de producción (aplica también cuando un Proceso está marcado como Release Candidate en pruebas), no es posible eliminar en el ambiente de desarrollo cualquier objeto que sea utilizado por este Proceso.
Entre tales objetos, se consideran: entidades, atributos y relaciones, formas, reglas de negocio y definición de participantes (reglas de asignación), definición de sistemas y de elementos de la organización.
De manera similar, no es posible modificar el nombre de estos objetos en producción (la propiedad Nombre). Esto es una restricción para garantizar la estabilidad del ambiente de producción en Deployments posteriores.
2. Sincronización de datos desde otro ambiente
Es una práctica común y recomendada crear usuarios y casos de uso en su ambiente de desarrollo. Si lo hizo, y la información que utilizó en dicho ambiente son datos reales que necesita tener en su ambiente objetivo, la manera más fácil de transferir esa información sin tener que crearla de nuevo es a través de una Sincronización de datos. En tal procedimiento, usted puede escoger cada elemento de data que desee importar a un archivo .bdex que puede ser importado posteriormente en su ambiente objetivo.
Los elementos de datos que pueden ser considerados son las entidades paramétricas administradas en producción, y los Usuarios con sus asociaciones.
3. Versionamiento de Procesos
Una vez que un Proceso haya sido llevado al ambiente de producción (aplica también cuando un Proceso está marcado como Release Candidate en pruebas), no es posible editar su flujo. Dicho Proceso queda bloqueado en desarrollo, de manera que si se requiere un cambio en el flujo (una nueva tarea, una nueva transición, etc), se requiere crear una nueva versión de ese Proceso.
Esto significa que a partir del primer Deployment de un Proceso, no se puede utilizar el Paso 1 del Asistente de Proceso (para la adición o edición de elementos BPMN en el flujo) para la versión del Proceso que está en producción. Para ello, se debe crear una nueva versión del Proceso y de los Subprocesos que utilice.
Por otro lado, los siguientes cambios no requieren que se cree una nueva versión del Proceso:
•Adicionar un nuevo atributo o entidad.
•Adicionar o editar una regla de negocio (sea como acción de Actividad, regla de asignación, o para la invocación de servicios Web o REST).
•Crear una nueva forma de consulta a nivel de aplicación o entidad.
En otras palabras, no se requiere una nueva versión del Proceso si se van a hacer cambios que se realizan desde el paso 2 en adelante del Asistente de Proceso. Más información sobre este tema se detalla en la siguiente sección.
|
Los cambios que se hagan sobre la versión de Proceso actual (sin crear una nueva), aplicarían directamente sobre los casos existentes del ambiente de producción. Por lo tanto, en este escenario es muy importante tener en cuenta las medidas, pruebas y consideraciones necesarias que garanticen que no se presenten problemas de consistencia en los casos nuevos y existentes. |
Para más información sobre las recomendaciones en este aspecto, consulte la guía para nueva versión de Proceso.
4. Posibilidades de edición de los objetos en producción
Una vez que un Proceso haya sido llevado al ambiente de producción (aplica también cuando un Proceso está marcado como Release Candidate en pruebas), Bizagi Studio controlará en el ambiente de desarrollo, las posibilidades para editar los objetos usados por ese Proceso.
Esto es una restricción para garantizar la estabilidad del ambiente de producción en Deployments posteriores.
Por lo tanto, para un Proceso que esté en producción, es recomendado crear una nueva versión de Proceso para realizar cambios que no sean ajustes menores.
Ajustes menores se pueden realizar a la versión actual del Proceso si involucran cambios puntuales sobre ciertos objetos que se usan por esos Procesos, como se detalla en la siguiente tabla:
OBJETO |
OPCIONES |
|---|---|
Entidades y atributos |
No es posible editar las siguientes propiedades de las entidades y atributos (incluye relaciones) : nombre, tipo o fuente. Solo se puede editar su nombre para mostrar. |
Formas (todos los tipos) |
No es posible editar las formas (adicionar, modificar o eliminar controles, o sus expresiones, validaciones o acciones asociadas). Sin embargo, las formas pueden clonarse o versionarse de por si, de manera que se puede cambiar la forma que se usa en cierta Actividad. |
Expresiones (booleanas y de tipo scripting) |
Su código puede ser editado (junto con otras propiedades como el nombre de mostrar o su descripción). Al hacerlo, se debe tener cuidado en no alterar el buen funcionamiento de los casos existentes. |
Funciones personalizadas |
Su código puede ser editado (junto con su descripción). |
Widgets de Bizagi |
Su código puede ser editado (junto con su descripción). |
Definición de participantes (reglas de asignación) |
Todas sus propiedades y condiciones pueden ser editadas. Esto implica las definiciones del criterio y reglas de asignación. |
Definición de la organización |
Solo el nombre de mostrar puede ser editado para los elementos de la organización previamente definidos (áreas, Roles, habilidades, grupos de usuario). |
Esquemas de festivos (en el esquema de horario de trabajo) |
Solo la descripción del esquema de días no laborales puede ser editado. |
Seguridad |
Cambios en la configuración de Autenticación y LDAP, debe hacerse directamente en el ambiente de producción con el Management Console. |
Notificaciones por correo (emails) |
Nuevos mensajes (cuando se utiliza la posibilidad de múltiples correos) se pueden incluir en la configuración de notificaciones. Los mensajes existentes no se pueden eliminar. Dentro de la definición del mensaje, su asunto, destinatario ("Para", "CC", y "BCC"), y contenido del cuerpo, pueden ser editado. Las condiciones de envío de los correos pueden ser editadas también pero no eliminadas. |
Plantillas de Documentos |
Su contenido puede ser editado. |
Invocaciones de interfaces |
La configuración de la invocación a un servicio Web o REST puede cambiarse tal como lo permite el asistente de interfaces en Bizagi. Los ajustes de parámetros (por ejemplo, de conexión, y demás que no requieran un nuevo mapeo de datos), pueden realizarse directamente sobre producción con el Management Console. |
Dimensiones |
Todas sus propiedades pueden ser editadas (excepto el nombre). |
Componentes en la Librería de componentes |
Se puede cambiar el archivo o ensamblado asociado al componente. |
Trabajos personalizados |
Se puede adicionar nuevos Pasos y Programaciones a los trabajos personalizados. |
Políticas |
Se puede editar la descripción, el nombre para mostrar y la documentación. |
Conectores |
Se pueden realizar versiones y actualizaciones menores. Para más información, consulte versionamiento de conectores. |
Cualquier otro cambio que no se encuentre listado en la tabla anterior, requiere crear una nueva versión de Proceso que utilice otro objeto diferente al que ya exista en producción.
5. Nuevas llaves de negocio
Cuando se definen nuevas llaves de negocio, se recomienda revisar que los datos en producción son compatibles con las nuevas características o restricciones (constraints).
De lo contrario, si se aplican llaves de negocio en desarrollo que no se dan con los datos en producción, se tendrá un error de integridad advertido por Bizagi durante el Deployment.
Para ilustrar lo anterior, supongamos que se tiene una entidad llamada Producto, la cual ya fue llevada al ambiente de producción sin definición de llaves de negocio. Entonces, no se debe redefinir posteriormente en la entidad Producto que su llave de negocio es el atributo NombreProducto si se detecta: que hay más de un registro en producción con NombreProducto=Crédito (más de un producto con el mismo nombre).
Además, no se permite realizar cambios en las llaves de negocio con atributos no que no hayan sido desplegados previamente. Es decir, si su entidad tiene dos atributos definidos como la llave de negocio y necesita agregar más, los atributos adicionales deben desplegarse en el ambiente antes de definir la nueva llave de negocio.
Para más información sobre estas definiciones, consulte predefiniendo llaves de negocio.
Last Updated 7/5/2023 2:34:39 PM