Antipatrones

<< Clic para mostrar Tabla de Contenidos >>

Navegación:  Bizagi Studio > Mejores prácticas y recomendaciones de implementación > Mejores prácticas en modelado de procesos >

Antipatrones

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.

 

Good practices24

 

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.

 

Good practices28

 

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.

 

Good practices26