API Management: arquitectura de integración

¡Estoy de vuelta con información adicional sobre Azure API Management! Más contenido de Azure, y probablemente seguiré escribiendo más posts relacionados con Azure en el futuro.

Creo que hay muchas formas de aprender cosas nuevas, y para mí, dos de ellas son escribir artículos en el blog y utilizar nuevas tecnologías para resolver problemas en el trabajo. Por supuesto, mi objetivo es intentar aplicar los temas de Azure sobre los que escribo a Dynamics 365.

Hoy voy a presentar un enfoque de arquitectura para las integraciones, aprovechando el API Management y otros componentes de Azure, para Dynamics 365 o cualquier otra cosa que tenga un endpoint.

Puedes leer la segunda parte de este post en IaC con Bicep: despliega la arquitectura de Azure API Management.

La arquitectura con APIM

Vamos a ponernos manos a la obra. Déja que te muestre un diagrama de lo que tengo en mente, y luego te lo explicaré todo con más detalle:

Mi idea es tener un API Management delante de Dynamics 365 Finance and Operations, o lo que sea que estés usando, y registrar todas las peticiones hechas al APIM y las respuestas devueltas por el APIM en un Event Hub como JSON.

Veamos los componentes individuales.

Azure API Management

Este será el endpoint de la API de cara al público que se conectará a nuestro backend real, que en el caso del diagrama es Dynamics 365 F&O.

Una de las ventajas de la APIM es que podemos gestionar el flujo de autenticación OAuth en Dynamics 365 y, por ejemplo, utilizar una clave de API en su lugar.

Además, podemos mockear APIs, modificar las peticiones y respuestas antes de que lleguen y salgan del backend, y definir varias otras reglas en las políticas.

Event Hub

El Event Hub es un servicio de ingestión de eventos, y lo utilizaremos para registrar las peticiones y respuestas de la API Management.

Estoy usando un Event Hub porque… no he sido capaz de conseguir las solicitudes y respuestas de APIM en un workspace de Log Analytics de otra manera.

Log Analytics

Log Analytics es una herramienta que utilizaremos para recoger los datos del Event Hub y analizar sus resultados.

Application Insights

Y, obviamente, App Insights es el siguiente componente. Está conectado al APIM y recogerá datos sobre el rendimiento del APIM, y también podemos utilizarlo para consultar los registros de Log Analytics.

Logic App

Debido a que el Event Hub no está destinado a la visualización de los datos, vamos a utilizar una Logic App para obtener los registros del centro de eventos en Log Analytics.

Pero todo esto… ¿para qué?

¡¡¡Sólo quiero que todos GASTÉIS MÁS DINERO EN AZURE!!!

El Sr. Burns regocijándose ante la idea de más gasto de Azure

Es broma, y como veremos más adelante, el coste mensual de todos los recursos será muy bajo.

Ya hablé antes de APIM y dije que me parecía una buena idea poner un APIM frente a nuestros endpoints de Dynamics 365 porque nos da varias funcionalidades que pueden ser realmente útiles.

Y antes de entrar en más detalles, un pequeño…

Este tipo de cosas, añadir una capa extra delante de una instancia de Dynamics 365, o de cualquier sistema, tiene que estar justificado. Si no tienes muchas integraciones, o no son críticas, esto puede no tener sentido. Usar esto o no depende de ti y de los requerimientos del proyecto.

En serio, ¿para qué?

La razón detrás de que haya montado esto es tener control y datos del uso de nuestras APIs, capturando las solicitudes hechas al sistema y las respuestas que devuelve.

Y en un escenario con muchas integraciones y varios sistemas externos que acceden a los datos del ERP, es una buena idea tener un registro de lo que está pasando. Y es incluso una mejor idea mantenerlo fuera de Dynamics 365 🙂

La API

Para demostrarlo, he creado una API de una calculadora utilizando una función de Azure, y el APIM será el frontend de esa API.

En el APIM he creado una política para usar el Event Hub como logger:

<policies>
    <inbound>
        <base />
        <log-to-eventhub logger-id="aristedotinfoapim-logger">@{
            if (context.Request != null)
            {
                var bodyRequest =  context.Request.Body.As<string>(preserveContent: true);
                
                var ret = string.Format("{{'Direction' : '{0}', 'DateTime' : '{1}', 'ServiceName' : '{2}', 'RequestId' : '{3}', 'IpAddress' : '{4}', 'OperationName' : '{5}', 'Body' : '{6}' }}", "Inbound", DateTime.UtcNow, context.Deployment.ServiceName, context.RequestId, context.Request.IpAddress, context.Operation.Name, bodyRequest);
                return ret;
            }
            else
            {
                return "INBOUND EMPTY";
            }
        }</log-to-eventhub>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
        <log-to-eventhub logger-id="aristedotinfoapim-logger">@{
            if (context.Request != null)
            {
                var bodyResponse =  context.Response.Body.As<string>(preserveContent: true);
                
                var ret = string.Format("{{'Direction' : '{0}', 'DateTime' : '{1}', 'ServiceName' : '{2}', 'RequestId' : '{3}', 'IpAddress' : '{4}', 'OperationName' : '{5}', 'Body' : '{6}' }}", "Outbound", DateTime.UtcNow, context.Deployment.ServiceName, context.RequestId, context.Request.IpAddress, context.Operation.Name, bodyResponse);
                return ret;
            }
            else
            {
                return "Outbound EMPTY";
            }
        }</log-to-eventhub>
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

La propiedad logger-id contiene el nombre de un logger que vamos a crear en el APIM. Podemos hacer esto usando la API REST de gestión de Azure o PowerShell. Yo he optado por este último:

$apimContext = New-AzApiManagementContext -ResourceGroupName "YOUR_RESOURCE_GROUP" -ServiceName "YOUR_APIM_NAME"
New-AzApiManagementLogger -Context $apimContext -LoggerId "YOUR_NEW_LOGGER_NAME" -Name "YOUR_NEW_LOGGER_NAME" -ConnectionString "YOUR_EVENTHUB_CONN_STRING;EntityPath=YOUR_NEW_LOGGER_NAME"

Con el script anterior, sustituyendo las cosas en LETRAS_MAYUSCULAS tendrás un nuevo logger listo.

Y en la policy lo que vamos a hacer es guardar la petición y la respuesta en formato JSON junto con otros datos, como la fecha y la hora, la IP desde donde se hace la llamada, el nombre del endpoint, etc.

Y ahora, usando Postman, podemos llamar a nuestra API. Voy a llamar a la operación «add»:

Llamando a la operación add desde Postman

Bien, 9 más 4 son 13. Parece que la API funciona.

Logging (de la forma no-tan-óptima)

Ahora estamos en la parte de los logs. Cuando se llama a cualquiera de las operaciones de APIM se registran en el Event Hub, y gracias a una Logic App obtendremos estos eventos en Log Analytics, y luego podemos recuperar los datos utilizando Log Analytics o App Insights.

Lo haré en Log Analytics, y después de unos minutos veremos un nuevo log personalizado:

Y, tras unos minutos después de hacer las peticiones, veremos lo que hemos enviado allí:

Y ahora tenemos los detalles de quién, cuándo, qué endpoint y qué se está enviando y la respuesta que devuelve el backend. Y si hay problemas, al menos podemos ver qué body se envió, qué error devolvió el backend, etc.

Logging (como tiene que ser)

Y bien, hay otros beneficios en compartir cosas, siempre hay alguien que sabe más que tú y te puede ayudar. En este caso Fabio Filardi (y Mötz Jensen me indicó el camino en la misma dirección), mandándome este post sobre una característica de API Management que permite mandar los cuerpos de las peticiones y respuestas directamente a App Insights.

Lo mejor de todo es que ya lo había probado y no conseguí que funcionara, asi que muchas gracias a Fabio por hacérmelo intentar de nuevo incluso cuando le dije que ya lo había probado 😅!

Si vamos a la pestaña «Settings» de nuestra API y navegamos al final de las opciones y hacemos clic en «Advanced settings» veremos esto:

Para conseguir que la APIM loguee los cuerpos de las peticiones y respuestas, tenemos que cambiar algunos valores por defecto.

Primero tenemos que cambiar el «correlation protocol» a W3C, y después marcar las checkboxes en Additional settings y poner 8192 en el campo «Number of payload bytes to log».

Cuando guardemos esto, podemos mandar una petición a nuestra API y, pasados unos minutos, podemos ir a Application Insights, Logs y seleccionar las requests ordenadas por la hora para mayor comodidad con esta query:

requests
| order by timestamp

Veremos una lista de peticiones, la de arriba es la que se hace a la función de Azure (que en este caso es nuestro backend) y la de debajo es la que se hace al APIM. La expandimos y veremos los cuerpos:

Request and responses bodies — Cuerpos de peticiones y respuestas

Y gracias a marcar cuatro checkboxes, nos podemos ahorrar el coste del Event Hub y la Logic App!

Los recursos en Azure

Y esto es posible gracias a Azure y a estos recursos:

Recursos de Azure para la arquitectura de APIM

Y como dije al principio, el coste de todo esto no va a ser muy alto. Vayamos a la calculadora de precios de Azure y comprobémoslo.

Y, aunque falten los recursos de App Insights y Log Analytics, que no están en la calculadora, el coste mensual en euros y para la región de West Europe es de 22,67 euros, lo que debería ser perfectamente justificable en un proyecto de implantación de ERP.

UPDATE: si usáis la solución de logueo buena, sin Event Hub ni Logic App, el precio baja hasta 11.67 euros.

Este precio puede subir dependiendo de los recursos consumidos, pero he hecho los números usando los niveles básicos para todo, y puedes ver que los elementos más caros son el Event Hub y el almacenamiento, a los que he asignado los valores por defecto de la calculadora.

¿Y cómo despliego todo esto?

Es una buena pregunta, porque acabo de explicar lo que hay en la solución que propongo y he mostrado más o menos cómo funciona y cómo puede ayudarnos.

Pero desplegar todo esto a mano cada vez que lo necesitamos puede llevar mucho tiempo. Y en el próximo post veremos cómo resolver este problema y desplegar todos los recursos con unos pocos clics.