Cómo implementar el SQL analytics endpoint en Fabric | Acadevor
·8 min de lectura
Cómo implementar el endpoint de análisis SQL paso a paso en Fabric
Guía práctica para implementar el SQL analytics endpoint en Microsoft Fabric y devolver datos operativos escritos al análisis sin exponer tokens de escritura.
Respuesta corta: El SQL analytics endpoint es la ruta de retorno analítico que expone, en modo solo lectura y con lenguaje T-SQL, los datos que tu equipo escribió en una capa operativa como SQL Database en Fabric. Se implementa en cuatro pasos: definir la capa escribible, escribir mediante una función gobernada, consultar por el endpoint y devolver el resultado a Power BI o Excel. Nunca expone tokens de escritura en la interfaz de análisis.
Qué resuelve el SQL analytics endpoint
Power BI y el modelo semántico son excelentes para leer, explicar y gobernar métricas. El problema aparece cuando el flujo necesita que el usuario actúe: fijar objetivos, clasificar registros, dejar notas ejecutivas o registrar aprobaciones. Esa escritura no puede vivir en el informe. Necesita una capa preparada para operar, con permisos y auditoría.
Una vez que esos datos existen en una base operativa, hay que devolverlos al análisis. Ahí entra el SQL analytics endpoint: una superficie de consulta que permite leer con T-SQL lo que se escribió, sin duplicar los cálculos oficiales del modelo semántico y sin abrir un canal de escritura en la capa de lectura.
En el método Acadevor esto es coherencia de única verdad: el modelo semántico sigue siendo el contrato de las métricas, y la capa operativa solo aporta los estados, objetivos y decisiones que no nacen en la fuente.
Los cuatro roles de la arquitectura escribible
Antes de tocar la interfaz conviene separar responsabilidades. La acción sobre datos gobernados se sostiene sobre cuatro roles claros:
la experiencia consulta medidas y dimensiones del modelo semántico. Los cálculos oficiales no se duplican en la aplicación.
Demo gratuita
Mira cómo construir tu sistema de datos e IA
Un recorrido práctico de principio a fin para unificar fuentes dispersas en un modelo semántico que alimenta Excel, Power BI, Copilot y tus agentes.
Lógica de negocio: User Data Functions aloja Python sin servidor reutilizable y lo expone a Fabric o a aplicaciones externas mediante endpoints autenticados.
Almacenamiento operativo: SQL Database, Cosmos DB u otra base transaccional guarda estados, objetivos y aprobaciones con permisos y auditoría.
Retorno analítico: los datos escritos regresan a Power BI, Excel o agentes mediante Direct Lake, el SQL analytics endpoint, una actualización o una API.
El SQL analytics endpoint es una de las cuatro rutas de retorno, y suele ser la más directa cuando ya trabajas con SQL Database en Fabric.
Paso a paso para implementar el endpoint de análisis SQL
Los pasos siguen el ciclo completo de acción y escritura, desde que se define la tabla operativa hasta que el dato vuelve al análisis.
Define la capa escribible. Crea la base operativa (por ejemplo SQL Database en Fabric) con las tablas que guardarán la acción. Para un caso de objetivos, la tabla debe guardar la métrica, el equipo, el escenario, el tipo de período, el período, el valor, la moneda, el estado, el responsable y la auditoría. Define una clave lógica que evite duplicados por período y escenario.
Escribe mediante una función gobernada. No escribas desde el navegador ni desde el informe. Una User Data Function o un backend seguro valida la entrada y ejecuta la escritura. Esto centraliza identidad, idempotencia, manejo de errores y registros en un solo lugar reutilizable.
Consulta por el SQL analytics endpoint. Una vez persistidos los datos, el endpoint expone las tablas en modo solo lectura con T-SQL. Aquí lees estados y objetivos actuales para alimentar el análisis, sin abrir ningún canal de escritura sobre esta superficie.
Devuelve el resultado al análisis. Conecta el endpoint a Power BI o a Excel para que dirección vea los objetivos y estados junto a las métricas del modelo semántico. Usa Direct Lake solo si el modelo y las fuentes fueron diseñados para ese modo.
Objetivos y Scorecards como patrón de referencia
El caso más común para justificar un SQL analytics endpoint es una tabla de objetivos que dirección compara contra los resultados reales.
La mecánica es directa: la tabla de objetivos guarda métrica, equipo, escenario, período, valor, moneda, estado, responsable y auditoría. La clave lógica evita duplicados por período y escenario. Una User Data Function o un backend seguro valida y escribe cada objetivo. El endpoint devuelve esos objetivos al análisis para leerlos junto a las métricas oficiales.
Si además necesitas sincronizar un Scorecard de Power BI, las llamadas a Power BI REST se ejecutan fuera del navegador y se prueban como una integración independiente. No mezcles esa sincronización con la lógica de escritura de la base operativa.
Cómo elegir entre las rutas de escritura disponibles
El SQL analytics endpoint no es la única forma de cerrar el ciclo. La ruta correcta depende de dónde vive la experiencia y de qué garantías necesitas.
Ruta
Cuándo encaja
Límite que se documenta
Fabric App y Data API
La empresa necesita una experiencia propia que consulta y modifica datos dentro de una aplicación Fabric
Estado de la versión preliminar, región, autenticación y modelo de permisos
User Data Functions
La misma regla debe invocarse desde Pipelines, Notebooks, Activator, Power BI o una aplicación por REST
Identidad, conexiones, idempotencia, errores y librerías del entorno de Python
Flujo transaccional y analítico
Un informe necesita ejecutar una acción acotada y escribir sobre SQL Database o Cosmos DB
La capacidad continúa en versión preliminar. Se validan región, tenant, latencia y auditoría
Backend externo
El caso exige autenticación propia, transacciones complejas o integración fuera de Fabric
Contrato API, secretos, observabilidad y sincronización con la capa analítica
El SQL analytics endpoint suele acompañar al flujo transaccional y analítico: escribes con una función sobre SQL Database y lees el resultado por el endpoint.
Qué documentar antes de pasar a producción
Varias de estas capacidades continúan en versión preliminar. Antes de confiar el flujo a un proceso real, deja por escrito y validado:
La región y el tenant donde corre la capacidad.
La latencia esperada del ciclo escritura y lectura.
La auditoría de quién escribió qué y cuándo.
Una alternativa para producción si la versión preliminar cambia.
La confirmación de que no hay tokens de escritura expuestos en la interfaz de análisis.
Esta disciplina es parte de tratar la solución como un sistema vivo: todo cambio importante debe poder probarse, aprobarse y revertirse.
Siguiente paso
Implementar bien el SQL analytics endpoint depende menos del código y más del criterio: separar lectura de escritura, mantener el modelo semántico como contrato y documentar los límites de cada versión preliminar. Si quieres construir este tipo de soluciones con autonomía, sin depender de un desarrollador, puedes aprenderlo paso a paso en la Comunidad Educativa. Si prefieres evaluar primero la preparación de tu empresa para este tipo de arquitectura, revisa la consultoría para empresas.
Preguntas frecuentes
¿Qué es el SQL analytics endpoint en Microsoft Fabric?
Es una superficie de consulta en modo solo lectura que expone con T-SQL los datos escritos en una capa operativa como SQL Database en Fabric. Sirve para devolver al análisis los estados, objetivos y aprobaciones que tu equipo registró, sin duplicar los cálculos del modelo semántico y sin abrir un canal de escritura.
¿Por qué no escribir datos directamente desde el informe de Power BI?
Porque la interfaz de análisis no debe exponer tokens de escritura. La escritura debe pasar por una capa gobernada, como una User Data Function o un backend seguro, que valide la entrada y controle identidad, idempotencia, errores y auditoría en un solo lugar reutilizable.
¿Cuándo conviene el SQL analytics endpoint frente a Direct Lake?
El SQL analytics endpoint es la opción directa cuando ya trabajas con SQL Database en Fabric y quieres leer los datos operativos con T-SQL. Direct Lake solo conviene si el modelo y las fuentes fueron diseñados específicamente para ese modo.
¿Qué campos debe guardar una tabla de objetivos para este patrón?
Debe guardar la métrica, el equipo, el escenario, el tipo de período, el período, el valor, la moneda, el estado, el responsable y la auditoría. Una clave lógica evita duplicados por período y escenario.
¿Qué debo validar antes de llevar este flujo a producción?
Varias capacidades continúan en versión preliminar, así que conviene documentar la región, el tenant, la latencia del ciclo, la auditoría y una alternativa para producción, además de confirmar que no hay tokens de escritura expuestos en la interfaz de análisis.
