Continue no Power BI via OData

Selo de estado: Preview (teto atual do produto) · Curso ACD-350 — Rota rápida: do Power BI/Excel ao ingestia.bi · Aula 2 de 5 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai conectar o Power BI ao Gold pelo feed OData, confirmar que o filtro está dobrando para o servidor (query folding) e saber exatamente onde essa superfície para — ela é Preview.

Vídeo#

Identificador no manifesto: acd-350-02-continue-usando-power-bi-odata · duração-alvo 8 min · tela do produto: /connect.

Roteiro:

Conteúdo#

Esta é a aula que sustenta a frase "você pode continuar usando o Power BI". Ela é verdadeira com uma condição que a doc declara em voz alta: a superfície que entrega isso é o feed OData v4, e o estado dela é Preview — funciona e é documentado, sem SLA. A conexão real fim-a-fim com Power BI e Excel (folding e refresh incremental) é validada continuamente por gate humano, não por um número de uptime.

Mapa de conceitos: o que vira o quê

Como aparece no produto

Em /connect ("Conectar BI") o produto mostra a URL base da API, o nome do seu dataset Gold e um cartão por ferramenta — Power BI, Tableau, Looker Studio, Excel. O caminho simples é Obter Dados → Feed OData com a URL …/api/v1/odata?api_key=SUA_CHAVE e autenticação Anônima (lembrando: chave na URL é um segredo na URL). O caminho recomendado passa a chave no cabeçalho:

let
    Chave = "SUA_CHAVE",
    Fonte = OData.Feed("https://ingestia.io/api/v1/odata", null, [
        Headers = [ #"Authorization" = "Bearer " & Chave ],
        Implementation = "2.0"
    ]),
    Tabela = Fonte{[Name = "vendas"]}[Data]
in
    Tabela

Implementation = "2.0" não é detalhe: é ele que faz o Power Query falar OData v4 e dobrar filtros e projeções para o servidor.

Exemplo Aurora

No workspace Aurora Varejo (prefixo aurora), as tabelas publicadas de aurora_gold aparecem como EntitySets do feed. Uma leitura típica, do jeito que o Power Query a dobra:

curl -H "Authorization: Bearer ing_live_..." \
  "https://ingestia.io/api/v1/odata/vendas?\$select=data,valor&\$filter=data ge 2026-01-01&\$orderby=data&\$count=true"

Traduzindo para o que você faz na interface: escolher colunas virou $select; filtrar linhas virou $filter; ordenar virou $orderby; manter primeiras N linhas viraria $top. A resposta é paginada em páginas de até 1.000 linhas com @odata.nextLink — o Power BI e o Excel seguem o link sozinhos até o fim. Siga sempre o nextLink exatamente como recebido: ele carrega um $skiptoken opaco, e um token adulterado responde 400.

O que NÃO existe nesta superfície

• Subset OData, não OData inteiro: sem $expand, $apply, $search, $compute, sem lambdas (any/all) e sem aritmética dentro do filtro; em texto, só contains, startswith e endswith. Fora do subset = 501 explícito. $format: apenas JSON.
• Sem recorte por membro neste canal. A chave é de nível workspace e enxerga todos os marts publicados; chave por membro com segurança por linha é Roadmap. Colunas marcadas como PII nunca saem pela API — nem no $metadata.
• Sem colunas STRUCT/RECORD no feed: publique colunas planas.
• Sem API REST de consulta liberada. /api/v1/query e /api/v1/tables estão fora de GA — o caminho recomendado hoje é justamente o OData.
• Sem escrita. A plataforma é somente leitura neste canal; INSERT/UPDATE é Roadmap.

Custo, quota e falha

Você paga pelos bytes realmente processados; o cabeçalho x-ingestia-cost-brl mostra o valor, hoje uma projeção, não preço faturado garantido. Cada chamada entra na auditoria como api.odata.read, separável do BI nativo. A quota é de 120 requisições/min por chave (240/min por workspace) e é separada do resto da plataforma — puxar dados pelo Power BI não degrada o painel nativo; estouro responde 429 com Retry-After. Profundidade máxima: 1.000.000 de linhas por consulta (acima, 400 pedindo filtro). Se a nuvem própria do cliente cair ou o datalake não estiver provisionado, o feed responde 503 — nunca uma coleção vazia, que faria o Excel concluir que "a tabela esvaziou".

Estado da capacidade

OData v4 endurecido + kit Power BI/Excel é a capacidade C10.6, claim Preview: sem SLA, sujeita a ajuste, com a conexão real sob validação humana contínua. Trate como "funciona e é documentado", não como "pode virar o canal crítico da diretoria amanhã".

Faça você mesmo#

No workspace de treino Aurora Varejo (abra /connect no console):

1. Crie uma chave de API somente leitura e copie a URL base da API e o nome do dataset Gold mostrados na tela.
2. No Power BI Desktop, use Obter Dados → Consulta em Branco → Editor Avançado e cole o let desta aula, trocando SUA_CHAVE pela sua chave e "vendas" pelo EntitySet que aparecer na lista.
3. Remova as colunas que você não vai usar e filtre data por um intervalo (ex.: a partir de 2026-01-01). Clique com o botão direito na última etapa → Exibir consulta nativa, quando disponível, para confirmar que virou $select + $filter.
4. Peça de propósito algo fora do subset — por exemplo um filtro com aritmética (valor * 2 > 300) — e observe o 501 com a lista do que é suportado.
5. Crie os parâmetros RangeStart e RangeEnd (Data/Hora), filtre a tabela por each [data] >= RangeStart and [data] < RangeEnd e configure a política de refresh incremental.
6. Aponte esse filtro para uma coluna de partição e compare o comportamento: a janela lida (e o byte pago) deve cair.
7. Confirme no console que as leituras apareceram na auditoria como api.odata.read.
8. Anote, em uma linha, o que você não conseguiu dobrar — é o insumo do plano de migração da aula 5.

Você terminou quando o Power BI carregar uma tabela do Gold da Aurora com filtro dobrado para o servidor, você tiver provocado um 501 de propósito e o refresh incremental estiver configurado com RangeStart/RangeEnd.

Checagem rápida#

Três perguntas no final da aula, corrigidas no servidor. A aula só conta como concluída depois da checagem.

Documentação relacionada#

• desenvolvedores/odata-powerbi-excel
• desenvolvedores/autenticacao
• suporte/status-e-limitacoes

Capacidades ensinadas#

C10.6 — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".