<< Clic para mostrar Tabla de Contenidos >> Navegación:  Automatización de Procesos con poco código > Studio Cloud -ambiente de autoría > Bizagi Studio > Asistente de Procesos > Modelar Procesos > Mejores prácticas en modelado de procesos > Manejando el paralelismo en Bizagi

Introducción

En Bizagi, hay casos en los que es necesario almacenar información dentro de la misma entidad Maestra (tabla de Bizagi), ingresada o poblada por diferentes usuarios (Participantes) de manera simultánea. Esto puede ocurrir en escenarios que involucran actividades paralelas o instancias de subprocesos paralelos.

 

Por ejemplo, considere una empresa de indumentaria que realiza evaluaciones periódicas de diferentes proveedores. En este proceso específico, se requiere que dos gerentes registren simultáneamente sus puntajes de evaluación y comentarios a través de actividades paralelas, como se ilustra en el proceso de negocio a continuación.

 

 

 

Escenario de negocio

Continuando con el proceso de evaluación de proveedores descrito anteriormente, es fundamental almacenar las puntuaciones de evaluación y los comentarios proporcionados por cada gerente en la entidad Maestra llamada mEvaluationResults. Esto implica la creación de una sola instancia de entidad, haciendo énfasis en la importancia de manejar la creación y persistencia de esta instancia única con precisión dentro de la base de datos de Bizagi. Es imperativo tener una comprensión sólida del uso de scopes en Bizagi para adoptar este enfoque de mejores prácticas en la gestión del paralelismo.

 

Dentro de la forma de actividad de cada gerente, hay tres campos obligatorios de la entidad Maestra mEvaluationResults. Sin embargo, cabe destacar que los XPath para registrar los resultados de la evaluación difieren para cada gerente, como se describe en las tablas XPath a continuación.

 

 

 

Una vez que el solicitante ha enviado los detalles del producto/servicio y la información básica del proveedor, se activan dos actividades para cada gerente, cada una con su propio scope. Dado que los campos de evaluación pertenecen a la misma entidad (mEvaluationResults), el XPath común es mVendorSelection.kmVendorToEvaluate.kmVendorBasicInfo.kmEvaluationResults, como se indica en el modelo de datos del proceso.

 

Sin un valor predeterminado o inicial establecido y persistido en la base de datos del proyecto de Bizagi dentro de la tabla mEvaluationResults antes de la instanciación de las dos actividades de Evaluar Proveedor, Bizagi crea scopes separados para cada actividad. En consecuencia, la tabla contiene dos instancias distintas creadas en cada scope. Al finalizar y enviar la evaluación del proveedor por parte del último gerente, Bizagi sobrescribe los valores de la primera instancia en mEvaluationResults, lo que resulta en la pérdida de entradas proporcionadas por el gerente inicial.

 

Mejor práctica

El enfoque recomendado es establecer una regla de negocio que se ejecutará antes de la creación de las dos instancias de actividad. Por ejemplo, esta regla podría establecerse como una acción Al salir en la actividad Registrar Información Básica del Proveedor o como una acción Al entrar en la compuerta paralela PG1.

 

Al realizar este paso, Bizagi asegura la persistencia de una instancia única en la tabla mEvaluationResults en la base de datos. En consecuencia, no surgen conflictos ni problemas cuando se crean posteriormente los dos scopes para cada actividad de Evaluar Proveedor.

 

 

Alternativamente, el flujo de trabajo se puede ajustar eliminando la actividad Registrar Información Básica del Proveedor. En su lugar, se puede implementar una forma de inicio para evitar la creación de nuevos casos (instancias de proceso) que no puedan enviarse desde esa actividad inicial. Esto se ilustra en el siguiente diagrama de flujo de trabajo:

 

 

Aquí, la regla de negocio utilizada para establecer un valor predeterminado se puede configurar como una acción Al salir en el evento de Inicio o como una acción Al entrar en la compuerta paralela PG1.

 

 

Las siguientes dos líneas de código establecen una fecha predeterminada para los campos Fecha de Evaluación para cada gerente:

 

<mVendorSelection.kmVendorToEvaluate.kmVendorBasicInfo.kmEvaluationResults.dEvaluationDate1> = DateTime.Today;
 
<mVendorSelection.kmVendorToEvaluate.kmVendorBasicInfo.kmEvaluationResults.dEvaluationDate2> = DateTime.Today;

 

Tras la ejecución de estas líneas de código y la finalización exitosa de la transacción, Bizagi genera una instancia única en la entidad maestra mEvaluationResults. Específicamente, esto da como resultado un valor distintivo para <mVendorSelection.kmVendorToEvaluate.kmVendorBasicInfo.kmEvaluationResults.Id>.

 

Recomendaciones adicionales

1. Evite campos comunes en Actividades Paralelas

En escenarios donde se crean instancias de actividades paralelas, como en el ejemplo de evaluación de proveedores, es crucial abstenerse de tener campos comunes en las formas para cada actividad. Esto aplica tanto a los campos editables como a los no editables. Por ejemplo, la actividad Evaluar Proveedor para el Gerente 1 no debe incluir campos de la actividad Evaluar Proveedor para el Gerente 2.

 

2. Evite inconsistencias de datos con registros compartidos de entidades Maestras

Tenga cuidado al tratar el mismo registro de una entidad Maestra en casos que involucran instancias paralelas. Pueden surgir inconsistencias en los datos, especialmente cuando dos casos diferentes (instancias de proceso) usan el mismo registro de una entidad Maestra para editar o actualizar valores. Por ejemplo, si diferentes creadores de casos crean dos instancias de proceso para actualizar la información básica de un proveedor, solo los valores enviados por el último usuario que completó la acción de actualización persisten en la base de datos del proyecto, lo que lleva a la sobrescritura de los valores ingresados por el primer usuario.

Last Updated 1/16/2024 1:43:59 PM