|
<< Clic para mostrar Tabla de Contenidos >> Bizagi como Productor de Kafka |
Bizagi como productor de Kafka permite que sus procesos publiquen eventos en Kafka para que sistemas externos puedan reaccionar a ellos.
En lugar de invocar APIs externas directamente, Bizagi puede emitir mensajes a topics de Kafka. Estos mensajes pueden ser consumidos por uno o varios sistemas, lo que habilita integraciones desacopladas y comunicación orientada a eventos.
Al publicar eventos generados durante la ejecución de los procesos, Bizagi puede actuar como una fuente de información para los sistemas conectados, permitiéndoles responder a los eventos de negocio a medida que ocurren.
Cuando Bizagi actúa como productor, envía mensajes a Kafka utilizando un conector.
El flujo es el siguiente:
1.Un proceso alcanza un punto en el que se requiere compartir información
2.Una tarea invoca el conector de Kafka mediante una Acción de Actividad
3.El conector envía el mensaje a un topic de Kafka
4.Kafka distribuye el mensaje a todos los consumidores suscritos
Una vez enviado el mensaje, Kafka es responsable de su entrega. Bizagi no gestiona ni controla cómo los sistemas externos consumen dicho mensaje.
Para publicar eventos, debe configurar un conector de Kafka en Bizagi Studio. Este conector define cómo Bizagi se conecta a Kafka y qué información se envía.
Obtención del conector
Puede obtener el conector de Kafka desde Bizagi Xchange o crearlo si es necesario.

Una vez importado, el conector se comporta como cualquier otro conector de integración y puede utilizarse dentro de sus procesos.
Configuración de la conexión
Antes de utilizar el conector, debe definir cómo se conecta a Kafka.
En la configuración del conector, proporcione:
•La dirección del broker de Kafka
•El protocolo de seguridad
•Las credenciales de autenticación
•La configuración SSL si es requerida

|
Esta configuración es específica por ambiente, lo que significa que cada ambiente (Desarrollo, Pruebas y Producción) debe tener su propia configuración de conexión. |
Uso del conector en un proceso
Para publicar un evento, utilice una Acción de Actividad dentro de una tarea en su proceso.
1.Configure una Acción de Actividad
2.Seleccione el conector de Kafka
3.Elija la acción Producir mensaje

4.Mapee los datos del proceso a los parámetros del conector
En este punto, usted define el contenido del mensaje que será enviado a Kafka.
Configuración del mensaje
Al enviar un mensaje, el conector requiere ciertos valores de entrada.
Los más importantes son:
•Topic: El topic de Kafka al que se enviará el mensaje. Este debe existir previamente en Kafka.
•Mensaje: El contenido del evento, que normalmente se construye a partir de datos del proceso.

También puede definir valores opcionales como:
•Una llave para identificar el mensaje
•Encabezados (Headers)
•Una partición específica
En la mayoría de los casos, basta con definir el topic y el mensaje.
Kafka no impone un formato específico para los mensajes, por lo que puede enviar cualquier tipo de contenido.
Los formatos más comunes incluyen JSON, XML o texto plano.
Sin embargo, es fundamental que los sistemas que consumen el mensaje comprendan su estructura. Por esta razón, debe existir un acuerdo entre el productor y los consumidores sobre el formato del mensaje.
En la mayoría de los escenarios, se prefiere JSON por su facilidad de construcción y procesamiento.
El conector de Kafka debe configurarse de manera independiente en cada ambiente.
Cuando un proceso se ejecuta:
•En Desarrollo, envía mensajes al broker configurado para Desarrollo
•En Pruebas, utiliza la configuración de Pruebas
•En Producción, utiliza la configuración de Producción
Esto garantiza que los mensajes se envíen al ambiente correcto sin interferir con otras configuraciones.
A diferencia del consumo, no existe una interfaz en Management Console para controlar la publicación de mensajes. La ejecución depende completamente del proceso.
Los mensajes se envían inmediatamente cuando se ejecuta la Acción de Actividad.
Kafka es responsable de almacenar, distribuir y entregar el mensaje a los consumidores.
Bizagi no realiza seguimiento de si el mensaje fue consumido ni de lo que ocurre después de su entrega.
Si ocurre un error al enviar el mensaje, el comportamiento depende de cómo esté configurado el conector dentro del proceso.
En términos generales:
•La tarea fallará
•El proceso podrá manejar el error utilizando mecanismos estándar de Bizagi, como flujos alternos o reintentos
Se recomienda diseñar el proceso considerando posibles fallos en la comunicación con sistemas externos.
La publicación de eventos desde Bizagi es útil cuando otros sistemas deben reaccionar a acciones realizadas dentro de sus procesos.
Por ejemplo:
•Un proceso alcanza una etapa de aprobación y envía un evento de notificación a sistemas externos
•Un caso es completado y Bizagi publica el resultado para reportes o analítica
•Bizagi envía actualizaciones que activan procesos en otras plataformas
En estos escenarios, Bizagi se convierte en una fuente de eventos que alimenta el resto del ecosistema.
Bizagi puede actuar como consumidor y productor al mismo tiempo.
Por ejemplo:
1.Un sistema externo publica un evento en Kafka
2.Bizagi consume el evento e inicia un caso
3.El proceso evalúa la información
4.Bizagi publica un nuevo evento con el resultado
Esto crea un flujo continuo de información en el que Bizagi tanto reacciona como genera eventos dentro de una arquitectura distribuida.
Last Updated 7/17/2026 10:26:35 PM