Subproceso de evento

Información general

Un subproceso de evento te permite reaccionar a eventos en el ámbito del proceso o subproceso. No está conectado al flujo de secuencia principal.

En su lugar, el motor lo desencadena cuando se produce un evento de inicio configurado mientras el ámbito adjunto está activo.

Utiliza un subproceso de evento cuando quieras:

• Centralizar la lógica de gestión de errores relacionada.
• Evite duplicar eventos de error de límite en varias tareas.
• Comportamiento de control en el ámbito del proceso o subproceso.
• Reaccionar a mensajes externos en tiempo de ejecución.
• Ejecuta la lógica de recuperación, registro o notificación de forma coherente.

En Maestro, un subproceso de evento puede comenzar con:

• un evento de inicio de error
• un evento de inicio de mensaje

Evento de inicio de error

Un evento de inicio de error desencadena el subproceso de evento cuando se produce un error BPMN y el código de error coincide, o cuando el evento se configura como catch-all.

Cuando se produce un error BPMN, el motor evalúa los subprocesos de eventos coincidentes en el mismo ámbito antes de evaluar los eventos de error de límite. Este orden de evaluación da prioridad al subproceso del evento.

Comportamiento de ejecución

Un evento de inicio de error siempre está interrumpiendo.

Cuando se produce el error, el motor:

• Desencadena el subproceso del evento.
• Cancela el ámbito del proceso o subproceso adjunto.
• Detiene todas las rutas activas dentro de ese ámbito.

Utiliza un evento de inicio de error cuando el error invalida la ejecución actual.

Ejemplos de la vida real:

• Una autorización de pago falla debido a la detección de fraude.
• Una validación de cumplimiento obligatoria falla durante la incorporación.
• Una dependencia crítica del sistema no está disponible.

Gestión de errores sin y con un subproceso de evento

Sin un subproceso de evento	Con un subproceso de evento
Adjuntas eventos de error de límite a tareas individuales.	Se define un subproceso de evento en el ámbito del proceso o subproceso.
A menudo se duplica una lógica de error similar en varias tareas.	Centralizas la lógica de gestión de errores relacionada en un solo lugar.
Cada tarea controla su propia gestión de errores.	El ámbito controla la gestión de errores para todas las tareas dentro de él.
El mantenimiento se vuelve más difícil a medida que el modelo crece.	El mantenimiento se vuelve más sencillo porque actualizas la lógica de error en un solo lugar.

Impacto en los modelos existentes

El motor cambia de comportamiento solo si añades un subproceso de evento al mismo ámbito.

• Los modelos que utilizan solo eventos de error de límite siguen comportándose como antes.
• Si añades un subproceso de evento, este gestiona los errores genéricos que no son gestionados por los eventos de error de límite en el mismo ámbito.
• Si ningún evento de error de límite coincide con un error lanzado, el motor evalúa el subproceso del evento.

No configures tanto un evento de error de límite como un subproceso de evento para gestionar la misma referencia de error dentro del mismo ámbito.

Reglas de configuración

Para un ámbito determinado (proceso o subproceso):

• Utilice solo un subproceso de evento por código de error.
• Utilice solo un subproceso de evento general.

Para una tarea determinada:

• Utiliza solo un evento de error de límite por código de error.
• Utiliza solo un evento de error de límite general.

Evento de inicio de mensaje

Un evento de inicio de mensaje desencadena el subproceso de evento cuando el motor recibe el mensaje configurado mientras el ámbito adjunto está activo.

Comportamiento de ejecución

El motor escucha el mensaje configurado mientras el ámbito adjunto está activo. Cuando recibe el mensaje, desencadena el subproceso de evento según su configuración de interrupción o no interrupción.

Los eventos de inicio de mensaje no anulan ni tienen prioridad sobre otros eventos de mensaje. Cada evento de mensaje reacciona de forma independiente en función de su ámbito y configuración.

Gestión de mensajes sin y con un subproceso de evento

Sin un subproceso de evento	Con un subproceso de evento
Modelas la gestión de mensajes dentro del flujo de secuencia principal.	Se define un subproceso de evento en el ámbito del proceso o subproceso.
Debes enrutar el flujo principal a través de eventos de captura de mensajes intermedios.	El motor escucha el mensaje mientras el ámbito está activo.
El proceso principal debe alcanzar explícitamente el evento del mensaje para reaccionar a él.	El subproceso del evento puede desencadenarse en cualquier momento mientras el ámbito esté activo.
La lógica de gestión de mensajes se acopla estrechamente a la estructura del flujo principal.	La lógica de gestión de mensajes sigue siendo independiente del flujo de secuencia principal.
Cambiar el comportamiento del mensaje puede requerir reestructurar el flujo principal.	Puedes actualizar la gestión de mensajes sin modificar el flujo principal.
El flujo principal siempre se detiene en el evento del mensaje.	Puedes configurar el evento de inicio de mensaje como con interrupción o sin interrupción.

Impacto en los modelos existentes

El motor cambia de comportamiento solo si añades un evento de inicio de mensaje dentro de un subproceso de evento.

• Los modelos que no utilizan un subproceso de evento siguen comportándose como antes.
• Una vez añadido un evento de inicio de mensaje, el motor escucha el mensaje configurado mientras el ámbito adjunto está activo.
• Si configuras el evento de inicio de mensaje como interrupción, el motor cancela el ámbito adjunto cuando recibe el mensaje.
• Si lo configuras como sin interrupción, el motor inicia el subproceso del evento en paralelo y permite que continúe el flujo principal.

No configures varios eventos de inicio de mensaje con la misma referencia de mensaje en el mismo ámbito.

Interrumpir vs no interrumpir

Puedes configurar un evento de inicio de mensaje como con interrupción o sin interrupción.

Interrumpir

Cuando el motor recibe el mensaje:

• Desencadena el subproceso del evento.
• Cancela el ámbito del proceso o subproceso adjunto.
• Detiene todas las rutas activas dentro de ese ámbito.

Utiliza un evento de inicio de mensaje de interrupción cuando el mensaje represente una señal externa que deba detener la ejecución actual.

Ejemplos de la vida real:

• Un cliente cancela un pedido mientras se está procesando.
• Un regulador envía una instrucción de detención de procesamiento.
• Un sistema principal envía un comando de terminación.

Sin interrupción

Cuando el motor recibe el mensaje:

• Desencadena el subproceso del evento.
• Mantiene activo el ámbito adjunto.
• Ejecuta el subproceso del evento en paralelo.
• Permite que continúe el proceso principal.

Utiliza un evento de inicio de mensaje sin interrupción cuando el mensaje deba desencadenar lógica adicional sin interrumpir el flujo principal.

Ejemplos de la vida real:

• Un cliente actualiza los datos de contacto mientras continúa la incorporación.
• Un sistema asociado envía metadatos adicionales.
• Un mensaje de notificación desencadena el registro de auditoría.