Eventos de Mensaje: Comunicación 1 a 1 en BPMN

En el dinámico mundo de la gestión de procesos de negocio (BPMN), los eventos de mensaje emergen como un mecanismo fundamental para la comunicación y la coordinación entre diferentes componentes de un sistema. Estos eventos, diseñados para gestionar interacciones uno a uno, permiten que un proceso espere la recepción de un mensaje específico antes de continuar su ejecución. Comprender a fondo qué son y cómo funcionan los eventos de mensaje es esencial para modelar procesos robustos y eficientes.

¿Qué son los Eventos de Mensaje?

Un evento de mensaje, en esencia, es un punto de espera dentro de un proceso. Actúa como un semáforo que detiene el flujo de la instancia del proceso hasta que se recibe un mensaje concreto. Este mensaje puede provenir de otro proceso, de un sistema externo o incluso de una interacción del usuario. La clave reside en que los eventos de mensaje establecen una relación uno a uno (1:1) entre el emisor y el receptor del mensaje. Esto significa que un mensaje específico está destinado a una única instancia de proceso en espera.

Eventos de Mensaje vs. Eventos de Señal: Diferencias Clave

Es común confundir los eventos de mensaje con los eventos de señal, ya que ambos son mecanismos de comunicación dentro de BPMN. Sin embargo, existen diferencias fundamentales que los hacen adecuados para distintos escenarios:

• Relación Emisor-Receptor: Los eventos de mensaje son para comunicación uno a uno (1:1), mientras que los eventos de señal son para comunicación uno a muchos (1:N). Un evento de mensaje se dirige a un receptor específico, mientras que un evento de señal puede activar múltiples receptores.
• Flujo de Comunicación: Los eventos de mensaje utilizan flujos de mensaje para conectar emisor y receptor, representando una conexión directa. Los eventos de señal, en cambio, utilizan flujos de señal, que son de tipo broadcast y no requieren una conexión directa entre emisor y receptores.
• Tipo de Comunicación: Los eventos de mensaje son punto a punto, ideales para interacciones específicas y dirigidas. Los eventos de señal son de tipo publicación-suscripción, donde un emisor publica una señal y todos los suscriptores la reciben.
• Número de Receptores: Un evento de mensaje tiene un único receptor, mientras que un evento de señal puede tener múltiples receptores que reaccionan a la misma señal.
• Sincronía: Los eventos de mensaje pueden ser síncronos o asíncronos, dependiendo de la implementación. Los eventos de señal son inherentemente asíncronos.
• Correlación: Los eventos de mensaje pueden ser correlacionados o no correlacionados, lo que permite vincular mensajes a instancias de proceso específicas. Los eventos de señal generalmente son no correlacionados, activando todos los suscriptores que estén a la escucha.

En resumen, si necesitas una comunicación dirigida y específica entre dos puntos de tu proceso, elige eventos de mensaje. Si necesitas notificar a múltiples partes de tu sistema sobre un evento, los eventos de señal son la opción más adecuada.

Tipos de Eventos de Mensaje

Los eventos de mensaje se utilizan en diferentes puntos de un proceso BPMN, adaptándose a diversas necesidades de comunicación:

Eventos de Mensaje de Inicio

Un proceso puede tener uno o varios eventos de mensaje de inicio. Cada uno de estos eventos debe tener un nombre de mensaje único. Al desplegar un proceso con eventos de mensaje de inicio, se crea una suscripción de mensaje para cada uno. Cuando se publica un mensaje con un nombre que coincide con la suscripción, se inicia una nueva instancia del proceso, activando el evento de mensaje de inicio correspondiente.

Es importante destacar que los mensajes publicados antes del despliegue del proceso, o después de una nueva versión del proceso sin un evento de inicio adecuado, no se correlacionan. La clave de correlación (correlationKey) juega un papel crucial en el control de la creación de instancias de proceso.

Si una instancia del proceso ya está activa y fue iniciada por un mensaje con la misma correlationKey, el nuevo mensaje no se correlaciona y no se crea una nueva instancia. Si el mensaje tiene un tiempo de vida (TTL) mayor a 0, se almacena en un buffer. Cuando la instancia activa se completa o termina, y existe un mensaje en buffer con la misma correlationKey y nombre de mensaje, este mensaje se correlaciona e inicia una nueva instancia de la versión más reciente del proceso.

Si la correlationKey del mensaje está vacía, siempre se crea una nueva instancia del proceso sin verificar si ya existe una activa.

Nota importante: La correlationKey no se especifica en el modelo BPMN del evento de inicio de mensaje. Se define en la aplicación que envía el mensaje que activa el evento de inicio.

Eventos de Mensaje de Captura Intermedios

Cuando un proceso alcanza un evento de mensaje de captura intermedio, se crea una suscripción de mensaje correspondiente. La instancia del proceso se detiene en este punto y espera hasta que se correlacione un mensaje. Una vez que se recibe y correlaciona el mensaje, el evento de captura se completa y el proceso continúa su flujo.

Una alternativa a los eventos de mensaje de captura intermedios son las tareas de recepción, que funcionan de manera similar pero pueden utilizarse junto con eventos de límite.

Eventos de Mensaje de Límite

Una actividad puede tener uno o varios eventos de mensaje de límite. Cada evento de mensaje de límite debe tener un nombre de mensaje único. Al iniciar la actividad, se crea una suscripción de mensaje para cada evento de límite. Si se dispara un evento de límite no interruptor, la actividad no se termina y se pueden correlacionar múltiples mensajes.

Eventos de Mensaje de Lanzamiento Intermedios y Eventos de Fin de Mensaje

Un proceso puede incluir eventos de mensaje de lanzamiento intermedios o eventos de fin de mensaje para modelar la publicación de un mensaje a un sistema externo, como un tópico de Kafka. Actualmente, estos eventos funcionan de manera similar a las tareas de servicio o tareas de envío, compartiendo propiedades relacionadas con el trabajo (tipo de trabajo, cabeceras personalizadas, etc.).

Cuando una instancia de proceso entra en un evento de mensaje de lanzamiento, se crea un trabajo correspondiente y espera a su finalización. Un trabajador de trabajos (job worker) debe solicitar trabajos de este tipo y procesarlos. Una vez que el trabajo se completa, el proceso continúa o finaliza si se trata de un evento de fin de mensaje.

Nota importante: Los eventos de mensaje de lanzamiento no son procesados por Zeebe para correlacionar un mensaje con un evento de captura. En cambio, crean trabajos con el tipo de trabajo definido, requiriendo un trabajador de trabajos para su procesamiento.

Definición de Mensajes y Correlación

Un mensaje puede ser referenciado por uno o varios eventos de mensaje. Debe definir el nombre del mensaje (ej. "Pedido Recibido") y la expresión de la clave de correlación (correlationKey) (ej. = idPedido). La correlationKey no es obligatoria si el mensaje solo es referenciado por eventos de mensaje de inicio.

El nombre del mensaje suele ser un valor estático (ej. "Pedido Cancelado"), pero también puede ser una expresión (ej. = "pedido " + estado). Si la expresión pertenece a un evento de inicio de mensaje, se evalúa al desplegar el proceso. En caso contrario, se evalúa al activar el evento de mensaje. La evaluación debe resultar en una cadena de texto (string).

La correlationKey es una expresión que generalmente accede a una variable de la instancia del proceso que contiene la clave de correlación del mensaje. Se evalúa al activar el evento de mensaje y debe resultar en una cadena de texto o un número.

Para correlacionar un mensaje con un evento de mensaje, el mensaje se publica con el nombre definido y el valor de la expresión correlationKey. Por ejemplo, si una instancia de proceso tiene una variable idPedido con valor "pedido-123", el mensaje debe publicarse con la clave de correlación "pedido-123".

Manejo de Variables de Mensaje

Por defecto, todas las variables del mensaje se fusionan en la instancia del proceso. Este comportamiento se puede personalizar definiendo una asignación de salida (output mapping) en el evento de captura de mensaje. Esto permite controlar qué variables del mensaje se transfieren a la instancia del proceso y cómo se mapean.

Ejemplos de Definición de Eventos de Mensaje en BPMN (XML)

Para ilustrar cómo se definen los eventos de mensaje en BPMN, aquí tienes ejemplos en formato XML:

Evento de Mensaje de Inicio

<bpmn:message id="Message_0z0aft4" name="pedido-realizado" /> <bpmn:startEvent id="pedido-realizado" name="Pedido realizado"> <bpmn:messageEventDefinition messageRef="Message_0z0aft4" /> </bpmn:startEvent> 

Evento de Mensaje de Captura Intermedio

<bpmn:message id="Message_1iz5qtq" name="pago-recibido"> <bpmn:extensionElements> <zeebe:subscription correlationKey="= idPedido" /> </bpmn:extensionElements> </bpmn:message> <bpmn:intermediateCatchEvent id="pago-recibido" name="Pago recibido"> <bpmn:messageEventDefinition messageRef="Message_1iz5qtq" /> </bpmn:intermediateCatchEvent> 

Evento de Mensaje de Límite

*(El ejemplo del evento de mensaje de límite no se proporcionó en el texto original, pero seguiría una estructura similar, asociando un evento de mensaje a un evento de límite en una actividad)*

Tabla Comparativa: Eventos de Mensaje vs. Eventos de Señal

Preguntas Frecuentes sobre Eventos de Mensaje

1. ¿Cuándo debo usar un evento de mensaje en lugar de un evento de señal?

   Utiliza eventos de mensaje cuando necesites una comunicación directa y específica entre dos partes de tu proceso, como esperar una respuesta de un sistema externo o la finalización de una tarea en otro proceso. Usa eventos de señal cuando quieras notificar a múltiples partes de tu sistema sobre un evento, sin necesidad de una comunicación directa uno a uno.

2. ¿Qué es la correlationKey y por qué es importante?

   La correlationKey es una clave que permite correlacionar un mensaje entrante con una instancia de proceso específica. Es crucial para asegurar que el mensaje se dirija a la instancia de proceso correcta, especialmente en escenarios donde múltiples instancias del mismo proceso pueden estar activas simultáneamente.

3. ¿Qué pasa si un mensaje llega antes de que el proceso esté esperando por él?

   Si un mensaje llega antes de que se cree la suscripción del evento de mensaje (por ejemplo, antes de que el proceso alcance el evento de captura intermedio), el mensaje no se correlacionará y se perderá a menos que se configure un tiempo de vida (TTL) para el mensaje en el sistema de mensajería subyacente.

4. ¿Puedo usar eventos de mensaje para comunicarme con sistemas externos?

   Sí, los eventos de mensaje son ideales para la comunicación con sistemas externos. Puedes modelar la recepción de mensajes desde sistemas externos utilizando eventos de mensaje de captura, y el envío de mensajes a sistemas externos utilizando eventos de mensaje de lanzamiento.

5. ¿Cuál es la diferencia entre un evento de mensaje de captura intermedio y una tarea de recepción?

   Un evento de mensaje de captura intermedio y una tarea de recepción tienen un comportamiento similar en cuanto a la espera de un mensaje. La principal diferencia radica en que las tareas de recepción pueden utilizarse en combinación con eventos de límite, lo que ofrece mayor flexibilidad en el manejo de interrupciones y errores.

En conclusión, los eventos de mensaje son una herramienta esencial en BPMN para modelar interacciones específicas y dirigidas entre procesos y sistemas. Comprender su funcionamiento y sus diferencias con los eventos de señal es fundamental para diseñar procesos de negocio robustos, eficientes y bien orquestados. Al dominar los eventos de mensaje, podrás crear modelos BPMN que representen con precisión la comunicación asíncrona y la coordinación en sistemas complejos.