Introducción
Bizagi como consumidor de Kafka permite que sus procesos reaccionen en tiempo real a eventos generados por sistemas externos. Cuando un mensaje es publicado en un topic de Kafka, Bizagi lo consume automáticamente y ejecuta una acción como iniciar un caso o crear un registro.
Al integrarse con arquitecturas orientadas a eventos, Bizagi puede transformar eventos entrantes en acciones de negocio estructuradas, lo que ayuda a garantizar que los procesos reaccionen de forma inmediata a los cambios en los sistemas conectados.
Cómo funciona el consumo
Antes de configurar Kafka, resulta útil comprender qué sucede internamente cuando llega un mensaje.
Bizagi utiliza un servicio interno que se ejecuta en la Azure Function de Triggers and Actions. Este servicio escucha de manera continua los nuevos mensajes en los topics configurados.
El flujo es el siguiente:
1.Un sistema externo publica un mensaje en un topic de Kafka
2.Bizagi recibe el mensaje a través del servicio de consumo
3.El mensaje se envía a una cola interna de Service Bus
4.Una función procesa el mensaje desde la cola
5.Bizagi ejecuta la acción configurada mediante OData
Esta arquitectura garantiza confiabilidad. Los mensajes no se procesan directamente al ser recibidos, sino a través de una cola interna, lo que permite realizar reintentos y evitar la pérdida de mensajes en caso de fallos.
Configuración del consumo de Kafka en Bizagi Studio
Para definir qué debe escuchar Bizagi y cómo debe reaccionar, es necesario configurar Kafka en Bizagi Studio.
Esta configuración incluye:
•La conexión a Kafka
•Los topics que Bizagi monitoreará
•Las acciones que se ejecutarán para cada topic
Acceso a la configuración
Comience navegando a la configuración de Kafka en Bizagi Studio.
1.En Bizagi Studio, vaya a la vista Experto
2.Abra el módulo Sistemas Externos
3.Expanda el nodo Eventos de Streaming
4.Seleccione Kafka
5.Haga clic derecho sobre Kafka y seleccione Nueva Configuración Kafka. También puede usar la misma opción desde la barra superior
Esto abre la ventana Conector Apache Kafka, donde puede definir tanto la conexión como los topics.
Configuración de la conexión
Antes de que Bizagi pueda escuchar eventos, debe establecer una conexión con el broker de Kafka.
En la ventana Conector Apache Kafka, defina lo siguiente:
•Nombre conexión: Un nombre para identificar la configuración
•Descripción: Una breve descripción de la conexión
•Ambiente: Seleccione el ambiente donde se aplicará la configuración: Desarrollo, Pruebas o Producción
Luego configure los parámetros de conexión:
1.Seleccione la opción Server (Outbound).
2.Bootstrap Servers (Broker List): Ingrese la dirección del broker de Kafka. Ejemplo: kafka.example.com:9092
3.Protocolo de seguridad: Seleccione cómo Bizagi se conectará a Kafka. Las opciones soportadas incluyen: SASL_PLAINTEXT, SASL_SSL y PLAINTEXT
4.Proporcione las credenciales requeridas según el protocolo seleccionado
Una vez configurado, haga clic en Probar conexión para verificar que Bizagi puede conectarse correctamente a Kafka.
Definición de topics y acciones
Después de configurar la conexión, cambie a la opción Consumer (Inbound). Aquí es donde define los topics que Bizagi monitoreará y cómo se procesará cada mensaje.
Cada fila representa una suscripción a un topic. Para cada una, debe configurar todos los campos necesarios para definir el origen del evento y la acción que Bizagi ejecutará.
•Habilitado: Active esta opción para habilitar el topic. Si no está habilitado, Bizagi ignorará los mensajes sin eliminar la configuración.
•Topic de Kafka: Ingrese el nombre exacto del topic. Bizagi no descubre los topics automáticamente, por lo que usted debe conocer el nombre previamente y asegurarse de que coincida exactamente con el definido en Kafka.
•Acción de Bizagi: Seleccione la acción que Bizagi ejecutará cuando se reciba un mensaje. Las opciones disponibles son: Crear Caso y Nuevo registro en entidad. Esta selección determina el resto de la configuración.
•Proceso o entidad objetivo: Este campo depende de la acción seleccionada:
oSi selecciona Crear Caso, elija el proceso que se ejecutará cuando se reciba un mensaje. Bizagi solo permitirá la creación del caso utilizando atributos que estén disponibles en la Forma de Inicio. Si los atributos requeridos no están en la Forma de Inicio, la creación del caso fallará.
oSi selecciona Nuevo registro en entidad, elija la entidad donde se almacenará el mensaje. En este escenario, solo las entidades Maestras están disponibles.
•Mapear mensaje en atributo: Seleccione el atributo donde se almacenará el mensaje de Kafka.
oPara Crear Caso, debe seleccionar un atributo del proceso que esté disponible en la Forma de Inicio.
oPara Nuevo registro en entidad, debe seleccionar un atributo de la entidad Maestra.
|
En ambos casos, solo están disponibles atributos de tipo String o Texto Extendido, ya que el mensaje se recibe como un único valor y se almacena directamente sin transformación. |
•Consumer Group ID: Defina el identificador que Bizagi utilizará como consumidor de Kafka.
Este valor permite que Kafka reconozca a Bizagi como suscriptor y también permite configurar el mismo topic múltiples veces con diferentes comportamientos.
Por ejemplo, puede usar diferentes Consumer Group ID para:
oActivar distintos procesos a partir del mismo topic
oAlmacenar el mismo mensaje en diferentes
|
Al definir los topics, tenga en cuenta que Bizagi valida cada configuración para evitar duplicados. Si intenta crear una configuración con la misma combinación de Nombre de topic, Acción de Bizagi y Consumer Group ID, el sistema mostrará el mensaje: Ya existe un topic con la misma configuración en este ambiente.
|
Deployment de la configuración configuration
Una vez completada la configuración, debe hacer deployment de la solución al ambiente de destino.
El deployment incluye:
•La conexión a Kafka
•Los topics definidos
•Las acciones configuradas
Cualquier cambio estructural, como la creación de nuevos topics o la modificación de acciones, requiere actualizar la configuración en Bizagi Studio y hacer deployment nuevamente.
Comportamiento por ambiente
El consumo de Kafka se comporta de manera diferente según el ambiente. Comprender esta diferencia le permite gestionar correctamente la configuración al pasar de Desarrollo a Pruebas y Producción.
Desarrollo
En Desarrollo, toda la configuración se realiza directamente en Bizagi Studio.
Usted define la conexión, los topics y las acciones como parte del modelo. Este ambiente está enfocado en diseñar y validar cómo Bizagi debe responder a los eventos entrantes.
No existe una interfaz en Management Console para controlar configuraciones de Kafka en este ambiente.
Pruebas y Producción
En Pruebas y Producción, la Management Console proporciona control operativo sobre la configuración a la que se le hizo deployment desde Bizagi Studio.
Para revisar las configuraciones de Kafka:
1.Abra la Management Console
2.Navegue a Conectar
3.Seleccione Eventos de Streaming
En esta sección, puede revisar la configuración a la que se le hizo deployment y controlar si cada topic está activo.
Desde aquí, puede habilitar o deshabilitar topics sin necesidad de realizar un nuevo deployment. Esto le permite detener o reanudar temporalmente el consumo de mensajes según sea necesario.
Sin embargo, esta interfaz está limitada al control en ejecución y no permite modificar cómo está definida la integración. Cualquier cambio que altere el significado de la configuración, es decir, cómo se interpreta un mensaje o qué acción se ejecuta, debe realizarse en Bizagi Studio y luego hacer un deployment nuevamente.
Trabajo con brokers compartidos
Si múltiples ambientes se conectan al mismo broker de Kafka, es necesario controlar cuidadosamente qué ambiente está consumiendo mensajes activamente.
Kafka asigna los mensajes a los consumidores cuando estos los leen. Como resultado, el primer ambiente activo puede procesar un mensaje antes que los demás.
Para evitar comportamientos no deseados:
•Deshabilite los topics en ambientes que no están en uso
•O configure brokers distintos para cada ambiente
Esto es especialmente importante cuando se promueven configuraciones entre ambientes.
Comportamiento en ejecución
Una vez se ha hecho deployment la configuración y habilitado un topic, Bizagi comienza a escuchar automáticamente.
El Scheduler no está involucrado. Los mensajes se procesan tan pronto como llegan.
Bizagi utiliza un modelo de entrega de al menos una vez, lo que significa que los mensajes pueden reintentarse en ciertos escenarios, pero no se pierden.
Para garantizar esto:
•Los mensajes se procesan a través de una cola interna antes de su ejecución
•Los offsets se confirman solo después de un procesamiento exitoso
Esto asegura confiabilidad incluso ante fallos temporales.
Reintentos y monitoreo
La integración con Kafka incluye mecanismos de reintentos para manejar fallos durante la comunicación o el procesamiento.
Si ocurre un problema:
•Las fallas de conexión generan intentos automáticos de reconexión
•Las fallas al reenviar mensajes generan reintentos con incremento progresivo
•Las fallas en el procesamiento generan reintentos a través de la cola interna
Monitoreo con trazas
Para monitorear la actividad de Kafka, puede utilizar las trazas en la Management Console.
Para configurar las trazas:
1.Abra la Management Console
2.Vaya a Trazas
3.Abra la pestaña Configuración
4.Ubique la categoría Eventos de Streaming
5.Ajuste el nivel de trazas según sea necesario
Para revisar las trazas:
1.Vaya a Trazas
2.Abra la pestaña Visualización
3.Filtre por la categoría Eventos de Streaming
Esto le permite observar cómo se procesan los mensajes e identificar posibles problemas durante la ejecución.
Escenarios típicos
El consumo de Kafka es especialmente útil cuando los procesos deben reaccionar inmediatamente a eventos externos.
Por ejemplo:
•Un sistema de detección de fraude publica transacciones sospechosas y Bizagi inicia casos automáticamente
•Sistemas externos envían actualizaciones que Bizagi almacena y procesa
•Dispositivos generan señales en tiempo real que activan flujos de trabajo
En estos escenarios, Bizagi actúa como una capa reactiva que transforma eventos entrantes en acciones de negocio estructuradas.
Configuración del ambiente
Dado que acciones como Crear caso y Nuevo registro en entidad se realizan mediante OData, debe configurar una aplicación OAuth 2.0 en el Portal de Trabajo.
Abra el Portal de Trabajo con un usuario que tenga acceso al menú Admin y a la sección Seguridad, y luego abra Aplicaciones OAuth 2.
Agregue una nueva aplicación con las siguientes características:
•Nombre: Registre el siguiente nombre:
bz:oauth:2.0:odata:activators:functions
|
|---|
El nombre de la aplicación debe configurarse exactamente como se muestra arriba. |
•Tipo de concesión: Credenciales del cliente
•Sitio web: Puede incluir la URL del Portal de Trabajo o dejarla en blanco.
•Alcance permitido: API.
•Nombre de usuario: Seleccione un usuario con los permisos mínimos requeridos para las operaciones de Kafka. Este usuario no necesita ser administrador. Para mayor seguridad, recomendamos crear una cuenta de servicio dedicada (por ejemplo, kafka-consumer). Este usuario debe tener:
oAcceso de inicio únicamente a los procesos iniciados por Kafka.
oPermiso para autenticarse con la OData API.
El usuario no debe tener privilegios administrativos ni acceso global a todos los procesos.
•Duración del token: Defina la duración del token de acceso utilizado por Kafka. Por seguridad, configure una duración corta, típicamente entre 2 y 5 minutos. Cada operación solicita un token nuevo de un solo uso. Evite usar 0 (sin expiración), ya que cualquier token previamente generado permanecería válido si las credenciales fueran comprometidas.
•Tipo de ciclo de vida: Absoluto.
•Descripción: Descripción opcional para su aplicación.
Una vez configurada la aplicación OAuth, Bizagi puede autenticarse y ejecutar las acciones asociadas a los mensajes de Kafka mediante OData.
Last Updated 22/07/2026 4:04:47 p. m.