Integración con Kafka

<< Clic para mostrar Tabla de Contenidos >>

Navegación:  Automatización de Procesos con poco código > Studio Cloud -ambiente de autoría > Bizagi Studio > Integrar aplicaciones externas desde Bizagi >

Integración con Kafka

Introducción

La integración de Bizagi con Kafka incorpora capacidades de integración orientadas a eventos en Bizagi. En lugar de depender de comunicación sincrónica basada en solicitud y respuesta, Bizagi puede participar en arquitecturas donde los sistemas intercambian información a través de flujos continuos de eventos.

 

BizagiKafkaIntegration01

 

Este artículo presenta los conceptos necesarios para comprender cómo Bizagi interactúa con Apache Kafka. Sirve como base para las guías específicas sobre cómo Bizagi consume y produce eventos.

 

Arquitectura orientada a eventos

¿Qué es un evento?

Un evento representa el hecho de que ocurrió algo relevante en el contexto de negocio o que se produjo un cambio de estado que puede ser de interés para uno o más sistemas. Algunos ejemplos incluyen un cliente realizando un pedido, la recepción de un pago, la creación de un ticket de soporte o la finalización de una capacitación por parte de un empleado.

 

Los eventos suelen contener información sobre qué ocurrió, cuándo ocurrió y cualquier dato que otros sistemas necesiten para reaccionar ante esa situación.

 

¿Qué es la arquitectura orientada a eventos?

La arquitectura orientada a eventos es un estilo de integración en el que los sistemas se comunican mediante eventos. Cuando ocurre algo relevante en el contexto de negocio, la información correspondiente se pone a disposición de otros sistemas, que pueden reaccionar según sus necesidades.

 

Este enfoque permite que los sistemas intercambien información sin necesidad de conocer en detalle cómo funcionan entre sí, lo que da lugar a un modelo de integración más flexible y escalable.

 

Arquitectura orientada a eventos frente a integraciones de solicitud y respuesta

Las integraciones tradicionales suelen seguir un modelo de solicitud y respuesta. En este enfoque, un sistema envía una solicitud directamente a otro sistema y espera una respuesta antes de continuar con su operación. Ambos sistemas deben estar disponibles y ser capaces de comunicarse al mismo tiempo para que la interacción sea exitosa.

 

Las arquitecturas orientadas a eventos siguen un enfoque diferente. En lugar de solicitar información directamente a otra aplicación, un sistema publica un evento que describe algo que ocurrió.

 

Considere el siguiente ejemplo:

 

Solicitud y respuesta

1.Un cliente realiza un pedido.

2.El sistema de pedidos llama al sistema de inventario y espera su respuesta.

3.El sistema de pedidos llama al sistema de facturación y espera su respuesta.

4.El sistema de pedidos llama al sistema de envíos y espera su respuesta.

5.Cada sistema debe responder correctamente antes de que el proceso continúe.

 

Orientado a eventos

1.Un cliente realiza un pedido.

2.Al mismo tiempo:

a.El sistema de pedidos publica un evento Order Created.

b.El sistema de inventario consume el evento y reserva inventario.

c.El sistema de facturación consume el evento y genera una factura.

d.El sistema de envíos consume el evento y prepara la entrega.

 

En el modelo orientado a eventos, el sistema de pedidos no necesita conocer qué aplicaciones consumen el evento ni cómo lo procesan. Esto reduce las dependencias entre sistemas y facilita agregar, eliminar o actualizar aplicaciones sin afectar las integraciones existentes.

 

Apache Kafka

¿Por qué Apache Kafka?

Las arquitecturas orientadas a eventos requieren una plataforma capaz de distribuir eventos entre sistemas. Aunque existen varias tecnologías que permiten la comunicación basada en eventos, Apache Kafka se ha convertido en una de las plataformas de transmisión de eventos más adoptadas en entornos empresariales.

 

Kafka proporciona las capacidades fundamentales necesarias para respaldar la comunicación orientada a eventos entre sistemas:

•Publicar y suscribirse a eventos: las aplicaciones pueden publicar (escribir) eventos y consumir (leer) eventos producidos por otros sistemas sin necesidad de conexiones directas entre aplicaciones.

•Almacenar eventos de forma confiable: los eventos permanecen disponibles después de ser publicados, lo que permite que los consumidores los procesen incluso si no estaban disponibles cuando ocurrió el evento.

•Procesar flujos de eventos de forma continua: las aplicaciones pueden reaccionar a los eventos de negocio a medida que ocurren, lo que permite escenarios de integración en tiempo real.

 

Para obtener más información, consulte la documentación de Apache Kafka.

 

Lo que esta integración aporta a Bizagi

Esta integración proporciona:

•Actualizaciones en tiempo real, permitiendo intercambiar información a medida que ocurren los eventos.

•Alto rendimiento, capaz de soportar grandes volúmenes de interacciones orientadas a eventos.

•Escalabilidad y extensibilidad, permitiendo que las integraciones crezcan a medida que evolucionan las necesidades del negocio.

•Resiliencia y tolerancia a fallos, ayudando a garantizar que los eventos permanezcan disponibles para su procesamiento durante interrupciones temporales.

 

Conceptos básicos de Kafka

Topics

Un topic es un canal donde se publican eventos. Los productores envían mensajes a los topics y los consumidores los leen desde allí.

 

Por ejemplo, un sistema de pedidos puede publicar eventos en un topic llamado orders. Las aplicaciones interesadas en eventos relacionados con pedidos pueden suscribirse a ese topic.

 

Los topics no se detectan automáticamente. Tanto los productores como los consumidores deben conocer y configurar sus nombres.

 

Publicación (Publishing)

La publicación es la acción de enviar un evento a un topic de Kafka.

 

Cuando ocurre algo relevante, como la creación de un pedido o la recepción de un pago, la aplicación puede publicar un evento para ponerlo a disposición de los consumidores interesados.

 

Por ejemplo, un sistema de pedidos puede publicar un evento Order Created en el topic orders después de que un cliente realiza un pedido.

 

Suscripción (Subscribing)

La suscripción es la acción de escuchar un topic para recibir los eventos publicados en él.

 

Las aplicaciones se suscriben a los topics que les interesan y consumen los eventos a medida que están disponibles.

 

Por ejemplo, Bizagi puede suscribirse al topic orders y consumir eventos Order Created para iniciar un proceso de gestión de pedidos.

 

Productores

Un productor es una aplicación que publica eventos en topics de Kafka.

 

Bizagi puede actuar como productor al publicar eventos relacionados con procesos para que sean consumidos por sistemas externos.

 

Consumidores

Un consumidor es una aplicación que lee y procesa eventos desde Topics de Kafka.

 

Bizagi puede actuar como consumidor al reaccionar a eventos entrantes y ejecutar acciones.

 

Eventos y mensajes

Un evento representa el hecho de que ocurrió algo relevante en el contexto de negocio, mientras que un mensaje es la información que transporta los datos de ese evento.

 

En Kafka, los eventos se intercambian y almacenan como mensajes.

 

Kafka no impone una estructura específica. Los mensajes pueden utilizar formatos como JSON, XML o texto plano, pero los productores y consumidores deben acordar el formato y el contenido del mensaje.

 

Consumer Group ID

Un Consumer Group ID identifica un grupo de consumidores que trabajan conjuntamente para procesar eventos desde un mismo Topic.

 

Los consumidores que comparten el mismo Consumer Group ID comparten el procesamiento de los eventos. Los consumidores que utilizan Consumer Group ID diferentes reciben los eventos de forma independiente.

 

Este valor puede definirse de acuerdo con los requisitos de la integración.

 

Offsets

Los Offsets definen la posición de un mensaje dentro de un topic.

 

Kafka utiliza los Offsets para realizar el seguimiento de qué mensajes ha procesado un consumidor y desde dónde debe continuar el consumo.

 

Contrato de mensajes

Un contrato de mensajes es el acuerdo entre productores y consumidores sobre cómo debe estructurarse e interpretarse un mensaje.

 

Este acuerdo define:

•La estructura del mensaje

•El significado de los datos

•El contenido esperado

 

Siguientes pasos

Ahora que conoce los conceptos principales de las arquitecturas orientadas a eventos y Apache Kafka, puede continuar con las siguientes guías:

•Consumir eventos con Bizagi, para aprender cómo Bizagi se suscribe a Topics de Kafka y reacciona a eventos entrantes.

•Publicar eventos con Bizagi, para aprender cómo Bizagi envía eventos relacionados con procesos a Topics de Kafka para que sean consumidos por sistemas externos.


Last Updated 9/24/2026 7:24:21 PM