Como utilizar a licença Fabric em portais Power BI

Uma capacidade do Microsoft Fabric pode ser utilizada para hospedar e processar relatórios apresentados dentro de um portal Power BI Embedded.

Essa arquitetura permite combinar os recursos do Fabric com uma experiência personalizada para clientes, fornecedores, franquias, unidades de negócio ou usuários de uma plataforma SaaS.

Também permite utilizar capacidades menores que F64 no modelo App Owns Data, sem exigir uma licença Power BI Pro para cada visualizador final.

Visão geral: o relatório permanece publicado em um workspace associado à capacidade Fabric. O portal autentica o usuário, utiliza uma entidade de serviço para se comunicar com o Power BI e gera um token temporário para incorporar o conteúdo autorizado.

Fabric e Power BI Embedded trabalham juntos

O Microsoft Fabric fornece a capacidade de processamento e pode executar diferentes cargas de dados e analytics.

O Power BI Embedded fornece o modelo técnico para apresentar relatórios dentro de uma aplicação.

Nesse cenário:

• a capacidade F processa o conteúdo;
• o workspace organiza os relatórios e modelos;
• o Microsoft Entra ID autentica a aplicação;
• a entidade de serviço chama as APIs;
• o embed token autoriza o conteúdo;
• o portal autentica o usuário final;
• o SDK JavaScript renderiza o relatório.

Para entender as diferenças conceituais, consulte Power BI Embedded ou Microsoft Fabric: qual é a diferença?.

É necessário utilizar uma F64?

Não necessariamente.

Uma F64 ou superior é necessária quando a empresa deseja que usuários gratuitos consumam conteúdo diretamente pelo Power BI Service em um workspace de capacidade qualificada.

No modelo Embed for your customers, ou App Owns Data, os usuários finais não acessam diretamente o Power BI Service. Eles entram no portal, que controla o acesso e gera o token de incorporação.

Por isso, uma F8, F16 ou F32 pode ser usada em um portal, desde que seja suficiente para o consumo da solução.

A escolha deve considerar:

• quantidade de acessos simultâneos;
• complexidade dos modelos;
• tamanho dos relatórios;
• frequência de atualização;
• outras cargas do Fabric;
• horários de maior utilização;
• necessidade de escalabilidade.

Pré-requisitos da arquitetura

Antes da implementação, a empresa precisa ter:

1. tenant Microsoft Entra ID;
2. assinatura ativa do Azure;
3. capacidade Microsoft Fabric;
4. workspace do Power BI ou Fabric;
5. relatórios e modelos publicados;
6. aplicação Web ou portal;
7. registro de aplicativo no Microsoft Entra ID;
8. entidade de serviço;
9. backend seguro para gerar tokens;
10. usuários e regras de autorização no portal.

1. Contratar a capacidade Microsoft Fabric

A capacidade é criada no portal do Azure.

Durante a criação, são definidos assinatura, grupo de recursos, região, administrador e SKU.

As SKUs começam em F2 e crescem conforme a quantidade de CUs. Para um portal, a SKU inicial deve ser escolhida com base em testes e carga esperada, e não apenas no número total de usuários cadastrados.

Uma empresa pode ter milhares de usuários cadastrados, mas poucos acessos simultâneos. Em outro cenário, poucas pessoas podem executar consultas muito pesadas.

Veja os detalhes de aquisição e cobrança em Como funcionam as licenças do Microsoft Fabric e Power BI Embedded.

2. Associar o workspace à capacidade

Depois de criar a capacidade, o workspace que contém os relatórios deve ser associado a ela.

Essa associação define onde o conteúdo será processado.

É recomendável organizar os ambientes em workspaces separados, por exemplo:

• desenvolvimento;
• homologação;
• produção.

Também é importante controlar quem pode publicar, alterar modelos e administrar permissões.

3. Registrar a aplicação no Microsoft Entra ID

O portal precisa de uma identidade para se comunicar com as APIs do Power BI.

Para isso, é criado um registro de aplicativo no Microsoft Entra ID. Esse registro gera informações como:

• Tenant ID;
• Client ID;
• segredo ou certificado;
• identidade da aplicação.

Em produção, certificados ou mecanismos seguros de gestão de segredos são preferíveis a credenciais armazenadas diretamente no código.

4. Criar e autorizar a entidade de serviço

A entidade de serviço representa a aplicação dentro do tenant.

A Microsoft recomenda o uso de service principal para aplicações de produção no modelo App Owns Data.

O administrador deve habilitar o uso das APIs do Power BI por entidades de serviço nas configurações do tenant e limitar o acesso a um grupo de segurança específico.

Depois disso, a entidade de serviço deve receber acesso ao workspace que contém os relatórios.

A documentação oficial detalha essa arquitetura em Embed for your customers.

5. Autenticar o usuário no portal

O usuário final pode ser autenticado pelo método escolhido pela aplicação, como:

• login próprio;
• Microsoft Entra ID;
• Single Sign-On;
• identidade de cliente;
• provedor externo compatível.

O login no portal não precisa ser o mesmo login do Power BI.

Depois de autenticar o usuário, a aplicação consulta suas permissões para determinar quais menus, relatórios e dados podem ser apresentados.

6. Obter os dados de incorporação

O backend precisa identificar:

• Workspace ID;
• Report ID;
• Semantic Model ID;
• URL de incorporação;
• funções de RLS, quando aplicável.

Essas informações são obtidas por meio das APIs REST do Power BI.

O backend, e não o navegador, deve manter as credenciais da aplicação e realizar as chamadas mais sensíveis.

7. Gerar o embed token

O embed token é uma autorização temporária para o conteúdo do Power BI.

No cenário App Owns Data, o fluxo normalmente é:

1. o usuário entra no portal;
2. o backend valida suas permissões;
3. a aplicação autentica a entidade de serviço no Microsoft Entra ID;
4. recebe um token do Microsoft Entra;
5. chama a API do Power BI;
6. gera o embed token;
7. envia ao navegador apenas os parâmetros necessários;
8. o relatório é renderizado pelo SDK.

A Microsoft explica os tipos de token em Tokens de acesso da análise integrada.

8. Aplicar Row-Level Security

O RLS permite utilizar o mesmo relatório para diferentes clientes ou unidades, mostrando somente os dados autorizados.

A aplicação pode informar uma identidade efetiva durante a geração do token.

Exemplos:

• um cliente visualiza somente seus contratos;
• uma filial visualiza somente sua unidade;
• um franqueado visualiza somente suas lojas;
• a diretoria acessa a visão consolidada.

A regra de segurança deve ser aplicada no modelo semântico, e não apenas por filtros visuais no portal.

9. Incorporar o relatório no front-end

No navegador, o portal utiliza o SDK JavaScript do Power BI para renderizar o relatório.

A configuração normalmente inclui:

• tipo do conteúdo;
• Report ID;
• embed URL;
• embed token;
• tipo do token;
• preferências de navegação;
• painéis e recursos exibidos.

O portal também pode reagir a eventos, alterar filtros, navegar entre páginas e personalizar a experiência.

10. Monitorar a capacidade

Depois da publicação, é necessário acompanhar:

• utilização de CUs;
• picos de consumo;
• consultas lentas;
• atualizações demoradas;
• rejeições;
• delays interativos;
• throttling;
• períodos acima da capacidade;
• consumo por item e workspace.

Como o Fabric compartilha recursos entre diferentes cargas, processos de engenharia de dados podem afetar a experiência dos relatórios.

O dimensionamento deve ser revisto com base no uso real. A capacidade pode ser aumentada em períodos críticos e reduzida quando a demanda cair.

Arquitetura resumida

Usuário
   ↓
Portal / Aplicação
   ↓ autenticação e autorização
Backend seguro
   ↓ entidade de serviço
Microsoft Entra ID
   ↓ token do Microsoft Entra
Power BI REST APIs
   ↓ embed token
Relatório em workspace Fabric
   ↓ processamento
Capacidade Microsoft Fabric

Cuidados de segurança

Algumas práticas importantes são:

• não gerar tokens diretamente no front-end;
• não expor Client Secret no navegador;
• usar validade curta para tokens;
• validar permissões a cada solicitação;
• aplicar RLS no modelo;
• proteger logs e dados pessoais;
• revogar usuários desligados;
• separar desenvolvimento e produção;
• monitorar acessos e falhas;
• utilizar HTTPS e políticas seguras de sessão.

Desenvolver um portal próprio ou utilizar uma plataforma pronta?

Uma empresa pode desenvolver toda essa estrutura internamente. Isso oferece flexibilidade, mas exige investimento contínuo em desenvolvimento, segurança, monitoramento e manutenção.

Outra opção é utilizar um portal já preparado para o ecossistema Power BI e Microsoft Fabric.

Power Insight: portal pronto para capacidades Fabric

A Power Insight permite utilizar relatórios hospedados em capacidades Microsoft Fabric dentro de um portal Power BI Embedded pronto para o mercado.

A plataforma reúne recursos como:

• autenticação de usuários;
• controle de grupos e permissões;
• menus personalizados;
• domínio próprio e white-label;
• integração com Microsoft Entra ID;
• Single Sign-On;
• aplicação de RLS;
• auditoria de acessos;
• inventário de relatórios;
• monitoramento de atualizações;
• acompanhamento de capacidades Fabric;
• modo TV e aplicativo;
• envio programado;
• integração com inteligência artificial.

Com isso, a empresa pode utilizar uma capacidade F menor que F64 no modelo App Owns Data e distribuir relatórios sem construir do zero toda a camada de portal.

Conheça o Portal Power BI Embedded da Power Insight e veja como utilizar sua capacidade Microsoft Fabric em um ambiente personalizado, seguro e preparado para crescer.

Conclusão

Uma capacidade Microsoft Fabric pode hospedar relatórios incorporados em portais por meio do Power BI Embedded.

A implementação exige associar o workspace à capacidade, registrar a aplicação no Microsoft Entra ID, configurar a entidade de serviço, gerar tokens no backend e aplicar corretamente as regras de segurança.

A F64 não é obrigatória no modelo App Owns Data. Capacidades menores podem ser utilizadas, desde que atendam à carga da solução e sejam monitoradas adequadamente.