Business Events: Payload personalizado (I)

El propósito de este artículo es hablar sobre la posibilidad de cambiar el formato o la estructura del JSON que enviamos a través de un Business Event de la forma menos intrusiva y más reusable posible, permitiendo en todo momento utilizar la potencia y la robustez del framework de Business Events.

Actualmente estoy participando en un proyecto con una gran cantidad de integraciones entre distintas herramientas. En este proyecto se ha decidido utilizar una Cola de Azure Service Bus para gestionar los distintos eventos que todas y cada una de las herramientas va generando. Debido a esta gran cantidad de herramientas y plataformas, se tuvo que homogeneizar el formato de los mensajes que son enviados por cada una de ellas, de modo que el tratamiento de los mismos sea lo más sencillo posible, y que se puedan tomar distintas decisiones basándose más en el contenido del mensaje y no tanto en la estructura del mismo.

Por regla general, el formato del payload de un Business Event viene dado por la clase BusinessEventsContract, y nosotros podemos añadir nuevos atributos por medio de herencia, tal y como podéis ver en este artículo. Una vez que serializamos el contrato de datos, obtenemos un JSON con una estructura similar a la siguiente:

Mientras que el formato del JSON para este proyecto, debía ser algo así:

Como podéis comprobar, se trata de generar una cabecera que permitirá diferenciar el tipo de evento que se está generando a través de «EventType», y envolver el contenido original de nuestro contrato de datos dentro del atributo «Data». Debido a esta necesidad, y asumiendo que esta estructura no se podía conseguir siguiendo los «pasos oficiales» para generar un Business Event personalizado, nos planteamos las siguientes opciones:

  • Generar un desarrollo desde cero para realizar la conexión con la cola de Azure Service Bus y enviar los mensajes con el formato que queramos.
  • Tratar de modificar el formato del JSON enviado a través de los Business Events sin romper la funcionalidad out of the box.

Obviamente, la solución elegida fue la segunda, por varios motivos:

  • El framework de Business Events gestiona, de forma estándar, la conexión con todos los extremos, y la configuración que tenemos que realizar para utilizarlos es muy sencilla.
  • El framework de Business Events tiene una gestión de errores integrada.
  • El framework de Business Events reintenta el envío de mensajes en caso de error.
  • Es mucho más divertido tratar de solventar este problema que generar la conexión de cero.
  • En caso de problemas en la conexión, envío de mensajes, etc… contamos con el equipo de soporte de Microsoft

Ahora que nos hemos decidido por la segunda opción, toca diseñar una solución que sea poco intrusiva, que nos asegure que va a continuar funcionando tras las continuas actualizaciones de aplicación y plataforma, y que sea reutilizable, de forma que resulte muy sencillo generar nuevos eventos de negocio que se adapten a ella.

Para ello, y debido al funcionamiento del framework de Business Events, diseñamos una solución dividida en dos partes:

1. Identificar los eventos que deben cumplir con el nuevo formato.

Esta identificación se realizará en el momento en que generamos el catálogo de eventos, es decir, cuando el sistema recorre los distintos eventos de negocio existentes y crea un registro por cada uno de ellos en la tabla BusinessEventsTable.

2. Modificar el payload a enviar al exterior.

El envío de eventos de negocio a los distintos extremos se realiza en dos pasos. En primer lugar (de forma muy resumida) se crea un registro en la tabla BusinessEventsCommitLog en el momento en que activamos el envío del evento de negocio (llamamos al método send()). En esta tabla se identifica el tipo de evento así como su contenido y para poder insertar el registro,S el contrato de datos tiene que cumplir con el formato definido por la clase BusinessEventsContract, por lo que el payload no puede ser modificado hasta que no llegamos a este punto. Posteriormente, hay un proceso batch que lee los registros de esta tabla y los envía al exterior.

Resumiendo, la idea es modificar el contenido del JSON justo antes de almacenarlo en esta tabla, dejando que el resto del proceso sea llevado a cabo de forma totalmente estándar.

Con esto, creo que ya podemos hacernos una idea de como será la solución llevada a cabo para cumplir con este objetivo. En el próximo artículo veremos el detalle técnico de la misma con los elementos que tenemos que crear y extender para llevarlo a cabo.

Esta es una solución de la que me siento bastante orgulloso (aunque seguramente sea más que mejorable) ya que, como veremos, una vez desarrollado, podemos generar tantos eventos de negocio como necesitemos de forma muy sencilla para que cumplan con el formato personalizado para este proyecto.

6 comments / Add your comment below

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información. ACEPTAR

Aviso de cookies