Event

1. Visión General

El componente Event (event) permite que diferentes flujos conversen entre sí por medio de eventos: un flujo "publica" un evento con un nombre, y otro flujo (o varios) "escucha" ese mismo nombre y reacciona a él. Es el patrón conocido como publish/subscribe (publicación y suscripción).

Úsalo cuando dos o más flujos necesitan comunicarse sin estar directamente conectados (por ejemplo, un flujo dispara un evento de "pedido creado" y otro flujo, totalmente independiente, escucha ese evento para enviar una notificación). No lo uses para llamadas directas y síncronas dentro del mismo flujo — en ese caso, el componente Function/Function Caller es más adecuado.

2. Prerrequisitos

• Para eventos con ámbito LOCAL: ningún requisito adicional, todo ocurre dentro de la misma instancia de la aplicación.
• Para eventos con ámbito SHARED (compartido entre instancias/aplicaciones): es necesario un servidor RabbitMQ configurado y accesible por la plataforma, con usuario y contraseña definidos en la configuración de la aplicación (no en el componente en sí).
• Requisitos de red: acceso al puerto estándar de RabbitMQ (5672) cuando el ámbito sea SHARED.

3. Autenticación y Conexión

El componente no expone campos de autenticación directamente — la conexión con RabbitMQ (usada solo en el ámbito SHARED) se configura a nivel de aplicación, no por flujo.

Campo	Obligatorio	Tipo	Descripción	Ejemplo
eventName	Sí	Texto	Nombre del evento. Debe ser el mismo en quien publica y en quien escucha.	"pedido-criado"
eventScope	Sí	Texto: LOCAL o SHARED	LOCAL: comunicación solo dentro de la misma instancia de la aplicación. SHARED: comunicación entre diferentes instancias/aplicaciones, vía cola de mensajes.	"SHARED"
eventType	No	Texto: SYNC o ASYNC	Define si quien publica el evento espera una respuesta (SYNC) o solo dispara y sigue adelante (ASYNC). Valor por defecto: vacío (ningún tipo definido).	"SYNC"
timeout	No	Número (milisegundos)	Tiempo máximo de espera por una respuesta en eventos síncronos, o tiempo de vida del mensaje en la cola. Valor por defecto: 3600000 (1 hora).	30000
executeOnExpire	No	Texto	Nombre de una función (registrada con el componente Function) que se llamará si el mensaje expira antes de ser procesado.	"tratarEventoExpirado"

4. Configuración / Operaciones Soportadas

El componente actúa de dos formas dentro de un flujo:

• Como disparador (escucha): el flujo inicia cuando el evento configurado se publica en algún lugar.
• Como acción (publicación): en otro punto del flujo, el componente publica un evento con el nombre configurado, enviando el cuerpo actual del mensaje.

Al publicar un evento síncrono (eventType: SYNC), quien publicó espera la respuesta de quien escuchó, dentro del tiempo definido en timeout. Al publicar un evento asíncrono (eventType: ASYNC), la publicación no espera respuesta.

Comportamiento en caso de error: si el mensaje expira (pasó el tiempo definido en timeout antes de ser procesado), el evento no se ejecuta y, si executeOnExpire está configurado, esa función es llamada para manejar la expiración. Si la ejecución del evento falla, el error se propaga a quien publicó (en eventos síncronos).

5. Ejemplos Prácticos

Ejemplo simple: dos flujos dentro de la misma aplicación. El primero publica un evento llamado "cliente-atualizado" con eventScope: LOCAL cada vez que se modifica un registro. El segundo flujo escucha ese mismo evento y actualiza una caché interna cada vez que ocurre.

Entrada del flujo que publica:

{
  "clienteId": 456,
  "camposAlterados": ["email", "telefone"]
}

Configuración del componente que publica el evento:

{
  "componentName": "event",
  "configurations": {
    "eventName": "cliente-atualizado",
    "eventScope": "LOCAL",
    "eventType": "ASYNC"
  }
}

Configuración del componente que escucha el evento (inicio del flujo que reacciona):

{
  "componentName": "event",
  "configurations": {
    "eventName": "cliente-atualizado",
    "eventScope": "LOCAL"
  }
}

El flujo que escucha recibe exactamente el mismo cuerpo publicado:

{
  "clienteId": 456,
  "camposAlterados": ["email", "telefone"]
}

Ejemplo avanzado: dos sistemas diferentes (corriendo en instancias separadas) necesitan intercambiar información de forma síncrona. El flujo A publica un evento "validar-estoque" con eventScope: SHARED y eventType: SYNC, esperando hasta 30 segundos (timeout: 30000) la respuesta del flujo B, que está escuchando ese mismo evento en otra aplicación. Si el flujo B tarda más que eso, el mensaje expira y la función configurada en executeOnExpire es llamada para registrar la falla.

Entrada del flujo que publica:

{
  "produtoId": "SKU-789",
  "quantidade": 5
}

Configuración del componente que publica:

{
  "componentName": "event",
  "configurations": {
    "eventName": "validar-estoque",
    "eventScope": "SHARED",
    "eventType": "SYNC",
    "timeout": "30000",
    "executeOnExpire": "tratarEventoExpirado"
  }
}

Respuesta recibida por quien publicó, cuando el flujo B responde a tiempo:

{
  "responses": [
    { "body": "{\"disponivel\":true,\"quantidadeEstoque\":42}" }
  ]
}

6. Puntos de atención

• En el ámbito LOCAL, el evento solo es visto por flujos que corren en la misma instancia de la aplicación.
• En el ámbito SHARED, depende de un RabbitMQ accesible para publicar y escuchar eventos.
• Los eventos síncronos quedan esperando respuesta hasta el timeout configurado — conviene dimensionar ese valor de acuerdo con el tiempo real de procesamiento esperado.

7. Errores Comunes y Troubleshooting

Error / Síntoma	Causa probable	Cómo resolverlo
El evento publicado nunca se recibe	eventName no es idéntico entre quien publica y quien escucha, o los ámbitos (LOCAL/SHARED) son diferentes.	Comprobar que el nombre del evento y el ámbito sean exactamente los mismos en ambos lados.
La publicación síncrona tarda y devuelve error	Nadie está escuchando el evento, o quien escucha tarda más que el timeout configurado.	Confirmar que exista un flujo activo escuchando ese evento y aumentar el timeout si es necesario.
"Timeout at [hora]. Skipping execution" (en el log)	El mensaje llegó después del tiempo límite definido en timeout.	Revisar si el timeout es adecuado al tiempo real de procesamiento esperado, o investigar lentitud en el consumidor.
El evento en el ámbito SHARED no funciona	RabbitMQ no está accesible o está mal configurado en la aplicación.	Verificar la conectividad y las credenciales de RabbitMQ configuradas en la aplicación.