Subproceso de evento

Información general

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

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

Usa un subproceso de evento cuando quieras:

• Centralizar la lógica de gestión de errores relacionada.
• Evitar duplicar eventos de error de límite en varias tareas.
• Controlar el comportamiento en el ámbito del proceso o subproceso.
• Reaccionar a los mensajes externos en runtime.
• Ejecutar 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 activa el subproceso de evento cuando se produce un error de BPMN y el código de error tiene coincidencias, o cuando el evento se configura como general.

Cuando se produce un error de 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 de eventos.

Comportamiento de ejecución

Un evento de inicio de error siempre interrumpe.

Cuando se produce el error, el motor:

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

Usa 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 ningún subproceso de evento	Con un subproceso de evento
Adjuntas eventos de error de límite a tareas individuales.	Defines un subproceso de evento en el ámbito del proceso o subproceso.
A menudo duplicas 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 propio manejo de errores.	El ámbito controla el manejo de errores para todas las tareas dentro de él.
El mantenimiento se vuelve más difícil a medida que crece el modelo.	El mantenimiento se vuelve más simple porque actualizas la lógica de error en un solo lugar.

Impacto en los modelos existentes

El motor cambia el 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, maneja los errores genéricos que no son manejados por los eventos de error de límite en el mismo ámbito.
• Si ningún evento de error de límite tiene coincidencias con un error lanzado, el motor evalúa el subproceso de evento.

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

Reglas de configuración

Para un ámbito dado (proceso o subproceso):

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

Para una tarea dada:

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

Evento de inicio de mensaje

Un evento de inicio de mensaje activa 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. Al recibir el mensaje, activa 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 ningún subproceso de evento	Con un subproceso de evento
Modelas la gestión de mensajes dentro del flujo de secuencia principal.	Defines un subproceso de evento en el ámbito del proceso o subproceso.
Debes enrutar el flujo principal a través de eventos de captura de mensaje intermedios.	El motor escucha el mensaje mientras el ámbito está activo.
El proceso principal debe llegar explícitamente al evento de mensaje para reaccionar al mismo.	El subproceso de evento puede desencadenarse en cualquier momento mientras el ámbito esté activo.
La lógica de manejo de mensajes se acopla estrechamente a la estructura de flujo principal.	La lógica de manejo de mensajes sigue siendo independiente del flujo de la secuencia principal.
Cambiar el comportamiento del mensaje puede requerir la reestructuración del flujo principal.	Puedes actualizar la gestión de mensajes sin modificar el flujo principal.
El flujo principal siempre se detiene en el evento de mensaje.	Puedes configurar el evento de inicio de mensaje como de interrupción o sin interrupción.

Impacto en los modelos existentes

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

• Los modelos que no utilizan un subproceso de evento siguen comportándose como antes.
• Una vez que añades 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 de interrupción, el motor cancela el ámbito envolvente cuando recibe el mensaje.
• Si lo configuras como sin interrupción, el motor inicia el subproceso de evento en paralelo y permite que el flujo principal continúe.

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

Con interrupción frente a sin interrupción

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

Interrumpir

Cuando el motor recibe el mensaje:

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

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

Ejemplos de la vida real:

• Un cliente cancela una orden 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 de evento.
• Mantiene activo el ámbito de inclusión.
• Ejecuta el subproceso de evento en paralelo.
• Permite que el proceso principal continúe.

Usa 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 detalles de contacto mientras continúa la incorporación.
• Un sistema asociado envía metadatos adicionales.
• Un mensaje de notificación activa el registro de auditoría.