Power BI Embedded: agregar análisis a su aplicación

Cada aplicación SaaS eventualmente necesita análisis. Los usuarios quieren paneles que muestren sus patrones de uso, métricas de rendimiento y resultados comerciales. Crear una capa de análisis personalizada desde cero (bibliotecas de gráficos, canales de datos, almacenamiento en caché, funcionalidad de exportación, interacciones de desglose) requiere de 6 a 12 meses de esfuerzo de ingeniería y mantenimiento continuo. Power BI Embedded ofrece una alternativa: capacidades de análisis de nivel empresarial integradas directamente en su aplicación, respaldadas por la infraestructura de Microsoft.

Power BI Embedded no consiste simplemente en "poner un iframe en una página". Es una plataforma completa para ofrecer experiencias analíticas interactivas, seguras y multiinquilino dentro de la interfaz de usuario de su propia aplicación. Sus clientes interactúan con análisis que se ven y se sienten nativos de su producto mientras usted aprovecha el motor de visualización maduro de Power BI, la capa de cálculo DAX y la infraestructura de conectividad de datos.

Esta guía cubre la arquitectura, los modelos de autenticación, la seguridad multiinquilino, la planificación de capacidad, la integración de SDK y las consideraciones de precios para integrar Power BI en su aplicación. Si está planificando una implementación de análisis integrados, explore nuestros servicios de análisis integrados de Power BI para obtener orientación sobre arquitectura y soporte de desarrollo.

Conclusiones clave

• Power BI Embedded admite dos escenarios: "insertar para sus clientes" (la aplicación posee datos) e "insertar para su organización" (el usuario posee datos)
• Se recomienda la autenticación de entidad de servicio para aplicaciones SaaS multiinquilino; Las cuentas de usuario maestras son más simples pero crean puntos únicos de falla.
• La seguridad a nivel de fila (RLS) es el mecanismo principal para garantizar el aislamiento de los datos de los inquilinos en conjuntos de datos compartidos.
• Las SKU Fabric F proporcionan la capacidad más rentable para escenarios integrados, comenzando en F2 para el desarrollo.
• El SDK de JavaScript permite un control programático profundo: aplicar filtros, capturar eventos, controlar la navegación y personalizar temas.
• El tamaño de la capacidad depende de los usuarios simultáneos, la complejidad de las consultas y el volumen de datos, no solo del número total de usuarios.
• Los temas personalizados y Chrome oculto hacen que los informes integrados parezcan nativos de su aplicación

---

Escenarios de integración: clientes frente a organización

Insertar para sus clientes (la aplicación posee datos)

El escenario "la aplicación posee datos" es el caso de uso principal de las aplicaciones SaaS. Su aplicación se autentica con Power BI mediante una entidad de servicio o una cuenta de usuario maestra, genera un token de inserción y entrega el informe incrustado a sus usuarios finales. Sus clientes nunca interactúan con Power BI directamente y no necesitan licencias de Power BI.

Flujo de arquitectura:

1. Su cliente inicia sesión en su aplicación utilizando su sistema de autenticación.
2. El backend de su aplicación llama a la API REST de Power BI para generar un token de inserción, cuyo ámbito es el informe, el conjunto de datos y la función RLS específicos de ese cliente.
3. El backend devuelve el token de inserción y la URL de inserción al frontend.
4. La interfaz inicializa el SDK de JavaScript de Power BI con el token de inserción y representa el informe en un elemento contenedor designado.
5. El token de inserción caduca después de un período configurable (predeterminado 1 hora) y su aplicación lo actualiza de forma transparente.

Características clave:

• Los clientes no necesitan licencias Power BI Pro o Premium por usuario
• Todos los costos de capacidad corren a cargo de usted (el proveedor de la aplicación) a través de SKU Fabric/Embedded
• Tienes control total sobre lo que ven los usuarios a través de RLS y filtrado programático.
• La autenticación está completamente dentro del sistema de autenticación de su aplicación.
• Los tokens integrados brindan acceso limitado en el tiempo y con alcance a artefactos específicos

Este es el modelo utilizado por los ISV, las plataformas SaaS y los portales internos donde el consumidor de análisis no debería saber ni importarle que Power BI sea la tecnología subyacente.

Insertar para su organización (los datos son propiedad del usuario)

El escenario "el usuario posee datos" sirve para insertar contenido de Power BI en aplicaciones internas donde los usuarios ya tienen licencias de Power BI (Pro o PPU). La experiencia integrada utiliza la identidad y los permisos de Power BI propios del usuario.

Flujo de arquitectura:

1. El usuario se autentica con Azure AD a través de su aplicación.
2. Su aplicación adquiere un token de acceso en nombre del usuario mediante el flujo en nombre de OAuth 2.0.
3. La aplicación llama a la API REST de Power BI con el token del usuario para obtener la configuración integrada.
4. El informe se representa con todos los permisos de Power BI del usuario.

Características clave:

• Cada usuario debe tener una licencia Power BI Pro o Premium por usuario
• Los usuarios ven contenido según sus propios permisos de Power BI y asignaciones de RLS.
• No se requiere capacidad adicional Fabric/Embedded (utiliza la asignación de licencia Pro/PPU del usuario)
• Menos control para el desarrollador de la aplicación, más autonomía para el usuario
• Arquitectura más simple pero mayor costo de licencia por usuario

Este modelo se utiliza normalmente para portales de intranet, integraciones de SharePoint y aplicaciones internas donde los usuarios ya tienen licencias de Power BI y deben conservar sus permisos de acceso existentes.

Elegir entre escenarios

Para la mayoría de las aplicaciones SaaS dirigidas a clientes externos, "la aplicación posee datos" es la opción correcta. El resto de esta guía se centra principalmente en este escenario.

---

Autenticación: principal de servicio frente a usuario maestro

Autenticación de principal de servicio

Una entidad de servicio es una identidad de aplicación de Azure AD en la que Power BI confía para acceder a los recursos mediante programación. Es el método de autenticación recomendado para aplicaciones integradas de producción.

Requisitos de configuración:

1. Registre una aplicación en Azure AD.
2. Cree un secreto de cliente o un certificado para la aplicación.
3. Cree un grupo de seguridad de Azure AD y agréguele la entidad de servicio.
4. En el portal de administración de Power BI, habilite el acceso a la entidad de servicio para el grupo de seguridad en Configuración de inquilino > Configuración de desarrollador.
5. Conceda a la entidad de servicio acceso a las áreas de trabajo de Power BI específicas que contienen su contenido incrustado.

Ventajas:

• No depende de una cuenta de usuario específica (elimina el punto único de falla)
• Los secretos y certificados del cliente se pueden rotar sin interrupción del servicio.
• Las entidades principales de servicio se pueden limitar a espacios de trabajo específicos (menor privilegio)
• Funciona con identidades administradas de Azure AD en aplicaciones alojadas en Azure
• Admite autenticación basada en certificados para mayor seguridad

Limitaciones:

• No se puede acceder a "Mi espacio de trabajo" (espacios de trabajo personales)
• No se pueden llamar ciertas API de administrador
• Requiere Azure AD Premium para algunas funciones avanzadas
• La configuración inicial es más compleja que la del usuario maestro.

Autenticación de usuario maestro

Un usuario maestro es una cuenta de usuario normal de Azure AD con una licencia Power BI Pro o PPU que su aplicación usa para autenticarse con Power BI. La aplicación inicia sesión como este usuario para generar tokens de inserción.

Ventajas:

• Configuración inicial más sencilla (crear un usuario, asignar una licencia, otorgar acceso al espacio de trabajo)
• Puede acceder a todas las funciones de Power BI, incluidas las API de administración
• No se requiere registro de la aplicación Azure AD

Desventajas:

• Punto único de falla: si la cuenta de usuario está bloqueada, la contraseña caduca o se activa MFA, su aplicación pierde el acceso a los análisis
• No se pueden utilizar políticas de acceso condicional que requieran inicio de sesión interactivo
• La rotación de contraseñas requiere actualizaciones de la aplicación
• Viola las mejores prácticas de seguridad de no utilizar cuentas humanas para procesos de máquina.
• Costo de licencia para la cuenta de usuario.

Recomendación: Utilice la autenticación de entidad de servicio para todas las implementaciones de producción. Las cuentas de usuario maestras son aceptables para entornos de desarrollo y prueba de concepto donde la simplicidad importa más que la confiabilidad.

Generación y gestión de tokens

Independientemente del método de autenticación, su aplicación genera tokens de inserción a través de la API REST de Power BI. El token encapsula los permisos para la sesión integrada.

Consideraciones para insertar tokens:

• Duración del token: El valor predeterminado es 1 hora, configurable hasta 24 horas. Las vidas más cortas son más seguras pero requieren actualizaciones más frecuentes.
• Alcance del token: Cada token tiene como alcance informes, conjuntos de datos y espacios de trabajo específicos. Generar el alcance más estrecho posible.
• Identidad RLS: Cuando se utiliza seguridad a nivel de fila, la identidad RLS (nombre de usuario y roles) está integrada en el token. Así es como se garantiza el aislamiento de los inquilinos.
• Actualización del token: Su interfaz debe monitorear la caducidad del token y solicitar un token nuevo antes de que caduque. El SDK de JavaScript proporciona eventos para esto.

Flujo de ejemplo de generación de tokens:

POST https://api.powerbi.com/v1.0/myorg/GenerateToken
{
    "datasets": [{"id": "dataset-guid"}],
    "reports": [{"id": "report-guid"}],
    "identities": [{
        "username": "[email protected]",
        "roles": ["TenantRole"],
        "datasets": ["dataset-guid"]
    }]
}

La respuesta contiene un token de inserción y una marca de tiempo de vencimiento. Su backend almacena en caché este token (respetando el vencimiento) y lo entrega a solicitudes de frontend autenticadas.

---

Seguridad a nivel de fila para múltiples inquilinos

Por qué RLS es fundamental para la integración integrada

En una aplicación SaaS multiinquilino, los datos de varios clientes a menudo residen en el mismo conjunto de datos de Power BI. Sin seguridad a nivel de fila, un token de inserción otorga acceso a todos los datos del conjunto de datos. RLS garantiza que cada cliente vea solo sus propios datos, aunque el conjunto de datos subyacente sea compartido.

RLS no es opcional para escenarios integrados de múltiples inquilinos. Una falla en el aislamiento de los inquilinos es una violación de datos. Diseñe RLS como un control de seguridad fundamental, no como una idea de último momento.

SPI estático

Static RLS define reglas de filtrado fijas mediante expresiones DAX en Power BI Desktop. Cada rol tiene un conjunto de filtros de tabla que restringen qué filas son visibles.

Ejemplo:

Un "TenantRole" con este filtro en la tabla Clientes:

[TenantId] = USERNAME()

Al generar un token de inserción, su aplicación establece el valor USERNAME() en el identificador del inquilino actual. El filtro DAX restringe todas las consultas a filas donde coincide TenantId.

Static RLS es simple y eficaz para un aislamiento sencillo de inquilinos. Funciona bien cuando:

• El aislamiento de inquilinos se basa en una sola columna (TenantId) que se propaga a través de relaciones.
• Todos los inquilinos ven la misma estructura de informe, solo filtrada según sus datos.
• El número de roles de RLS es pequeño y estable.

SPI dinámico

Dynamic RLS utiliza expresiones DAX que se evalúan en el momento de la consulta en función de la identidad del usuario. Esto permite escenarios de seguridad más complejos sin crear roles separados para cada inquilino.

Patrones de RLS dinámicos comunes:

Patrón USERPRINCIPALNAME():

[Email] = USERPRINCIPALNAME()

El token de inserción establece el nombre de usuario de la identidad efectiva en el correo electrónico del usuario. El filtro coincide con una columna de Correo electrónico en una tabla de asignación de seguridad.

Patrón de tabla de seguridad: Cree una tabla de seguridad dedicada que asigne usuarios a los datos a los que pueden acceder:

Aplique filtros RLS que unan esta tabla de seguridad a sus tablas de hechos a través de relaciones. Este patrón admite permisos a nivel de usuario dentro de un inquilino, no solo el aislamiento a nivel de inquilino.

Pruebas y validación de RLS

Pruebas previas a la implementación:

1. En Power BI Desktop, use "Ver como" para probar cada rol de RLS con nombres de usuario de muestra.
2. Verifique que el filtrado cruzado entre tablas respete los límites de RLS.
3. Pruebe casos extremos: usuarios sin filas coincidentes (deberían ver informes vacíos, no errores), usuarios con múltiples roles y valores nulos en las columnas de filtro.
4. Verifique que las medidas DAX que usan ALL() o REMOVEFILTERS() no omitan RLS (no deberían, pero verifiquen).

Validación de producción:

• Automatice las pruebas de RLS como parte de su canal de implementación
• Genere tokens de inserción para probar las identidades de los inquilinos y verifique que los resultados de la consulta coincidan con los datos esperados.
• Supervisar los intentos de omisión de RLS en métricas de capacidad (patrones de consulta inusuales, volúmenes de datos inesperados)
• Realizar revisiones de seguridad trimestrales de las configuraciones de RLS.

---

Tamaño de capacidad y SKU de tela

Comprensión de la capacidad

Power BI Embedded requiere capacidad dedicada: recursos informáticos reservados para sus cargas de trabajo integradas. La capacidad se mide en unidades de capacidad (CU), que determinan la potencia de procesamiento disponible para generar informes, ejecutar consultas y actualizar conjuntos de datos.

La capacidad no es por usuario. Es un grupo compartido de computación del que se basan todas sus sesiones integradas. Esto significa que los precios aumentan con la simultaneidad y la complejidad de las consultas, no con el número total de usuarios.

Opciones de SKU de tela F

Las SKU de Microsoft Fabric F son el modelo de precios actual para la capacidad de Power BI Embedded. Reemplazaron las SKU A heredadas por un modelo más flexible y con capacidad de pausa.

Notas importantes:

• Los usuarios simultáneos no significan usuarios totales. Significa que los usuarios realizan consultas activas al mismo tiempo. Una proporción típica es que entre el 5% y el 10% del total de usuarios son simultáneos en un momento dado.
• Estos son números orientativos aproximados. La capacidad real depende en gran medida de la complejidad de la consulta, el tamaño del modelo y el recuento de visualizaciones por informe.
• Las SKU F se pueden pausar cuando no están en uso (a diferencia de las SKU P heredadas), lo cual es valioso para el desarrollo y las cargas de trabajo estacionales.
• F64 y superiores incluyen funciones Power BI Premium (informes paginados, IA, canales de implementación) sin costo de licencia adicional.

Metodología de dimensionamiento de capacidad

Paso 1: Estimar los usuarios simultáneos.

Usuarios simultáneos = Usuarios totales x Índice de concurrencia máxima

Para paneles de análisis de SaaS a los que se accede durante el horario comercial: índice de simultaneidad del 5 al 10 %. Para paneles operativos que se revisan con frecuencia a lo largo del día: índice de simultaneidad del 15 al 25 %. Para paneles controlados por eventos (monitoreo en tiempo real, alertas): índice de simultaneidad del 30 al 50 %.

Paso 2: Evaluar la complejidad de la consulta.

Informes simples (5-10 elementos visuales, agregaciones básicas, tabla de hechos única): 1x línea de base. Informes medianos (10 a 20 imágenes, inteligencia de tiempo, múltiples tablas de hechos): 2 a 3 veces la línea de base. Informes complejos (más de 20 elementos visuales, DAX complejo, grandes conjuntos de datos, consultas entre fuentes): línea de base de 4 a 6 veces mayor.

Paso 3: Calcule la capacidad requerida.

Comience con el SKU que coincida con su estimación de usuarios simultáneos de la tabla anterior. Multiplique por su factor de complejidad. Si el resultado excede la capacidad de consulta simultánea del SKU, pase al siguiente nivel.

Paso 4: Validar con pruebas de carga.

El dimensionamiento teórico es un punto de partida. Antes del lanzamiento de la producción, realice pruebas de carga con volúmenes de datos, patrones de consulta y niveles de simultaneidad realistas. Microsoft proporciona una herramienta de prueba de carga de capacidad de Power BI Embedded para este fin.

Paso 5: Planifique el crecimiento.

Agregue entre un 30% y un 50% de margen por encima de su pico actual para adaptarse al crecimiento durante los próximos 6 a 12 meses. Las SKU F se pueden actualizar sin tiempo de inactividad, por lo que puede ajustar el tamaño de forma incremental.

Estrategias de optimización de costos

• Pausar capacidades de desarrollo en horario no laboral. F SKU facturados por segundo cuando están activos, gratis cuando están en pausa. Automatizar la pausa/reanudación con Azure Automation o Logic Apps puede reducir los costos de desarrollo entre un 60 y un 70 %.

• Optimizar modelos antes de escalar capacidad. Un modelo bien optimizado en F8 a menudo supera a un modelo mal optimizado en F32. Invierta en optimización del modelo antes de recurrir a la informática para solucionar problemas de rendimiento.

• Utilice tablas de agregación para conjuntos de datos grandes. La agregación previa de datos en granularidades comunes (diaria, semanal, mensual) reduce el procesamiento de consultas entre un 80 y un 90 % para elementos visuales de nivel de resumen, al tiempo que se preserva la capacidad de profundizar en detalles.

• Implementar almacenamiento en caché a nivel de informe a través de la API REST de Power BI. Para paneles con actualizaciones de datos poco frecuentes, los resultados almacenados en caché reducen el consumo de capacidad por sesión de usuario.

• Considere capacidades separadas para diferentes cargas de trabajo. Aislar las operaciones de actualización de las consultas interactivas evita que los picos de actualización degraden la experiencia del usuario. Esto es particularmente importante si tiene grandes conjuntos de datos que se actualizan durante el horario comercial.

---

Integración del SDK de JavaScript

Incrustación básica

El SDK de JavaScript de Power BI (powerbi-client) proporciona la interfaz programática para insertar y controlar el contenido de Power BI en su aplicación web.

Instalación:

npm install powerbi-client

Flujo de inserción básico:

import * as pbi from 'powerbi-client';

const powerbi = new pbi.service.Service(
    pbi.factories.hpmFactory,
    pbi.factories.wpmpFactory,
    pbi.factories.routerFactory
);

const embedConfig = {
    type: 'report',
    id: reportId,
    embedUrl: embedUrl,
    accessToken: embedToken,
    tokenType: pbi.models.TokenType.Embed,
    settings: {
        panes: {
            filters: { visible: false },
            pageNavigation: { visible: true }
        },
        background: pbi.models.BackgroundType.Transparent,
        layoutType: pbi.models.LayoutType.Custom,
        customLayout: {
            displayOption: pbi.models.DisplayOption.FitToWidth
        }
    }
};

const reportContainer = document.getElementById('report-container');
const report = powerbi.embed(reportContainer, embedConfig);

Control programático

El SDK expone un amplio control programático sobre el informe integrado:

Aplicando filtros:

const filter = {
    $schema: "http://powerbi.com/product/schema#basic",
    target: {
        table: "Sales",
        column: "Region"
    },
    operator: "In",
    values: ["North", "South"],
    filterType: pbi.models.FilterType.BasicFilter
};

await report.setFilters([filter]);

Capturando eventos:

report.on('loaded', function() {
    console.log('Report loaded successfully');
});

report.on('dataSelected', function(event) {
    const data = event.detail;
    // Handle user selection — navigate to detail page, update other UI, etc.
});

report.on('pageChanged', function(event) {
    const pageName = event.detail.newPage.displayName;
    // Track page navigation in your analytics
});

Actualización de token:

report.on('tokenExpired', async function() {
    const newToken = await fetchNewEmbedToken();
    await report.setAccessToken(newToken);
});

Control de navegación:

// Navigate to a specific page
const pages = await report.getPages();
const targetPage = pages.find(p => p.displayName === 'Revenue Analysis');
await targetPage.setActive();

// Set a specific slicer value
const visuals = await targetPage.getVisuals();
const slicer = visuals.find(v => v.type === 'slicer');
await slicer.setSlicerState({
    filters: [{
        $schema: "http://powerbi.com/product/schema#basic",
        target: { table: "Date", column: "Year" },
        operator: "In",
        values: [2026],
        filterType: pbi.models.FilterType.BasicFilter
    }]
});

Representación por fases para rendimiento

Para informes complejos con muchos elementos visuales, la representación por fases mejora el rendimiento percibido al representar primero el contenido de la mitad superior de la página:

const embedConfig = {
    // ... standard config
    settings: {
        // ... other settings
        commands: [{
            visualRendered: {
                phase: 1,
                visualNames: ['revenue-kpi', 'trend-chart', 'summary-table']
            }
        }]
    }
};

report.on('visualRendered', function(event) {
    if (event.detail.phase === 1) {
        // Hide loading spinner, show report
        document.getElementById('loading').style.display = 'none';
    }
});

---

Temas personalizados y marca

Por qué son importantes los temas personalizados

Los elementos visuales predeterminados de Power BI utilizan la paleta de colores y el estilo de Microsoft. En un contexto integrado, esto crea una inconsistencia visual con su aplicación. Los temas personalizados alinean los análisis integrados con el sistema de diseño de su producto, haciendo que la experiencia parezca nativa en lugar de integrada.

Estructura JSON del tema

Los temas de Power BI se definen como archivos JSON con control sobre colores, fuentes, valores predeterminados visuales y estilo de elementos:

{
    "name": "MyApp Theme",
    "dataColors": [
        "#2563EB", "#7C3AED", "#059669", "#D97706",
        "#DC2626", "#0891B2", "#4F46E5", "#65A30D"
    ],
    "background": "#FFFFFF",
    "foreground": "#1E293B",
    "tableAccent": "#2563EB",
    "textClasses": {
        "callout": {
            "fontSize": 28,
            "fontFace": "Inter, sans-serif",
            "color": "#0F172A"
        },
        "title": {
            "fontSize": 14,
            "fontFace": "Inter, sans-serif",
            "color": "#1E293B"
        },
        "header": {
            "fontSize": 12,
            "fontFace": "Inter, sans-serif",
            "color": "#475569"
        },
        "label": {
            "fontSize": 11,
            "fontFace": "Inter, sans-serif",
            "color": "#64748B"
        }
    },
    "visualStyles": {
        "*": {
            "*": {
                "border": [{
                    "color": {"solid": {"color": "#E2E8F0"}},
                    "radius": 8
                }],
                "background": [{
                    "color": {"solid": {"color": "#FFFFFF"}},
                    "transparency": 0
                }]
            }
        }
    }
}

Aplicar temas mediante programación

Los temas se pueden aplicar en el momento de la inserción o cambiar dinámicamente (útil para la compatibilidad con el modo oscuro):

// Apply theme at embed time
const embedConfig = {
    // ... standard config
    theme: { themeJson: customThemeJson }
};

// Switch theme dynamically (e.g., light/dark mode toggle)
await report.applyTheme({ themeJson: darkThemeJson });

Ocultar Power BI Chrome

Para obtener una apariencia completamente nativa, oculte los elementos de la interfaz de usuario integrados de Power BI y reemplácelos con sus propios controles de aplicación:

const settings = {
    panes: {
        filters: { visible: false },      // Hide filter pane
        pageNavigation: { visible: false } // Hide page tabs
    },
    bars: {
        actionBar: { visible: false },     // Hide action bar
        statusBar: { visible: false }      // Hide status bar
    },
    background: pbi.models.BackgroundType.Transparent,
    visualRenderedEvents: true
};

Luego, cree controles personalizados de navegación, filtrado y exportación en el marco de la interfaz de usuario de su aplicación. Utilice el SDK de JavaScript para aplicar filtros, cambiar páginas y activar exportaciones mediante programación cuando los usuarios interactúen con sus controles personalizados.

Este enfoque requiere más esfuerzo de desarrollo, pero produce una experiencia perfecta en la que los usuarios no pueden distinguir entre las características nativas de su aplicación y el contenido de Power BI integrado.

---

Optimización del rendimiento para integrado

Rendimiento de la interfaz

• Carga diferida del SDK. El SDK de JavaScript de Power BI tiene aproximadamente 300 KB. Cárguelo de forma asincrónica y solo cuando el usuario navegue a una página de análisis.
• Precargar tokens de inserción. Genere tokens de inserción antes de que el usuario solicite el informe. Si su aplicación sabe que el usuario probablemente verá análisis (basados ​​en patrones de navegación), precargue el token durante las transiciones de página.
• Utilice la incrustación de arranque. El SDK admite un patrón de arranque que inicializa el iframe antes de que el token de inserción esté disponible, lo que reduce el tiempo de carga percibido entre 200 y 500 ms.

// Bootstrap first (fast — creates iframe immediately)
const report = powerbi.bootstrap(container, { type: 'report' });

// Load later when token is available
const embedConfig = { /* full config */ };
report.load(embedConfig);

• Implementar el almacenamiento en caché de informes. Una vez que se carga un informe, el iframe lo retiene en la memoria. Si el usuario sale y regresa, reutilice el iframe existente en lugar de volver a incrustarlo. Esto elimina por completo el tiempo de carga para las visitas posteriores dentro de la misma sesión.

Rendimiento del backend

• Tokens de inserción de caché. Los tokens de inserción son válidos durante toda su vida útil (predeterminado 1 hora). Almacénelos en caché en Redis o en memoria y reutilícelos en solicitudes para la misma combinación de informe/identidad.
• Generación de tokens por lotes. Si el panel de un usuario contiene varios informes integrados, genere todos los tokens integrados en una única llamada API utilizando la capacidad de múltiples recursos del punto final GenerateToken.
• Supervisar los límites de velocidad de la API. La API REST de Power BI tiene límites de velocidad por entidad de servicio. Supervise 429 respuestas e implemente un retroceso exponencial. Para aplicaciones de gran escala, distribuya la carga entre varias entidades de servicio.

Diseño de informes para incrustados

Los informes diseñados para consumo integrado deben priorizar el rendimiento sobre la complejidad visual:

• Limite los elementos visuales a 8-12 por página (cada elemento visual genera una consulta separada)
• Utilice el modo Importar en lugar de DirectQuery cuando sea posible (entre 10 y 100 veces más rápido)
• Datos preagregados con la granularidad adecuada
• Evite medidas DAX complejas en las páginas de destino (guárdelas para obtener detalles detallados)
• Utilice marcadores para vistas precalculadas en lugar de cálculos dinámicos
• Pruebe los tiempos de carga de los informes en su nivel de simultaneidad esperado, no solo para un solo usuario.

Para las organizaciones que implementan análisis integrados, ECOSIRE ofrece servicios de desarrollo y consultoría de arquitectura para garantizar un rendimiento óptimo desde el primer día.

---

Consideraciones de seguridad para dispositivos integrados

Seguridad del token

Los tokens para insertar otorgan acceso al contenido de Power BI. Trátelos como credenciales confidenciales:

• Nunca exponga tokens de inserción en el código fuente del lado del cliente o en los parámetros de URL
• Generar tokens del lado del servidor y entregarlos a través de puntos finales API autenticados.
• Utilice la vida útil más corta del token (la hora predeterminada es razonable para la mayoría de las aplicaciones)
• Implementar lógica de actualización de tokens en lugar de generar tokens de larga duración.
• Monitorear los patrones de generación de tokens para detectar anomalías (volumen inusual, ID de informes inesperados)

Validación de aislamiento de inquilinos

Para aplicaciones multiinquilino, valide el aislamiento de inquilinos continuamente:

• Pruebas automatizadas que generan tokens de inserción para el inquilino A y verifican que no se puede acceder a los datos del inquilino B.
• Registro de consultas para detectar intentos de acceso a datos entre inquilinos
• Auditorías periódicas de configuración de RLS (los roles de RLS pueden modificarse en Power BI Desktop y debilitarse accidentalmente)
• Alertas sobre errores del filtro RLS (que podrían indicar una mala configuración)

Seguridad de la red

• Restrinja el acceso a la API REST de Power BI a rangos de IP conocidos mediante el acceso condicional de Azure AD
• Utilice puntos de conexión privados para conexiones de puerta de enlace a fuentes de datos locales
• Habilite el registro de auditoría en el portal de administración de Power BI para realizar un seguimiento de todas las llamadas API e incrustar la generación de tokens.
• Implemente encabezados de política de seguridad de contenido para restringir la incrustación de iframe en el dominio de su aplicación.

---

Preguntas frecuentes

¿Cuánto cuesta Power BI Embedded para una aplicación SaaS con 10 000 usuarios?

El costo depende de los usuarios simultáneos, no del total de usuarios. Si el 5% de sus 10 000 usuarios son simultáneos en su punto máximo (500 usuarios simultáneos), necesitaría aproximadamente una capacidad de F32 a aproximadamente $8200 por mes (pago por uso). Con una reserva (compromiso de 1 año), esto se reduce a aproximadamente $5500 por mes. Su costo real podría ser mayor o menor según la complejidad del informe, el tamaño del conjunto de datos y los patrones de uso. Comience con F8 como prueba piloto, cargue la prueba con simultaneidad realista y escale según mediciones reales.

¿Puedo usar Power BI Embedded sin Azure?

Power BI Embedded requiere Azure AD para la autenticación y capacidad Fabric/Embedded aprovisionada a través de Azure. Su aplicación en sí puede hospedarse en cualquier lugar (AWS, GCP, local), pero los recursos de Power BI deben estar en Azure. La entidad de servicio o la cuenta de usuario maestra deben estar en Azure AD y la capacidad debe ser un recurso de Azure. Para las organizaciones que no tienen presencia de Azure, la configuración agrega aproximadamente de 2 a 4 horas de trabajo de configuración de Azure y una administración continua mínima de Azure más allá de la capacidad misma.

¿Cuál es la diferencia entre las SKU A, las SKU EM y las SKU Fabric F de Power BI Embedded?

Las SKU eran la capacidad original de Power BI Embedded, aprovisionada a través de Azure. Las SKU EM eran una opción de licencia para la integración interna con Office 365. Ambas han sido reemplazadas por las SKU Fabric F, que proporcionan un modelo de capacidad unificada para todas las cargas de trabajo de Power BI y Fabric. Las SKU F ofrecen facturación por segundo, capacidad de pausar/reanudar y una estructura de precios más simple. Para nuevas implementaciones, utilice SKU F exclusivamente. Los clientes existentes de SKU A deben planificar la migración a SKU F para obtener mejores precios y capacidades.

¿Pueden los usuarios exportar datos de informes integrados?

Sí, pero esto lo controlas a través de la configuración de inserción. El SDK de JavaScript le permite habilitar o deshabilitar las capacidades de exportación (Exportar a Excel, PDF, PowerPoint) por informe. También puede implementar una funcionalidad de exportación personalizada a través de la API de exportación, que le brinda más control sobre el formato, los filtros aplicados y el registro de auditoría. Para datos confidenciales, desactive la exportación integrada y proporcione su propio mecanismo de exportación que aplique controles de autorización y marcas de agua adicionales.

¿Cómo manejo el desarrollo de informes en un escenario integrado?

El desarrollo de informes sigue el flujo de trabajo estándar de Power BI: cree informes en Power BI Desktop, publíquelos en un espacio de trabajo de desarrollo, pruebe con tokens de inserción de muestra y promuévalos a producción a través de canalizaciones de implementación. La diferencia clave es que los informes integrados necesitan pruebas adicionales para el comportamiento de RLS, el rendimiento en condiciones de concurrencia, el diseño receptivo en todos los tamaños de pantalla y la interacción con la interfaz de usuario de su aplicación. Establezca un canal de CI/CD que incluya validación RLS automatizada y pruebas de regresión de rendimiento como parte de cada implementación de informes.