Power BI Embedded: Adicionando análises ao seu aplicativo

Todo aplicativo SaaS eventualmente precisa de análises. Os usuários desejam painéis que mostrem seus padrões de uso, métricas de desempenho e resultados de negócios. Construir uma camada de análise personalizada do zero – bibliotecas de gráficos, pipelines de dados, cache, funcionalidade de exportação, interações de detalhamento – leva de 6 a 12 meses de esforço de engenharia e manutenção contínua. O Power BI Embedded oferece uma alternativa: recursos analíticos de nível empresarial incorporados diretamente em seu aplicativo, apoiados pela infraestrutura da Microsoft.

Power BI Embedded não é simplesmente “colocar um iframe em uma página”. É uma plataforma completa para fornecer experiências analíticas interativas, seguras e multilocatários na interface do usuário do seu próprio aplicativo. Seus clientes interagem com análises que parecem nativas do seu produto enquanto você aproveita o mecanismo de visualização maduro do Power BI, a camada de cálculo DAX e a infraestrutura de conectividade de dados.

Este guia aborda a arquitetura, os modelos de autenticação, a segurança multilocatário, o planejamento de capacidade, a integração do SDK e as considerações de preços para incorporar o Power BI em seu aplicativo. Se você estiver planejando uma implementação de análise incorporada, explore nossos serviços de análise incorporada do Power BI para obter orientação de arquitetura e suporte ao desenvolvimento.

Principais conclusões

• O Power BI Embedded oferece suporte a dois cenários: "incorporado para seus clientes" (o aplicativo possui os dados) e "incorporado para sua organização" (o usuário possui os dados)
• A autenticação principal do serviço é recomendada para aplicativos SaaS multilocatários; contas de usuário mestre são mais simples, mas criam pontos únicos de falha
• A segurança em nível de linha (RLS) é o principal mecanismo para garantir o isolamento de dados do locatário em conjuntos de dados compartilhados
• Os SKUs Fabric F fornecem a capacidade mais econômica para cenários incorporados, começando em F2 para desenvolvimento
• O JavaScript SDK permite controle programático profundo: aplicação de filtros, captura de eventos, controle de navegação e personalização de temas
• O dimensionamento da capacidade depende dos usuários simultâneos, da complexidade da consulta e do volume de dados --- não apenas da contagem total de usuários
• Temas personalizados e cromo oculto fazem com que os relatórios incorporados pareçam nativos do seu aplicativo

---

Cenários de incorporação: clientes x organização

Incorporação para seus clientes (o aplicativo possui dados)

O cenário “o aplicativo possui dados” é o principal caso de uso para aplicativos SaaS. Seu aplicativo é autenticado com o Power BI usando uma entidade de serviço ou conta de usuário mestre, gera um token incorporado e fornece o relatório incorporado aos usuários finais. Seus clientes nunca interagem diretamente com o Power BI e não precisam de licenças do Power BI.

Fluxo de arquitetura:

1. Seu cliente faz login em seu aplicativo usando seu sistema de autenticação.
2. O back-end do seu aplicativo chama a API REST do Power BI para gerar um token incorporado, com escopo para o relatório, conjunto de dados e função RLS específicos para esse cliente.
3. O backend retorna o token incorporado e o URL incorporado ao frontend.
4. O front-end inicializa o SDK JavaScript do Power BI com o token incorporado e renderiza o relatório em um elemento de contêiner designado.
5. O token incorporado expira após um período configurável (padrão 1 hora) e seu aplicativo o atualiza de forma transparente.

Características principais:

• Os clientes não precisam de licenças do Power BI Pro ou Premium por usuário
• Todos os custos de capacidade são suportados por você (o fornecedor do aplicativo) por meio de SKUs Fabric/Embedded
• Você tem controle total sobre o que os usuários veem por meio de RLS e filtragem programática
• A autenticação está inteiramente dentro do sistema de autenticação do seu aplicativo
• Os tokens incorporados fornecem acesso com escopo e tempo limitado a artefatos específicos

Este é o modelo usado por ISVs, plataformas SaaS e portais internos onde o consumidor de análise não deve saber ou se importar que o Power BI é a tecnologia subjacente.

Incorporação para sua organização (o usuário possui dados)

O cenário "o usuário possui dados" serve para incorporar conteúdo do Power BI em aplicativos internos onde os usuários já possuem licenças do Power BI (Pro ou PPU). A experiência incorporada usa a identidade e as permissões do Power BI do próprio usuário.

Fluxo de arquitetura:

1. O usuário se autentica no Azure AD por meio do seu aplicativo.
2. Seu aplicativo adquire um token de acesso em nome do usuário usando o fluxo em nome do OAuth 2.0.
3. O aplicativo chama a API REST do Power BI com o token do usuário para obter a configuração incorporada.
4. O relatório é renderizado com todas as permissões do Power BI do usuário.

Características principais:

• Cada usuário deve ter uma licença do Power BI Pro ou Premium por usuário
• Os usuários veem o conteúdo com base em suas próprias permissões do Power BI e atribuições de RLS
• Nenhuma capacidade adicional de Fabric/Embedded é necessária (usa a alocação de licença Pro/PPU do usuário)
• Menos controle para o desenvolvedor da aplicação, mais autonomia para o usuário
• Arquitetura mais simples, mas maior custo de licenciamento por usuário

Esse modelo normalmente é usado para portais de intranet, integrações do SharePoint e aplicativos internos onde os usuários já possuem licenças do Power BI e devem manter as permissões de acesso existentes.

Escolhendo entre cenários

Para a maioria dos aplicativos SaaS direcionados a clientes externos, “o aplicativo possui dados” é a escolha correta. O restante deste guia concentra-se principalmente neste cenário.

---

Autenticação: entidade de serviço x usuário mestre

Autenticação principal de serviço

Uma entidade de serviço é uma identidade de aplicativo do Azure AD na qual o Power BI confia para acessar recursos de maneira programática. É o método de autenticação recomendado para aplicativos incorporados de produção.

Requisitos de configuração:

1. Registre um aplicativo no Azure AD.
2. Crie um segredo de cliente ou certificado para o aplicativo.
3. Crie um grupo de segurança do Azure AD e adicione-lhe o principal de serviço.
4. No portal de administração do Power BI, habilite o acesso da entidade de serviço para o grupo de segurança em Configurações do locatário > Configurações do desenvolvedor.
5. Conceda à entidade de serviço acesso aos espaços de trabalho específicos do Power BI que contêm seu conteúdo incorporado.

Vantagens:

• Sem dependência de uma conta de usuário específica (elimina ponto único de falha)
• Os segredos e certificados do cliente podem ser alternados sem interrupção do serviço
• As entidades de serviço podem ter como escopo espaços de trabalho específicos (privilégio mínimo)
• Funciona com identidades gerenciadas pelo Azure AD em aplicativos hospedados no Azure
• Suporta autenticação baseada em certificado para maior segurança

Limitações:

• Não é possível acessar "Meu espaço de trabalho" (áreas de trabalho pessoais)
• Não é possível chamar determinadas APIs administrativas
• Requer Azure AD Premium para alguns recursos avançados
• A configuração inicial é mais complexa que a do usuário mestre

Autenticação de usuário mestre

Um usuário mestre é uma conta de usuário regular do Azure AD com uma licença do Power BI Pro ou PPU que seu aplicativo usa para autenticar com o Power BI. O aplicativo efetua login como esse usuário para gerar tokens incorporados.

Vantagens:

• Configuração inicial mais simples (criar um usuário, atribuir uma licença, conceder acesso ao espaço de trabalho)
• Pode acessar todos os recursos do Power BI, incluindo APIs de administração
• Não é necessário registro de aplicativo do Azure AD

Desvantagens:

• Ponto único de falha: se a conta do usuário for bloqueada, a senha expirar ou a MFA for acionada, seu aplicativo perderá o acesso às análises
• Não é possível usar políticas de acesso condicional que exijam login interativo
• A rotação de senha requer atualizações de aplicativos
• Viola as melhores práticas de segurança de não usar contas humanas para processos de máquina
• Custo da licença para a conta do usuário

Recomendação: use a autenticação principal de serviço para todas as implantações de produção. As contas de usuário mestre são aceitáveis ​​para ambientes de desenvolvimento e prova de conceito onde a simplicidade é mais importante do que a confiabilidade.

Geração e gerenciamento de tokens

Independentemente do método de autenticação, seu aplicativo gera tokens incorporados por meio da API REST do Power BI. O token encapsula as permissões para a sessão incorporada.

Considerações sobre token incorporado:

• Vida útil do token: O padrão é 1 hora, configurável até 24 horas. Vidas mais curtas são mais seguras, mas exigem atualizações mais frequentes.
• Escopo do token: Cada token tem como escopo relatórios, conjuntos de dados e espaços de trabalho específicos. Gere o escopo mais restrito possível.
• Identidade RLS: Ao usar a segurança em nível de linha, a identidade RLS (nome de usuário e funções) é incorporada ao token. É assim que você garante o isolamento do inquilino.
• Atualização de token: Seu frontend deve monitorar a expiração do token e solicitar um novo token antes que ele expire. O JavaScript SDK fornece eventos para isso.

Fluxo de exemplo de geração de token:

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"]
    }]
}

A resposta contém um token incorporado e um carimbo de data/hora de expiração. Seu back-end armazena esse token em cache (respeitando a expiração) e o disponibiliza para solicitações de front-end autenticadas.

---

Segurança em nível de linha multilocatário

Por que o RLS é fundamental para sistemas incorporados

Numa aplicação SaaS multi-inquilino, os dados de vários clientes residem frequentemente no mesmo conjunto de dados do Power BI. Sem segurança em nível de linha, um token incorporado concede acesso a todos os dados do conjunto de dados. O RLS garante que cada cliente veja apenas os seus próprios dados, mesmo que o conjunto de dados subjacente seja partilhado.

O RLS não é opcional para cenários integrados de vários locatários. Uma falha no isolamento do locatário é uma violação de dados. Projete o RLS como um controle de segurança fundamental, não como uma reflexão tardia.

RLS estático

O RLS estático define regras de filtro fixas usando expressões DAX no Power BI Desktop. Cada função possui um conjunto de filtros de tabela que restringem quais linhas ficam visíveis.

Exemplo:

Um "TenantRole" com este filtro na tabela Clientes:

[TenantId] = USERNAME()

Ao gerar um token incorporado, seu aplicativo define o valor USERNAME() como o identificador do locatário atual. O filtro DAX restringe todas as consultas às linhas onde TenantId corresponde.

O RLS estático é simples e eficaz para isolamento direto do locatário. Funciona bem quando:

• O isolamento do locatário é baseado em uma única coluna (TenantId) que se propaga por meio de relacionamentos
• Todos os locatários veem a mesma estrutura de relatório, apenas filtrada para seus dados
• O número de funções RLS é pequeno e estável

RLS dinâmico

O RLS dinâmico usa expressões DAX que são avaliadas no momento da consulta com base na identidade do usuário. Isto permite cenários de segurança mais complexos sem criar funções separadas para cada inquilino.

Padrões RLS dinâmicos comuns:

Padrão USERPRINCIPALNAME():

[Email] = USERPRINCIPALNAME()

O token incorporado define o nome de usuário da identidade efetiva para o e-mail do usuário. O filtro corresponde a uma coluna Email em uma tabela de mapeamento de segurança.

Padrão de tabela de segurança: Crie uma tabela de segurança dedicada mapeando os usuários para os dados que eles podem acessar:

Aplique filtros RLS que unem esta tabela de segurança às suas tabelas de fatos por meio de relacionamentos. Este padrão suporta permissões ao nível do utilizador dentro de um inquilino, não apenas ao isolamento ao nível do inquilino.

Teste e validação de RLS

Testes de pré-implantação:

1. No Power BI Desktop, use "Exibir como" para testar cada função RLS com exemplos de nomes de usuário.
2. Verifique se a filtragem cruzada entre tabelas respeita os limites RLS.
3. Teste casos extremos: usuários sem linhas correspondentes (devem ver relatórios vazios, não erros), usuários com múltiplas funções e valores nulos em colunas de filtro.
4. Verifique se as medidas DAX usando ALL() ou REMOVEFILTERS() não ignoram o RLS (não deveriam, mas verificam).

Validação de produção:

• Automatize os testes de RLS como parte do seu pipeline de implantação
• Gere tokens incorporados para testar identidades de locatários e verifique se os resultados da consulta correspondem aos dados esperados
• Monitore tentativas de desvio de RLS em métricas de capacidade (padrões de consulta incomuns, volumes de dados inesperados)
• Realizar revisões trimestrais de segurança das configurações RLS

---

Dimensionamento de capacidade e SKUs de malha

Compreendendo a capacidade

O Power BI Embedded requer capacidade dedicada --- recursos de computação reservados para suas cargas de trabalho incorporadas. A capacidade é medida em Unidades de Capacidade (CUs), que determinam o poder de processamento disponível para renderizar relatórios, executar consultas e atualizar conjuntos de dados.

A capacidade não é por usuário. É um conjunto compartilhado de computação do qual todas as suas sessões incorporadas são extraídas. Isso significa que os preços variam de acordo com a simultaneidade e a complexidade da consulta, e não com a contagem total de usuários.

Opções de SKU de tecido F

Os SKUs do Microsoft Fabric F são o modelo de preços atual para a capacidade do Power BI Embedded. Eles substituíram os SKUs A legados por um modelo mais flexível e com capacidade de pausa.

Notas importantes:

• Usuários simultâneos não significam o total de usuários. Isso significa que os usuários consultam ativamente ao mesmo tempo. Uma proporção típica é de 5 a 10% do total de usuários simultâneos em um determinado momento.
• Estes são números de orientação aproximados. A capacidade real depende muito da complexidade da consulta, do tamanho do modelo e da contagem de visualizações por relatório.
• Os SKUs F podem ser pausados ​​quando não estiverem em uso (ao contrário dos SKUs P legados), o que é valioso para cargas de trabalho sazonais e de desenvolvimento.
• F64 e superiores incluem recursos do Power BI Premium (relatórios paginados, IA, pipelines de implantação) sem custo adicional de licença.

Metodologia de Dimensionamento de Capacidade

Etapa 1: estimar usuários simultâneos.

Usuários simultâneos = total de usuários x taxa máxima de simultaneidade

Para painéis analíticos SaaS acessados ​​durante o horário comercial: taxa de simultaneidade de 5 a 10%. Para painéis operacionais verificados frequentemente ao longo do dia: taxa de simultaneidade de 15 a 25%. Para painéis orientados a eventos (monitoramento em tempo real, alertas): taxa de simultaneidade de 30 a 50%.

Etapa 2: avaliar a complexidade da consulta.

Relatórios simples (5 a 10 recursos visuais, agregações básicas, tabela de fatos únicos): 1x linha de base. Relatórios médios (10 a 20 recursos visuais, inteligência de tempo, tabelas de fatos múltiplos): linha de base 2 a 3x. Relatórios complexos (mais de 20 elementos visuais, DAX complexo, grandes conjuntos de dados, consultas de fontes cruzadas): linha de base de 4 a 6x.

Etapa 3: Calcule a capacidade necessária.

Comece com o SKU que corresponde à estimativa de usuários simultâneos da tabela acima. Multiplique pelo seu fator de complexidade. Se o resultado exceder a capacidade de consulta simultânea do SKU, passe para o próximo nível.

Etapa 4: validar com teste de carga.

O dimensionamento teórico é um ponto de partida. Antes do lançamento da produção, realize testes de carga com volumes de dados, padrões de consulta e níveis de simultaneidade realistas. A Microsoft fornece uma ferramenta de teste de carga de capacidade do Power BI Embedded para essa finalidade.

Etapa 5: Planeje o crescimento.

Adicione 30-50% de margem acima do pico atual para acomodar o crescimento nos próximos 6 a 12 meses. Os SKUs F podem ser atualizados sem tempo de inatividade, para que você possa dimensionar corretamente de forma incremental.

Estratégias de otimização de custos

• Pausar capacidades de desenvolvimento fora do horário de trabalho. F SKUs cobrados por segundo quando ativos, gratuitos quando pausados. Automatizar a pausa/retomada com a Automação do Azure ou Aplicativos Lógicos pode reduzir os custos de desenvolvimento em 60-70%.

• Otimize modelos antes de aumentar a capacidade. Um modelo bem otimizado em F8 geralmente supera um modelo mal otimizado em F32. Invista na otimização do modelo antes de lançar a computação em problemas de desempenho.

• Use tabelas de agregação para grandes conjuntos de dados. A pré-agregação de dados em granularidades comuns (diariamente, semanalmente, mensalmente) reduz o processamento de consultas em 80-90% para recursos visuais em nível de resumo, preservando ao mesmo tempo a capacidade de detalhamento.

• Implementar o cache em nível de relatório por meio da API REST do Power BI. Para painéis com atualizações de dados pouco frequentes, os resultados armazenados em cache reduzem o consumo de capacidade por sessão de usuário.

• Considere capacidades separadas para diferentes cargas de trabalho. Isolar as operações de atualização de consultas interativas evita que picos de atualização prejudiquem a experiência do usuário. Isso é especialmente importante se você tiver grandes conjuntos de dados que são atualizados durante o horário comercial.

---

Integração SDK JavaScript

Incorporação Básica

O SDK JavaScript do Power BI (powerbi-client) fornece a interface programática para incorporar e controlar o conteúdo do Power BI em seu aplicativo Web.

Instalação:

npm install powerbi-client

Fluxo de incorporação 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);

Controle Programático

O SDK expõe amplo controle programático sobre o relatório incorporado:

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
});

Atualização de token:

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

Controle de navegação:

// 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
    }]
});

Renderização em fases para desempenho

Para relatórios complexos com muitos elementos visuais, a renderização em fases melhora o desempenho percebido ao renderizar primeiro o conteúdo acima da dobra:

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 e branding

Por que os temas personalizados são importantes

Os visuais padrão do Power BI usam a paleta de cores e o estilo da Microsoft. Em um contexto incorporado, isso cria inconsistência visual com seu aplicativo. Os temas personalizados alinham as análises incorporadas ao sistema de design do seu produto, fazendo com que a experiência pareça nativa, em vez de integrada.

Estrutura JSON do tema

Os temas do Power BI são definidos como arquivos JSON com controle sobre cores, fontes, padrões visuais e estilo de elemento:

{
    "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
                }]
            }
        }
    }
}

Aplicando temas programaticamente

Os temas podem ser aplicados no momento da incorporação ou alternados dinamicamente (útil para suporte ao modo escuro):

// 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 });

Ocultando o Power BI Chrome

Para obter uma aparência totalmente nativa, oculte os elementos de interface do usuário integrados do Power BI e substitua-os pelos seus próprios controles de aplicativo:

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
};

Em seguida, crie controles personalizados de navegação, filtragem e exportação na estrutura de UI do seu aplicativo. Use o SDK JavaScript para aplicar filtros de maneira programática, alterar páginas e acionar exportações quando os usuários interagirem com seus controles personalizados.

Essa abordagem requer mais esforço de desenvolvimento, mas produz uma experiência perfeita em que os usuários não conseguem distinguir entre os recursos nativos do seu aplicativo e o conteúdo incorporado do Power BI.

---

Otimização de desempenho para sistemas integrados

Desempenho de front-end

• Carregamento lento do SDK. O SDK JavaScript do Power BI tem aproximadamente 300 KB. Carregue-o de forma assíncrona e somente quando o usuário navegar para uma página de análise.
• Pré-carregar tokens incorporados. Gere tokens incorporados antes que o usuário solicite o relatório. Se seu aplicativo souber que o usuário provavelmente visualizará análises (com base em padrões de navegação), pré-carregue o token durante as transições de página.
• Use a incorporação de bootstrap. O SDK oferece suporte a um padrão de bootstrap que inicializa o iframe antes que o token incorporado esteja disponível, reduzindo o tempo de carregamento percebido em 200 a 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 o cache de relatórios. Depois que um relatório é carregado, o iframe o retém na memória. Se o usuário sair e retornar, reutilize o iframe existente em vez de incorporá-lo novamente. Isso elimina totalmente o tempo de carregamento para visitas de retorno na mesma sessão.

Desempenho de back-end

• Tokens incorporados em cache. Os tokens incorporados são válidos por toda a sua vida útil (padrão 1 hora). Armazene-os em cache no Redis ou na memória e reutilize-os em solicitações para a mesma combinação de relatório/identidade.
• Geração de token em lote. Se o painel de um usuário contiver vários relatórios incorporados, gere todos os tokens incorporados em uma única chamada de API usando o recurso de vários recursos do endpoint GenerateToken.
• Monitore os limites de taxa da API. A API REST do Power BI tem limites de taxa por entidade de serviço. Monitore 429 respostas e implemente uma espera exponencial. Para aplicações de alta escala, distribua a carga entre vários principais de serviço.

Design de relatório para incorporado

Os relatórios projetados para consumo incorporado devem priorizar o desempenho em detrimento da complexidade visual:

• Limite os recursos visuais a 8 a 12 por página (cada visual gera uma consulta separada)
• Use o modo Importar em vez do DirectQuery quando possível (10-100x mais rápido)
• Dados pré-agregados na granularidade apropriada
• Evite medidas DAX complexas em páginas de destino (guarde-as para detalhes de detalhamento)
• Use marcadores para visualizações pré-computadas em vez de cálculos dinâmicos
• Teste os tempos de carregamento do relatório no nível de simultaneidade esperado, não apenas para usuário único

Para organizações que implementam análises incorporadas, a ECOSIRE fornece serviços de consultoria e desenvolvimento de arquitetura para garantir o desempenho ideal desde o primeiro dia.

---

Considerações de segurança para sistemas integrados

Segurança de token

Os tokens incorporados concedem acesso ao conteúdo do Power BI. Trate-os como credenciais confidenciais:

• Nunca exponha tokens incorporados no código-fonte do lado do cliente ou em parâmetros de URL
• Gere tokens no servidor e entregue-os por meio de endpoints de API autenticados
• Use o menor tempo de vida prático do token (o padrão de 1 hora é razoável para a maioria dos aplicativos)
• Implementar lógica de atualização de token em vez de gerar tokens de longa duração
• Monitore padrões de geração de tokens em busca de anomalias (volume incomum, IDs de relatórios inesperados)

Validação de isolamento de locatário

Para aplicações multilocatários, valide o isolamento do locatário continuamente:

• Testes automatizados que geram tokens incorporados para o Locatário A e verificam se os dados do Locatário B não estão acessíveis
• Registro de consultas para detectar tentativas de acesso a dados entre locatários
• Auditorias regulares de configuração de RLS (as funções de RLS podem ser modificadas no Power BI Desktop e enfraquecidas acidentalmente)
• Alerta sobre erros de filtro RLS (que podem indicar configuração incorreta)

Segurança de Rede

• Restringir o acesso à API REST do Power BI a intervalos de IP conhecidos usando o Acesso Condicional do Azure AD
• Use endpoints privados para conexões de gateway com fontes de dados locais
• Habilite o log de auditoria no portal de administração do Power BI para rastrear todas as chamadas de API e incorporar a geração de token
• Implemente cabeçalhos de política de segurança de conteúdo para restringir a incorporação de iframe ao domínio do seu aplicativo

---

Perguntas frequentes

Quanto custa o Power BI Embedded para um aplicativo SaaS com 10.000 usuários?

O custo depende dos usuários simultâneos, não do total de usuários. Se 5% dos seus 10.000 usuários forem simultâneos no pico (500 usuários simultâneos), você precisaria de aproximadamente capacidade F32 a aproximadamente US$ 8.200 por mês (pagamento conforme o uso). Com uma reserva (compromisso de 1 ano), isso cai para aproximadamente US$ 5.500 por mês. Seu custo real pode ser maior ou menor dependendo da complexidade do relatório, do tamanho do conjunto de dados e dos padrões de uso. Comece com F8 para um piloto, teste de carga com simultaneidade realista e dimensione com base em medições reais.

Posso usar o Power BI Embedded sem o Azure?

O Power BI Embedded requer o Azure AD para autenticação e capacidade de malha/incorporada provisionada por meio do Azure. Seu aplicativo em si pode ser hospedado em qualquer lugar (AWS, GCP, local), mas os recursos do Power BI devem estar no Azure. A entidade de serviço ou conta de usuário mestre deve estar no Azure AD e a capacidade deve ser um recurso do Azure. Para organizações sem presença existente no Azure, a configuração adiciona aproximadamente 2 a 4 horas de trabalho de configuração do Azure e gerenciamento mínimo contínuo do Azure além da própria capacidade.

Qual é a diferença entre SKUs A, SKUs EM e SKUs Fabric F do Power BI?

Os SKUs A eram a capacidade original do Power BI Embedded, provisionada por meio do Azure. Os SKUs EM eram uma opção de licenciamento para incorporação interna com o Office 365. Ambos foram substituídos pelos SKUs do Fabric F, que fornecem um modelo de capacidade unificado para todas as cargas de trabalho do Power BI e do Fabric. Os SKUs F oferecem faturamento por segundo, capacidade de pausa/retomada e uma estrutura de preços mais simples. Para novas implementações, utilize exclusivamente SKUs F. Os clientes existentes de SKU A devem planejar a migração para SKUs F para obter melhores preços e recursos.

Os usuários podem exportar dados de relatórios incorporados?

Sim, mas você controla isso através das configurações de incorporação. O JavaScript SDK permite ativar ou desativar recursos de exportação (exportar para Excel, PDF, PowerPoint) por relatório. Você também pode implementar a funcionalidade de exportação personalizada por meio da API de exportação, que oferece mais controle sobre o formato, os filtros aplicados e o registro de auditoria. Para dados confidenciais, desative a exportação integrada e forneça seu próprio mecanismo de exportação que aplique verificações de autorização e marcas d'água adicionais.

Como lidar com o desenvolvimento de relatórios em um cenário incorporado?

O desenvolvimento de relatórios segue o fluxo de trabalho padrão do Power BI: crie relatórios no Power BI Desktop, publique em um espaço de trabalho de desenvolvimento, teste com tokens incorporados de amostra, promova para produção por meio de pipelines de implantação. A principal diferença é que os relatórios incorporados precisam de testes adicionais para comportamento de RLS, desempenho sob simultaneidade, layout responsivo em tamanhos de tela e interação com a interface do usuário do seu aplicativo. Estabeleça um pipeline de CI/CD que inclua validação automatizada de RLS e testes de regressão de desempenho como parte de cada implantação de relatório.