A API REST ExecuteQueries tem capacidade de atingir integralmente a GA o que torna perceptível o aumento de soluções personalizadas para consultar conjuntos de Dados no Power BI.
A pergunta mais frequente na comunidade do Power BI é voltada para os principais cenários de uso da API REST. E a resposta é que a API ExecuteQueries é capaz de ampliar o alcance das soluções de negócios que utilizam conjuntos de dados do Power BI, porém há algumas limitações que devem ser levadas em consideração.
Ou seja, a API ExecuteQueries é uma ótima opção para recuperar pequenos blocos de dados, automatizar testes de conjuntos de dados e implementar soluções de nuvem orientadas por BI, entre outras funções.
Uma característica chave que esses cenários têm em comum é que eles funcionam em pequena escala. Por exemplo, a API ExecuteQueries restringe os resultados da consulta a 100.000 linhas ou 1.000.000 valores por consulta (o que for encontrado primeiro), portanto, claramente não é a escolha certa se você deseja ou precisa recuperar centenas de milhões de linhas. Se você quiser usar a API ExecuteQueries, deverá manter os resultados da consulta restritos.
A API ExecuteQueries também não é a escolha certa para middleware de grande escala, como aplicativos de visualização de dados que suportam milhares de usuários simultâneos, porque a API ExecuteQueries limita o número de consultas a 120 por minuto. Se um serviço ou aplicativo exceder esse limite, as consultas falharão com o código de erro HTTP 429. Esse aspecto limita a escalabilidade porque há apenas um número limitado de solicitações que você pode enviar. Atualmente, não existem planos de aumentar esse limite.
Então, o que você faz quando precisa trabalhar em uma escala maior do que a API ExecuteQueries pode suportar?
Mude para pontos de extremidade XMLA no Power BI Premium! XMLA é o protocolo de comunicação do mecanismo do Microsoft Analysis Services.
Como o diagrama a seguir ilustra, o XMLA oferece suporte a clientes avançados, clientes de terceiros, ferramentas de modelagem de dados, bem como soluções personalizadas de visualização e gerenciamento de dados na escala da capacidade Premium subjacente.
O XMLA por si só não impõe nenhum limite na carga da consulta ou nos tamanhos do conjunto de resultados. O protocolo XMLA é capaz de usar formatos de protocolo mais otimizados e evita o custo de codificação de grandes resultados em JSON.
Portanto, é a escolha certa se seus requisitos excederem os recursos da API ExecuteQueries, porque você está obtendo uma conexão cliente/servidor sem limitação para o mecanismo do Analysis Services que é executado dentro do Power BI.
Observe, no entanto, que isso normalmente requer o uso de bibliotecas de cliente do Analysis Services, que sua solução deve poder carregar para se comunicar por meio de pontos de extremidade XMLA.
Um ótimo exemplo de um serviço de camada intermediária que aproveita os pontos de extremidade XMLA é o proxy HTTP de David Browne para Power BI Premium e Azure Analysis Services.
Ele é implementado como um projeto de API ASP.NET Core 5, que permite POST de uma consulta DAX por meio de seu Endpoint principal/API/Query e retorna os resultados da consulta como um documento JSON muito semelhante à API ExecuteQueries.
Se você perceber uma taxa crescente de erros HTTP “429” em sua solução de negócios, indica que você está atingindo os limites de limitação da API ExecuteQueries e pode ser viável alternar rapidamente para o proxy HTTP para evitar a limitação via Pontos de extremidade XMLA.
A longo prazo, você pode optar por refatorar sua solução de negócios para se comunicar diretamente com os endpoints XMLA.
Embora seja relativamente simples consultar conjuntos de dados do Power BI, o tratamento de conexão XMLA é um pouco mais complexo, especialmente em escala. A API REST ExecuteQueries não requer nenhum tratamento de conexão especial, mas o protocolo XMLA exige porque é um protocolo com estado.
Seria ineficiente estabelecer uma nova conexão XMLA para cada consulta e, em seguida, fechar a conexão quando os resultados fossem recebidos.
Em vez disso, considere manter um pool de conexões abertas para que você possa enviar consultas sem sobrecarga de conexão. Observe que o Power BI pode fechar conexões abertas por vários motivos, como ao despejar temporariamente um conjunto de dados para acomodar outras cargas de trabalho na mesma capacidade Premium.
Se uma consulta falhar porque uma conexão foi perdida, considere abrir uma nova conexão e tentar novamente a consulta. Confira o arquivo ConnectionPool.cs no exemplo de proxy HTTP de David para um pool de conexões simples que pode servir como ponto de partida para sua própria implementação.
E é isso para uma introdução de alto nível à refatoração de aplicativos de visualização de dados e outras soluções de negócios se você perceber que a limitação na API REST ExecuteQueries está começando a criar problemas de escalabilidade.
A API REST ExecuteQueries é uma ótima opção em pequena escala, especialmente se você estiver usando o Power BI compartilhado. Para soluções de grande escala, na maioria das vezes, você precisará alternar para pontos de extremidade XMLA e hospedar seus conjuntos de dados no Power BI Premium. As APIs do Power BI podem oferecer suporte em qualquer escala, mas não há uma API de tamanho único.
Escolha as tecnologias certas para a finalidade e os requisitos de escalabilidade de sua solução e migre suas soluções para endpoints XMLA se quiser evitar limitações e limitações de tamanho do conjunto de resultados.
Fonte: Blog Power BI.
Autor do artigo original: Kay Unkroth.
Toda sexta-feira postamos um novo artigo sobre Power BI aqui no blog da DataEX. Fique atento as nossas redes sociais e não perca as novidades mais recentes voltadas para a ferramenta tecnológica número um da Microsoft.
