Cómo implementar las Fabric Apps operativas paso a paso

Una Fabric App operativa se implementa por capas separadas: lectura analítica desde el modelo semántico, escritura gobernada hacia una SQL database hija vía la Data API GraphQL, y consumo de solo lectura por el SQL analytics endpoint. Nunca se escribe sobre el modelo semántico y el navegador nunca guarda secretos ni decide permisos. Fabric Apps requiere habilitación del administrador del tenant; conviene revisar su estado de disponibilidad en la documentación oficial antes de planificar.

¿Cuándo conviene una Fabric App en lugar de un informe?

Un informe responde preguntas. Una aplicación permite actuar. La decisión de implementación es simple: si el usuario solo consulta, un informe de Power BI alcanza. Pero cuando el usuario debe cargar datos, aprobar, definir objetivos o recorrer un proceso, una experiencia a medida convierte Fabric en una herramienta de trabajo diario.

Con Fabric Apps y el Rayfin SDK, una organización crea interfaces propias que consultan datos gobernados y escriben datos operativos en una SQL database administrada por Fabric. No todo necesita una aplicación. La regla es honesta: solo cuando hay acción sobre el dato justifica el costo de construir y mantener una capa de aplicación.

Antes de decidir, conviene tener claro el acuerdo del negocio sobre sus métricas. El modelo semántico es donde ese acuerdo queda escrito: primero se ordenan las métricas y las decisiones, después las herramientas. Una Fabric App bien hecha respeta ese contrato en lugar de reinventar cálculos en la interfaz.

¿Qué capas componen una Fabric App operativa?

Una aplicación operativa no es un bloque único. Separa responsabilidades para que la escritura no contamine la lectura y para que las reglas vivan donde corresponde. Estas son las capas del patrón:

• Lectura analítica: la aplicación consulta el modelo semántico con medidas y dimensiones gobernadas. Los valores reales, los formatos y las definiciones salen del modelo, no de cálculos improvisados en la pantalla.
• Escritura: RayfinClient usa la Data API GraphQL generada por Fabric Apps para escribir en la SQL database hija. No se escribe sobre el modelo semántico. La escritura vive en una capa transaccional con permisos definidos en el modelo de datos. Este patrón es una aplicación concreta de qué es la capa de escritura y acción operativa sobre el ecosistema Fabric.
• Consumo analítico: el SQL analytics endpoint expone una copia de solo lectura para Power BI, Excel o modelos enriquecidos. Si hay latencia, se documenta.
• Metadata de métricas: la aplicación lee del modelo la definición, el formato, la tendencia, el orden, el equipo y la dimensión sugerida. Esto evita codificar reglas de negocio de forma fija en el frontend.

Tabla: qué hace cada capa y por qué

¿Cómo se implementan los targets sin ensuciar el modelo?

Los objetivos son el caso operativo más común. El usuario define una meta por semana, mes, trimestre o año, con nombre automático y escenario. El error frecuente es dejar que el usuario escriba nombres y fechas sueltas. En cambio, el período debe derivarse del calendario de gestión, para que cada objetivo quede clasificado sin ambigüedad.

La arquitectura recomendada para targets sigue un flujo claro, que puedes ver desarrollado en detalle en la guía sobre cómo implementar la capa de escritura y acción operativa paso a paso:

1. La Fabric App captura el objetivo en la interfaz.
2. RayfinClient escribe a través de la Data API GraphQL.
3. El dato aterriza en la SQL database hija.
4. El SQL analytics endpoint expone esa escritura como solo lectura.
5. El modelo semántico integra el valor para Power BI, Excel o una Scorecard.

Un detalle de experiencia importante: la aplicación puede mostrar el objetivo recién guardado desde la respuesta de la API, aunque el modelo analítico todavía tenga una actualización pendiente. El usuario ve confirmación inmediata sin esperar el ciclo analítico completo.

¿Dónde está el límite de seguridad de la aplicación?

Aquí es donde muchos proyectos fallan. El navegador es un cliente, no un lugar de confianza. Las reglas son estrictas y no negociables:

• No se exponen tokens en el navegador.
• El navegador no realiza inserciones ni actualizaciones sensibles por su cuenta.
• El navegador no decide permisos.
• localStorage sirve solo para desarrollo, nunca como fuente productiva, y debe quedar marcado como alternativa.

Cuando la acción debe actualizar Power BI REST, Scorecards u otro sistema con permisos de escritura, la llamada se ejecuta en una función del lado del servidor, una CLI operada o un backend seguro. Los check-ins de Scorecards por API entran en esta categoría: pasan por una capa segura, nunca directo desde el cliente.

Fabric aporta alojamiento y servicios, pero la responsabilidad no se transfiere. Los secretos, los permisos mínimos, las reglas expuestas en la interfaz y el cumplimiento siguen siendo del equipo. La documentación de modelos de datos y permisos de datos separa la consulta, la identidad y el acceso a las fuentes, y esa separación es la que hay que respetar en la implementación.

¿Qué madurez tiene hoy Fabric Apps y qué responsabilidad implica?

Antes de comprometer un proyecto, revisa el estado de disponibilidad de Fabric Apps en la documentación oficial: la cobertura por región puede variar y siempre requiere la habilitación del administrador del tenant. En producción utiliza Fabric SSO como autenticación. Si el caso necesita autenticación personalizada, transacciones complejas o garantías propias de una función estable, se diseña una capa de aplicación alternativa en lugar de forzar la herramienta.

Esto no descalifica la tecnología. Significa planificar con criterio: validar disponibilidad regional, coordinar con el administrador del tenant y decidir por adelantado qué acciones viven en Fabric y cuáles necesitan una capa propia. Un buen diseño de UX de análisis ayuda: navegación por equipos, panel lateral de métricas, tabla predeterminada y pestaña de gráficos por dimensión. Una aplicación ejecutiva no debe parecer un informe disfrazado; debe guiar decisiones y acciones según el rol.

¿Cuál es el checklist mínimo antes de construir?

Antes de escribir la primera línea de la aplicación, conviene confirmar lo esencial:

• El modelo semántico existe y define métricas, formatos y dimensiones (el contrato está claro).
• El administrador del tenant habilitó Fabric Apps y la región lo soporta.
• Las escrituras sensibles tienen una función del lado del servidor o un backend seguro previsto.
• Los períodos de los targets se derivan del calendario de gestión.
• La latencia entre escritura y análisis está documentada y aceptada por el negocio.

Si alguno de estos puntos falta, el problema no es de código: es de arquitectura de datos, y ninguna capa de aplicación va a compensar un modelo mal diseñado.

Siguiente paso

Una Fabric App operativa es tan sólida como el modelo semántico que la sostiene. Si tu organización está evaluando cuándo pasar del informe a la aplicación, o cómo ordenar el modelo antes de construir, la forma más directa de verlo aplicado es con un ejemplo real: mira la demo gratuita y evalúa con tu equipo qué camino, formación o consultoría, encaja con tu punto de partida.