Los antipatrones son patrones de modelado utilizados erróneamente para representar algunas condiciones de negocio. En general, los antipatrones parecen funcionar bien, pero su uso no es directamente compatible o no cumple con BPMN y podrían hacer que los procesos no funcionen como se esperaba. Por estas razones, no se recomienda utilizar Antipatrones.
A continuación encontrará algunos de los antipatrones de uso más frecuente:
Evite poner elementos diferentes a Eventos y tareas después de una compuerta basada en eventos
Ej: patrón de cancelación con Compuertas Paralelas
La compuerta basada en eventos proporciona un patrón de modelado útil, el cual, debe ser usado apropiadamente. Teniendo en cuenta que este tipo de compuerta permite y controla las diferentes posibilidades en el flujo de proceso. Asegúrese de que esta compuerta siempre sea seguida por tareas o eventos. Otros elementos BPMN (como subprocesos u otras compuertas) que estén justo después de esta compuerta no son compatibles.
Es común ver a procesos automatizados usando un patrón de cancelación que involucra una Compuerta basada en eventos seguido de una compuerta Paralela.
El proceso se cancela por completo si se ejecuta un evento o si llega a en cierto tiempo antes de que se complete un conjunto de actividades, de lo contrario, se deshabilita la lógica de la cancelación.
A la izquierda, la manera más común para modelar esta cancelación; este tipo de patrón no es compatible con BPMN y por lo tanto, no está respaldada por Bizagi.
A la derecha una forma alternativa; Un evento adicional se utiliza para descartar la lógica cancelación una vez que se llevan a cabo las actividades necesarias.
Cuando utilice una puerta de enlace divergente, no bifurque el flujo antes de converger
Cuando el flujo de su proceso utiliza una compuerta divergente, se recomienda utilizar una compuerta convergente del mismo tipo para recolectar todos los tokens creados.
Usted no debe bifurcar el flujo antes de converger, ya que Bizagi no podrá controlar las rutas creadas.
Nunca use señales o mensajes en subprocesos embebidos
los Subprocesos embebidos (también conocidos como Experto) no deben contener señales o mensajes. Estos pueden causar que el subproceso se abra a la espera de algo para activarlos, y no permitir que el proceso padre para termine correctamente.
Nunca utilice Eventos de Mensaje para enviar correos electrónicos
Los Eventos de Mensaje no se deben utilizar para enviar correos electrónicos durante el flujo del proceso. Estos elementos deben ser utilizados para permitir la comunicación entre proceso.
Los correos electrónicos deben ser enviados utilizando Activity actions.
Nunca use señales o mensajes para activar caminos dentro de un mismo proceso
Las señales son eventos que se escuchan en todos los procesos activos y por esto cuando se lanza una señal en un proceso el camino que se desea activar se activa en todos los procesos existentes, no solo en el proceso requerido.
En este tipo de situación es necesario usar un evento condicional.
Un ejemplo común de este error es cuando se desea deshabilitar la opción de cancelar el proceso.
En la izquierda y en la mitad, las maneras más comunes para modelar este caso; este tipo de patrón no es la manera adecuada de modelar el proceso y por lo tanto generara errores en el proceso de Bizagi.
A la derecha una forma alternativa; Se usa un evento condicional en lugar de la señal o el mensaje junto con una tarea de script que activa el evento.
Usando eventos temporizadores adjuntos
Cuando usa los eventos de temporizador adjuntos y se activa la ruta de excepción (cuando el temporizador alcanza su duración), el caso sigue al siguiente elemento en la ruta de excepción. Sin embargo, las acciones de la actividad Al salir (flecha roja), o las validaciones de formularios incluidas en la tarea (como campos obligatorios) no se ejecutan. Por lo tanto, como práctica recomendada, es aconsejable incluir una tarea de secuencia de comandos de validación, que restablezca o elimine la información que no desea conservar cuando la ruta pasa por la ruta de excepción (la ruta del temporizador).
Consideraciones con elementos BPMN síncronos que se ejecutan automáticamente después de un evento de temporizador
Los eventos de temporizador son ejecutados por el Scheduler. Cuando se ejecuta un temporizador en un proceso, se crea un nuevo trabajo del Scheduler. Puede ver todos los trabajos en el Management Console.
Si después de un evento de temporizador modela elementos BPMN que se ejecutan automáticamente de manera síncrona (sin intervención del usuario), cuando el trabajo del temporizador llega a su tiempo de ejecución (duración del temporizador) y ejecuta el temporizador, Bizagi también ejecuta el temporizador y todos sus elementos posteriores en la misma transacción.
Si alguno de los elementos automáticos de BPMN falla, Bizagi retrocede al elemento que inició la transacción, el temporizador. Esto significa que el temporizador no se vuelve a ejecutar y el caso se bloquea en el evento del temporizador.
Ejemplos de elementos que se ejecutan automáticamente de forma síncrona (sin intervención del usuario) son:Cuando modela elementos BPMN que se ejecutan automáticamente de forma síncrona (sin intervención del usuario) como:
•Todas las tareas automáticas se ejecutan de forma sincrónica. Por ejemplo:
-Tareas de servicio como actividades sincrónicas.
-Tareas de escritura.
•Expresiones al salir del evento del temporizador.
Expliquemos este comportamiento con el siguiente ejemplo.
Después de ejecutar la Tarea 1, se ejecutan los siguientes pasos:
1. El trabajo en el Scheduler se crea con la duración establecida en el temporizador. Vea cómo configurar la duración del temporizador.
2. Cuando el trabajo alcanza la duración del temporizador, ejecuta el temporizador e inicia una transacción con todos los siguientes elementos:
•Expresiones al salir del evento del temporizador.
•Todas las tareas automáticas se ejecutan de forma sincrónica.
Por lo tanto, en el ejemplo, se ejecuta la Tarea 2 (esta tarea se establece como síncrona).
3. En la misma transacción, Bizagi ejecuta la tarea Script, Tarea 3. Ahora, supongamos que la Tarea 3 falla en este punto.
4. Bizagi retrocede al elemento del temporizador. Sin embargo, Bizagi NO crea un nuevo trabajo del Scheduler. Esto significa que el temporizador no se vuelve a ejecutar y el caso se bloquea en el evento del temporizador.
Para evitar este comportamiento, debe configurar la tarea de servicio (Tarea 2) como una actividad asincrónica, consulte Uso de actividades asincrónicas, y también mueva cualquier expresión al salir del temporizador a una tarea asincrónica. Al hacer esto, si la Tarea 2 o la Tarea 3 fallan, luego de ejecutar el temporizador, Bizagi revierte la transacción a la Tarea 2, para que pueda configurar reintentos, o reintentar manualmente desde la Consola de Actividades Asincrónicas.
Utilizar tareas de servicio para notificaciones por correo electrónico
Generalmente, las notificaciones por correo electrónico se configuran en una tarea Script. Este tipo de tarea se ejecuta automáticamente de forma síncrona, y todas las tareas sincrónicas en secuencia se ejecutan en una misma transacción. Si una de las actividades falla, Bizagi retrocede al elemento que inició la transacción. Si se incluye una tarea Script en esta secuencia, el correo electrónico se enviará nuevamente y podría terminar en comunicaciones repetidas.
Considere el siguiente proceso para entender este comportamiento.
En este proceso, la Tarea 4 es una tarea Script utilizada para enviar notificaciones por correo electrónico, y la Tarea 3 es una tarea de Servicio configurada como una actividad sincrónica. Por lo tanto, la transacción posterior a la Tarea 1 sigue estos pasos:
1. Se ejecuta la Tarea 2 (tarea Script).
2. Se ejecuta la Tarea 3 (tarea de Servicio). Al estar configurada como actividad sincrónica, se ejecuta automáticamente en la misma transacción.
3. Bizagi continúa con la ejecución de la Tarea 4 (tarea Script). Recuerde que esta tarea se utiliza para enviar notificaciones por correo electrónico y las tareas de Script se ejecutan automáticamente de forma síncrona. En este punto, suponga que esta tarea falla.
4. Como ninguna de las tareas anteriores se configuró como actividad asincrónica, Bizagi retrocede a la Tarea 1. Considerando que la Tarea 4 fue la que falló, esto significa que la Tarea 2 y la Tarea 3 se ejecutan nuevamente.
Para evitar este comportamiento, tenga en cuenta que para la ejecución de tareas automáticas en secuencia, la mejor práctica es convertir tantas tareas automáticas como sea posible en actividades asincrónicas. Luego, en este ejemplo, es altamente aconsejable configurar la Tarea 3 (tarea de Servicio) como una actividad asincrónica. De esta manera, Bizagi retrocede a esta tarea si esta (o cualquier tarea posterior) falla, y usted podrá configurar reintentos y observar el registro de errores en la Consola de Actividades Asincrónicas del Portal de Trabajo.
Adicionalmente, recuerde que es posible configurar notificaciones por correo electrónico desde una tarea de Servicio. Por lo tanto, como práctica recomendada para la ejecución de tareas automáticas en secuencia, se recomienda cambiar las tareas Script utilizadas para enviar notificaciones por correo electrónico (por ejemplo, la Tarea 4) a tareas de Servicio configuradas como actividades asincrónicas y que cumplen el mismo propósito. De esta manera, puede detener el retroceso de Bizagi a tareas ya ejecutadas cuando una tarea de notificación por correo electrónico falla, y reanudar la ejecución de la transacción desde esta.
Last Updated 1/26/2022 11:18:10 AM