Hay ítems en Fabric que no siempre utilizamos y pueden fortalecer escenarios. En este caso hablo de API for GraphQL.
En el siguiente artículo invitamos a Nazarena a contarnos de un requisito para disponibilizar datos de un Lakehouse de Fabric mediante API REST que fue satisfactorio gracias al ítem en cuestión.
Para comenzar voy a poner en contexto el requerimiento que guía el artículo.
Implementar un mecanismo de consulta a los datos mediante una API del tipo REST, accediendo de forma segura, pero sin darle acceso directo al Lake, al SQL Endpoint ni al workspace.
La necesidad era bastante concreta: exponer información y devolver un JSON entendible para otro sistema.
Para evaluar la viabilidad aplicamos una prueba sobre la arquitectura medallón ya desarrollada, al igual que en el caso del cliente, sumándole una API for GraphQL de Fabric y una Azure Function como capa intermedia. La Function recibe una llamada, consulta Fabric con identidad administrada y devuelve la información requerida.
El objetivo era que el sistema externo accediera solamente a un endpoint.
La arquitectura a continuación permite visualizar el flujo que vamos a implementar.
Para el caso, vamos a tomar como referencia datos disponibles de una demo, donde el objetivo será exponer únicamente las operaciones de Venta de Exportaciones. Los datos se obtienen de la tabla de hechos fact_operaciones, ubicada dentro de la capa Gold y contiene las operaciones de ventas.
API for GraphQL en Fabric
Como primer paso, creamos el ítem API for GraphQL en el workspace de Fabric y lo conectamos al Lakehouse Gold. Pero antes de seguir voy a sumar la definición como les gusta hacer aquí en LaDataWeb:
API for GraphQL es un ítem de Fabric que permite crear una capa de acceso sobre los datos de Fabric, exponiendo los campos y fuentes que se necesiten consultar.
Paso posterior podremos definir en que datos trabajar.
Desde el editor de API for GraphQL podemos probar consultas directamente sobre las fuentes expuestas por la API. Desde ahí se puede validar el esquema disponible, aplicar filtros, trabajar con variables y ejecutar agregaciones antes de implementarlo.
En este caso lo utilizamos para probar la consulta sobre fact_operaciones y asegurar que los filtros y agrupaciones funcionaran antes de incorporarlos en la Azure Function.
Una vez validada la consulta en Fabric, con los datos y resultados correctos, copiamos el endpoint del ítem para utilizarlo luego en la Function.
Azure Function
Con GraphQL funcionando, nos queda resolver cómo exponer esos datos de una forma simple hacia un sistema externo.
Se podría consumir GraphQL directamente, pero eso implicaría el acceso al modelo de Fabric y su entorno. Por eso utilizamos Azure Function como una capa intermedia que recibe los parámetros, consulta GraphQL y devuelve un JSON como el requerimiento lo solicitaba.
Para este caso, al igual que en el artículo de La Data Web donde usamos Azure Functions como puente entre Fabric y una API externa, volvemos a usar la Function como una capa intermedia.
La diferencia es que ahora el flujo va en sentido contrario, el sistema externo consulta la Azure Function, esta se conecta a la API for GraphQL de Fabric y devuelve la información en un JSON simple de consumir.
El endpoint final que se expone es el siguiente:
GET /api/exportaciones/resumen
NOTA: Para la prueba se utilizó una Function App en Flex Consumption de manera de contar con un esquema flexible y de pago por uso.
Configuración del endpoint de Fabric
En la Function App se agregó una variable de entorno con el nombre FABRIC_GRAPHQL_ENDPOINT, donde guardamos la URL copiada desde el ítem GraphQL.
De esta forma el endpoint no queda escrito dentro del código y puede ser cambiado sin modificar la lógica de la Function.
*FABRIC_GRAPHQL_ENDPOINT =
Managed Identity
Un punto que hay que resolver antes de poder implementar la solución completa es la autenticación contra Fabric.
La autenticación podría resolverse mediante una app registration, con Client ID y Client Secret, pero para el caso implementado y para evitar la creación de secretos, se habilitó una identidad administrada del sistema directamente en la Function App.
Function App > Identity > System assigned > On
Con esto Azure le asigna una identidad propia al recurso. En el código se utiliza DefaultAzureCredential, por lo que cuando corre en Azure toma automáticamente esa identidad y solicita un token para Fabric.
from azure.identity import DefaultAzureCredential
credential = DefaultAzureCredential()
token = credential.get_token("https://api.fabric.microsoft.com/.default").token
Dar permiso a esa identidad dentro de Fabric
Con habilitar la identidad en Azure no alcanza. Fabric también tiene que reconocerla y autorizarla.
En este caso agregamos la identidad de la Function App directamente al workspace de Fabric con rol Contributor. De esta forma, la identidad obtiene acceso a los ítems del workspace, incluida la API for GraphQL y la fuente de datos utilizada por la consulta.
También se podría dar acceso de forma más granular directamente sobre el ítem GraphQL, asignando únicamente el permiso necesario para ejecutar consultas.
Es importante tener en cuenta la configuración del tenant. Dependiendo de las políticas de la organización, el uso de service principals o identidades administradas puede requerir ciertas configuraciones y habilitación en el Admin Portal por parte del administrador.
Del resultado GraphQL a un JSON de negocio
La Function no devuelve la respuesta de GraphQL tal cual viene.
Fabric devuelve los grupos y agregaciones. La Function toma esa información, calcula el precio promedio como facturación dividida por toneladas y arma una estructura más cómoda para consumir: totales, campaña, cultivo y destinos.
La consulta GraphQL procesa los datos, filtra las operaciones, aplica el rango de fechas y agrupa la información. Sobre esos grupos calcula directamente en Fabric métricas como facturación total, toneladas y cantidad de operaciones.
A partir de esa respuesta, la Azure Function termina de darle forma al resultado, calcula el precio promedio como facturación / toneladas y arma una estructura para consumir desde afuera: totales generales, campañas, cultivos y destinos.
GraphQL: filtra, agrupa y agrega los datos directamente en Fabric.
Azure Function: calcula la métrica derivada y transforma la respuesta en un JSON más simple para el consumidor.
El resultado que se obtiene al hacer la llamada es:
¿Y cómo se protege el endpoint externo?
Para la prueba se configuró la Function con AuthLevel.FUNCTION. Esto obliga a enviar una Function Key para poder ejecutar el endpoint.
La clave es que esa Function Key solo controla el acceso al endpoint de la Function. La conexión entre la Function y Fabric se autentica por separado, usando Entra ID y Managed Identity.
https://[function-app].azurewebsites.net/api/exportaciones/resumen?code=[function-key]
Conclusión
La prueba permitió validar la posibilidad de mantener el dato dentro de Microsoft Fabric y exponer hacia afuera solamente la información que necesita otra aplicación.
- El Lakehouse sigue siendo interno.
- GraphQL se ocupa de consultar y agregar.
- La Azure Function define lo que se disponibiliza.
- Y la autenticación entre servicios queda resuelta con una identidad administrada.
Escrito por