Power PlatformPower BIAnálise

Pagar caro por um BI que poucas pessoas veem virou normal. Não deveria

Como levar dados do Power BI para HTML e JavaScript com a Execute Queries API, por que capacidade dedicada raramente faz sentido para equipes pequenas e onde a IA realmente acelera o projeto.

Macareno30 de setembro de 20267 min de leitura

Toda conversa sobre Power BI fora do Power BI começa igual. Alguém quer "o dashboard dentro do portal": na intranet, no SharePoint, com as cores da empresa, sem aquele iframe que entrega que o relatório mora em outro lugar. A equipe técnica abre a documentação, encontra Embedded, capacidades dedicadas, tokens, e em meia hora a reunião já está discutindo uma assinatura mensal que ninguém tinha orçado.

Passamos por esse roteiro há pouco. Analisamos o relatório existente, cruzamos com a lista de melhorias do cliente, desenhamos arquitetura, modelo e estimativa. No meio do caminho, uma pergunta simples reorganizou tudo: quem, afinal, vai olhar esses números?

A resposta foi: poucas pessoas. Uma equipe pequena que usa o painel para montar um relatório fixo em PowerPoint, enviado para as áreas. Isso mudou a arquitetura, o licenciamento e até o papel da IA no projeto. Vamos por partes.

Cinco portas para tirar o Power BI do Power BI

Existem basicamente cinco maneiras de levar conteúdo do Power BI para uma página web, e elas não são variações da mesma coisa:

Caminho	Quem vê	Licença de quem vê	Controle visual
Publish to web	Qualquer pessoa com o link	Nenhuma	Nenhum, e os dados ficam públicos
Secure embed	Usuários da organização	Pro ou PPU	Iframe, sem código
Embed for your organization	Usuários da organização	Pro ou PPU	Iframe controlado por JavaScript
Embed for your customers	Usuários externos	Nenhuma (paga-se capacidade)	Iframe controlado por JavaScript
Execute Queries API	Quem a sua aplicação autenticar	Pro ou PPU	Total: você desenha

As quatro primeiras têm uma coisa em comum: o que aparece na tela é um iframe servido pelo app.powerbi.com. Dá para filtrar, trocar de página e capturar eventos pelo SDK, mas o CSS do seu portal não entra lá dentro. Se o requisito é "parecer nativo", sobra a quinta porta: pedir os números e desenhar você mesmo.

A API que devolve números, não relatórios

A Execute Queries API recebe uma consulta DAX e devolve linhas em JSON. Dentro de um web part SPFx, o token sai da própria sessão do Microsoft 365 do usuário, com a permissão Dataset.Read.All. Assim a consulta roda com a identidade de quem abriu a página, e a segurança por linha do modelo é aplicada sem nenhum backend extra.

Os limites precisam estar na mesa desde o primeiro dia:

uma consulta e uma tabela por chamada;
no máximo 100 mil linhas ou 1 milhão de valores por consulta;
15 MB por resposta;
120 consultas por minuto por usuário.

É uma API para indicadores e tabelas agregadas, não para extração em massa. E ela tem uma pegadinha: se a consulta passa do limite, a resposta vem com HTTP 200 e dados parciais. O status diz que deu certo. O erro está escondido dentro do JSON.

Quando não existe relatório no meio, o modelo semântico vira contrato. Renomear uma medida passa a quebrar uma tela.

O modelo que só funcionava porque ninguém olhava de perto

O modelo que encontramos fazia o relatório funcionar, mas foi construído em volta dos visuais e não como uma fonte de dados. Tabelas de pessoas sem relacionamento com a tabela de eventos. Colunas calculadas buscando atributos linha a linha. A mesma normalização de e-mail repetida em uma dúzia de medidas. Tabelas automáticas de data escondidas por todo lado.

Dentro do Power BI, os visuais disfarçam tudo isso. Pela API, cada atalho vira consulta lenta, número divergente ou medida impossível de filtrar. A migração, portanto, não é "trocar a tela": é refatorar o modelo para esquema estrela, criar medidas explícitas numa pasta dedicada à API e validar os números, KPI por KPI, contra o relatório antigo.

Uma dica que economiza horas: o Performance Analyzer do Power BI Desktop mostra a consulta DAX exata de cada visual. É o ponto de partida perfeito para o catálogo de consultas do web part.

A licença que ninguém precisava comprar

Aqui a pergunta "quem vai olhar?" pesou mais. O Power BI Pro custa US$ 14 por usuário por mês desde abril de 2025. Uma capacidade Fabric F64 libera a visualização para usuários com licença gratuita, mas custa perto de US$ 5 mil por mês na reserva anual. A conta só fecha quando centenas de pessoas consomem o conteúdo.

Para uma equipe pequena, a conta é outra: algumas licenças Pro, ou nenhum custo extra se as pessoas já tiverem Microsoft 365 E5. E as áreas que recebem o relatório não abrem o Power BI; recebem um arquivo. (Vale sempre confirmar esse modelo de distribuição com o parceiro de licenciamento.)

Isso também muda como exportar. A exportação automática nativa para PowerPoint (ExportToFile) exige capacidade dedicada. Mas o web part já tem os dados de cada consulta na memória, e uma biblioteca como a PptxGenJS gera o .pptx no próprio navegador, com gráficos nativos e editáveis e o template visual da empresa. O botão "Exportar para PowerPoint" custa horas de desenvolvimento, não assinatura.

Fabric: presente em tudo, obrigatório em quase nada

Hoje o Power BI é uma das cargas de trabalho do Microsoft Fabric. Workspaces, modelos e configurações de tenant já vivem no portal do Fabric, mesmo para quem acha que "não usa Fabric". Ainda assim, nada nessa arquitetura exigiu capacidade Fabric: a API funciona com licença Pro em capacidade compartilhada.

Onde ele fez sentido foi num lugar inesperado: a telemetria do portal. Os eventos de navegação eram gravados numa lista do SharePoint, que já acumulava dezenas de milhares de itens por mês. O cliente queria medir tempo de permanência, o que multiplica esse volume. Uma lista não foi feita para isso. Para esse caso específico, uma capacidade F2, a menor da família, com Eventstream ou Lakehouse é a resposta honesta.

Quando a IA entra na planilha de horas

A Microsoft publicou o Power BI Authoring MCP, ainda em preview: um servidor que permite a um agente de IA criar tabelas, medidas, relacionamentos e papéis de segurança em linguagem natural, trabalhando sobre arquivos PBIP versionados no Git e executando DAX para validar o resultado. Ele não cria visuais, o que, nesse projeto, era irrelevante: os visuais estavam no SPFx.

Com IA no modelo, no código do web part e na classificação de assuntos do chatbot, a estimativa caiu cerca de 40%. Mas é preciso ser honesto sobre onde essa economia mora. A evidência é mista: um experimento do GitHub mediu desenvolvedores 55% mais rápidos numa tarefa isolada, enquanto um estudo do METR em 2025 encontrou desenvolvedores experientes 19% mais lentos trabalhando em código que já conheciam.

Acelera muito	Quase não acelera
Medidas DAX e refatoração do modelo	Respostas do cliente
Componentes e serviços do web part	Homologação e conferência de números
Geração do PowerPoint	Aprovação de permissões e acessos
Dicionário de assuntos a partir de milhares de mensagens	Esperar a nova telemetria acumular dados

A IA encurta a construção. O relógio do projeto continua sendo, em boa parte, o relógio das pessoas.

Antes de assinar, pergunte quem vai olhar

A arquitetura certa não saiu de uma comparação de SKUs nem de uma lista de features. Saiu de uma pergunta sobre gente: quantas pessoas vão ver isso, e o que elas fazem depois. Poucas pessoas montando um relatório para as áreas não pedem capacidade dedicada; pedem um modelo limpo, uma API bem usada e um botão que gera o PowerPoint do mês.

Antes de discutir licença, pergunte quem está do outro lado da tela. Muitas vezes a resposta está num e-mail com um .pptx anexado.

Se você gosta desse tipo de bastidor, com números reais e sem hype, assine a newsletter do macareno.net e receba os próximos artigos em primeira mão.

Fontes