Solucionar problemas de conectividade de ponto de extremidade XMLA

Os pontos de extremidade XMLA do Power BI usam o protocolo de comunicação nativo do Analysis Services para acessar os modelos semânticos do Power BI. Por isso, a solução de problemas do ponto de extremidade XMLA é muito parecida com a solução de problemas de uma conexão do Analysis Services típica. No entanto, algumas diferenças em relação a dependências específicas do Power BI se aplicam.

Antes de começar

Antes de solucionar problemas de um cenário do ponto de extremidade XMLA, revise os conceitos básicos abordados em Conectividade do modelo semântico com o ponto de extremidade XMLA. A maioria dos casos de uso de pontos de extremidade XMLA mais comuns é abordada aqui. Outros guias de solução de problemas do Power BI, como Solucionar problemas de gateways – Power BI e Solucionar problemas do recurso Analisar no Excel, também podem ser úteis.

Habilitar o ponto de extremidade XMLA

O ponto de extremidade XMLA pode ser habilitado nas capacidades Power BI Premium, Premium por usuário e Power BI Embedded. Em capacidades menores, como uma A1 com apenas 2,5 GB de memória, você poderá encontrar um erro nas configurações de capacidade ao tentar definir o ponto de extremidade XMLA para Leitura/Gravação e selecionar Aplicar. O erro indica "Houve um problema com as configurações da carga de trabalho. Tente novamente em alguns minutos.".

Confira algumas opções:

• Limite o consumo de memória de outros serviços na capacidade, como fluxos de dados, a 40% ou menos, ou desabilite completamente um serviço desnecessário.
• Atualize a capacidade para um SKU maior. Por exemplo, atualizar de uma capacidade A1 para A3 resolve o problema de configuração sem precisar desabilitar os fluxos de dados.

Você também deve habilitar a configuração Exportar dados no nível do locatário no portal de administração do Power BI. Essa configuração também é necessária para o recurso Analisar no Excel.

Estabelecer uma conexão cliente

Após a habilitação do ponto de extremidade XMLA, recomendamos testar a conectividade com um espaço de trabalho na capacidade. Para saber mais, confira Conectar a um workspace Premium. Além disso, leia a seção Requisitos de conexão para obter dicas úteis e informações sobre as limitações de conectividade XMLA atuais.

Conectar com uma entidade de serviço

Se você habilitou configurações de locatário para permitir que entidades de serviço usem APIs do Power BI, conforme descrito em Habilitar entidades de serviço, poderá se conectar a um ponto de extremidade XMLA usando uma entidade de serviço. Tenha em mente que a entidade de serviço exige o mesmo nível de permissões de acesso no workspace ou no modelo semântico que os usuários comuns.

Para usar uma entidade de serviço, especifique as informações de identidade do aplicativo na cadeia de conexão, como:

• Aplicativo de ID - de usuário:appid@tenantid

• Senha

  • cert:impressão digital (recomendado para segurança)

    Data Source=powerbi://api.powerbi.com/v1.0/myorg/Contoso;Initial Catalog=PowerBI_Dataset;User ID=app:<appid>;Password=cert:<thumbprint>;

  • Segredo do aplicativo

    Data Source=powerbi://api.powerbi.com/v1.0/myorg/Contoso;Initial Catalog=PowerBI_Dataset;User ID=app:<appid>;Password=<secret>;

Se você receber o seguinte erro:

“Não podemos nos conectar ao modelo semântico devido a informações de conta incompletas. Para entidades de serviço, especifique a ID do locatário junto com a ID do aplicativo usando o formato aplicativo:<IDdoApp>@<IDdoLocatario> e tente novamente."

Especifique a ID do locatário com a ID do aplicativo usando o formato correto.

Também é válido especificar a ID do aplicativo sem a ID do locatário. No entanto, nesse caso, você deve substituir o alias myorg na URL da fonte de dados pela ID de locatário real. O Power BI pode localizar a entidade de serviço no locatário correto. Como prática recomendada, use o alias myorg e especifique a ID do locatário com a ID do aplicativo no parâmetro ID de usuário.

Conectando-se com o Microsoft Entra B2B

Com o suporte de B2B (entre empresas) do Microsoft Entra no Power BI, você pode fornecer aos usuários convidados externos acesso aos modelos semânticos por meio do ponto de extremidade XMLA. Habilite a configuração Compartilhar conteúdo com usuários externos no portal de administração do Power BI. Para saber mais, confira Distribuição do conteúdo do Power BI para usuários convidados externos com o Microsoft Entra B2B.

Como implantar um modelo semântico

Você pode implantar um projeto de modelo tabular do Visual Studio (SSDT) em um workspace atribuído a uma capacidade Premium, de forma muito parecida com um recurso de servidor no Azure Analysis Services. No entanto, durante a implantação, há algumas considerações adicionais. Confira a seção Implantar projetos de modelo do Visual Studio (SSDT) no artigo Conectividade do modelo semântico com o ponto de extremidade XMLA.

Implantar um novo modelo

Na configuração padrão, o Visual Studio tenta processar o modelo como parte da operação de implantação para carregar os dados no modelo semântico por meio das fontes de dados. Conforme descrito em Implantar projetos de modelo do Visual Studio (SSDT), essa operação pode falhar porque as credenciais da fonte de dados não podem ser especificadas como parte da operação de implantação. Em vez disso, se as credenciais da fonte de dados ainda não estiverem definidas para nenhum dos modelos semânticos existentes, você precisará especificar as credenciais da fonte de dados nas configurações do modelo semântico usando a interface do usuário do Power BI (Modelos semânticos>Configurações>Credenciais da fonte de dados>Editar credenciais). Após a definição das credenciais da fonte de dados, o Power BI poderá aplicar as credenciais automaticamente a qualquer novo modelo semântico, depois que a implantação de metadados for bem-sucedida e o modelo semântico for criado.

Se o Power BI não puder associar o novo modelo semântico às credenciais da fonte de dados, você receberá um erro indicando “Não é possível processar o banco de dados. Motivo: falha ao salvar modificações no servidor." com o código de erro "DMTS_DatasourceHasNoCredentialError", conforme mostrado abaixo:

Para evitar a falha de processamento, defina as Opções de Implantação>Opções de Processamento para Não Processar, como mostrado na imagem a seguir. O Visual Studio implanta apenas os metadados. Em seguida, você poderá configurar as credenciais da fonte de dados e clicar em Atualizar agora no modelo semântico na interface do usuário do Power BI.

Novo projeto com base em um modelo semântico existente

Não há suporte para a criação de um projeto de tabela no Visual Studio por meio da importação dos metadados de um modelo semântico existente. No entanto, você pode se conectar ao modelo semântico usando o SQL Server Management Studio, gerar scripts com os metadados e reutilizá-los em outros projetos de tabelas.

Como migrar um modelo semântico para o Power BI

É recomendável especificar o nível de compatibilidade 1500 (ou superior) para modelos tabulares. Esse nível de compatibilidade oferece suporte à maioria dos recursos e tipos de fonte de dados. Os níveis de compatibilidade posteriores são compatíveis com níveis anteriores.

Provedores de dados com suporte

No nível de compatibilidade 1500, o Power BI dá suporte aos seguintes tipos de fonte de dados:

• Fontes de dados do provedor (herdadas com uma cadeia de conexão nos metadados de modelo).
• Fontes de dados estruturadas (introduzidas com o nível de compatibilidade 1400).
• Declarações M embutidas de fontes de dados (conforme o Power BI Desktop as declara).

Recomendamos que você use fontes de dados estruturadas, que o Visual Studio criará por padrão ao passar por Importar fluxo de dados. No entanto, se você estiver planejando migrar para o Power BI um modelo existente que usa uma fonte de dados de provedor, verifique se essa fonte depende de um provedor de dados com suporte. Especificamente, o Driver do Microsoft OLE DB para SQL Server e qualquer driver ODBC de terceiros. Para o Driver do OLE DB para SQL Server, você deve alternar a definição da fonte de dados para o Provedor de Dados .NET Framework para SQL Server. Para drivers ODBC de terceiros que podem estar indisponíveis no serviço do Power BI, você deve alternar para uma definição de fonte de dados estruturada.

Também recomendamos substituir o Driver do Microsoft OLE DB para SQL Server (SQLNCLI11) desatualizado em suas definições de fonte de dados do SQL Server pelo Provedor de Dados .NET Framework para SQL Server.

A tabela a seguir fornece um exemplo de cadeia de conexão do Provedor de Dados .NET Framework para SQL Server que substitui uma cadeia de conexão correspondente para o Driver do OLE DB para SQL Server.

Fontes de partição de referência cruzada

Assim como há vários tipos de fonte de dados, também há vários tipos de fonte de partição que um modelo tabular pode incluir a fim de importar dados para uma tabela. Especificamente, uma partição pode usar uma fonte de partição de consulta ou uma fonte de partição M. Esses tipos de fonte de partição, por sua vez, podem referenciar fontes de dados de provedor ou fontes de dados estruturadas. Enquanto os modelos tabulares no Azure Analysis Services dão suporte à referência cruzada desses vários tipos de partição e fontes de dados, o Power BI aplica uma relação mais estrita. As fontes de partição de consulta devem referenciar fontes de dados de provedor, e as fontes de partição M devem referenciar fontes de dados estruturadas. Outras combinações que não têm suporte no Power BI. Caso você queira migrar um modelo semântico de referência cruzada, a seguinte tabela descreve as configurações com suporte:

Fontes de dados e representação

As configurações de representação que você pode definir para fontes de dados do provedor não são relevantes para o Power BI. O Power BI usa um mecanismo diferente baseado nas configurações do modelo semântico para gerenciar as credenciais da fonte de dados. Por isso, selecione Conta de Serviço se você estiver criando uma Fonte de dados de provedor.

Processamento refinado

Quando é disparada uma atualização agendada ou sob demanda no Power BI, ele normalmente atualiza todo o modelo semântico. Em muitos casos, é mais eficiente executar atualizações de forma mais seletiva. Você pode realizar tarefas de processamento refinado no SSMS (SQL Server Management Studio), conforme mostrado abaixo ou usando ferramentas ou scripts de terceiros.

Substituições no comando Refresh no TMSL

Substituições no Comando Refresh (TMSL) permitem que os usuários escolham uma definição de consulta de partição diferente ou uma definição de fonte de dados para a operação de atualização.

Assinaturas de email

Os modelos semânticos que são atualizados por meio de um ponto de extremidade XMLA não disparam uma assinatura de email.

Erros na capacidade do Premium

Erro de conexão com o servidor no SSMS

Ao se conectar a um workspace do Power BI com SSMS (SQL Server Management Studio), o seguinte erro pode ser exibido:

TITLE: Connect to Server
------------------------------
Cannot connect to powerbi://api.powerbi.com/v1.0/[tenant name]/[workspace name].
------------------------------
ADDITIONAL INFORMATION: 
The remote server returned an error: (400) Bad Request.
Technical Details:
RootActivityId: 
Date (UTC): 10/6/2021 1:03:25 AM (Microsoft.AnalysisServices.AdomdClient)
------------------------------
The remote server returned an error: (400) Bad Request. (System)

Ao se conectar a um workspace do Power BI com SSMS, verifique o seguinte:

• A configuração do ponto de extremidade XMLA está habilitada para a capacidade do locatário. Para saber mais, consulte Habilitar leitura e gravação de XMLA.
• A configuração Permitir pontos de extremidade XMLA e Analisar no Excel com modelos semânticos locais está habilitada em Configurações do locatário.
• Você está usando a versão mais recente do SSMS. Baixe a o mais recente.

Execução de consulta no SSMS

Quando conectado a um workspace em uma capacidade do Power BI Premium ou do Power BI Embedded, o SQL Server Management Studio pode exibir o seguinte erro:

Executing the query ...
Error -1052311437: We had to move the session with ID '<Session ID>' to another Power BI Premium node. Moving the session temporarily interrupted this trace - tracing will resume automatically as soon as the session has been fully moved to the new node.

Esta é uma mensagem informativa que pode ser ignorada no SSMS 18.8 e superiores porque as bibliotecas de clientes serão reconectadas automaticamente. Observe que as bibliotecas de clientes instaladas com o SSMS v18.7.1 ou inferiores não são compatíveis com o rastreamento de sessão. Baixe o SSMS mais recente.

Executando um comando grande usando o ponto de extremidade XMLA

Ao executar um comando grande usando o ponto de extremidade XMLA, você pode encontrar o seguinte erro:

Executing the query ...
Error -1052311437:
The remote server returned an error: (400) Bad Request.

Technical Details:
RootActivityId: 3716c0f7-3d01-4595-8061-e6b2bd9f3428
Date (UTC): 11/13/2020 7:57:16 PM
Run complete

Ao usar o SSMS v18.7.1 ou anterior para executar uma operação de atualização de execução prolongada (>1 minuto) em um modelo semântico de uma capacidade do Power BI Premium ou do Power BI Embedded, o SSMS poderá exibir essa mensagem de erro, ainda que a operação de atualização tenha sucesso. Isso ocorre devido a um problema conhecido nas bibliotecas de cliente em que o status da solicitação de atualização é incorretamente rastreado. Isso é resolvido no SSMS 18,8 e superior. Baixe o SSMS mais recente.

Esse erro também pode ocorrer quando uma solicitação muito grande precisa ser redirecionada para um nó diferente no cluster Premium. Em geral, ela é vista quando você tenta criar ou alterar um modelo semântico usando um script TMSL grande. Nesses casos, o erro geralmente pode ser evitado especificando o Catálogo Inicial para o nome do banco de dados antes de executar o comando.

Ao criar um banco de dados, você pode criar um modelo semântico vazio, por exemplo:

{   
  "create": {   
    "database": {   
      "name": "DatabaseName"
    }   
  }   
} 

Depois de criar o modelo semântico, especifique o Catálogo Inicial e faça alterações no modelo semântico.

Outros aplicativos e ferramentas de cliente

Aplicativos cliente e ferramentas como o Excel, o Power BI Desktop, o SSMS ou ferramentas externas que se conectam e trabalham com modelos semânticos em capacidades do Power BI Premium podem causar o seguinte erro: O servidor remoto retornou um erro: (400) Solicitação Incorreta.. O erro pode ser causado especialmente se uma consulta DAX subjacente ou um comando XMLA estiver em execução longa. Para atenuar possíveis erros, use os aplicativos e ferramentas mais recentes que instalam versões recentes das bibliotecas de clientes do Analysis Services com atualizações regulares. Seja qual for o aplicativo ou a ferramenta, as versões mínimas necessárias da biblioteca de clientes para se conectar aos modelos semânticos e trabalhar com eles em uma capacidade Premium por meio do ponto de extremidade XMLA são:

Editando as associações de função no SSMS

Ao usar o SSMS (SQL Server Management Studio) versão 18.8 para editar uma associação a uma função em um modelo semântico, o SSMS poderá exibir o seguinte erro:

Failed to save modifications to the server. 
Error returned: ‘Metadata change of current operation cannot be resolved, please check the command or try again later.’ 

Isso ocorre devido a um problema conhecido na API REST dos serviços de aplicativos. Isso será resolvido em uma versão futura. Enquanto isso, para contornar esse erro, em Propriedades de função, clique em Script e insira e execute o seguinte comando TMSL:

{ 
  "createOrReplace": { 
    "object": { 
      "database": "AdventureWorks", 
      "role": "Role" 
    }, 
    "role": { 
      "name": "Role", 
      "modelPermission": "read", 
      "members": [ 
        { 
          "memberName": "xxxx", 
          "identityProvider": "AzureAD" 
        }, 
        { 
          "memberName": “xxxx” 
          "identityProvider": "AzureAD" 
        } 
      ] 
    } 
  } 
} 

Erro de publicação – Modelo semântico com conexão dinâmica

Ao publicar novamente um modelo semântico com conexão dinâmica usando o conector do Analysis Services, o erro “Há um modelo semântico/relatório existente com o mesmo nome. Exclua ou renomeie o modelo semântico existente e tente novamente.” poderá ser exibido.

Isso ocorre porque o modelo semântico que está sendo publicado tem uma cadeia de conexão diferente, mas o mesmo nome do modelo semântico existente. Para resolver esse problema, exclua ou renomeie o modelo semântico existente. Além disso, republique todos os aplicativos que dependem do relatório. Se necessário, os usuários downstream devem ser informados para atualizar qualquer indicador com o novo endereço de relatório, a fim de garantir que eles acessem o relatório mais recente.

O modelo semântico conectado ao vivo não pode ser carregado

Os usuários que tentam criar um novo modelo Live Connected ou abrir um modelo Live Connected existente, usando as versões de março de 2024 ou posteriores do Power BI Desktop, podem encontrar um erro semelhante ao seguinte: "Não foi possível conectar ao seu modelo no serviço do Power BI. O conjunto de dados pode ter sido excluído, renomeado, movido ou é possível que você não tenha permissão para acessá-lo."

O erro pode ocorrer quando um proxy é configurado no ambiente do usuário e o proxy está impedindo o acesso ao serviço do Power BI. A partir da versão de março de 2024 do Power BI Desktop, o ambiente do usuário deve permitir conexões com o serviço do Power BI no ponto de extremidade *.pbidedicated.windows.net ou com os pontos de extremidade de serviço do Power BI correspondentes para nuvens soberanas.

Para validar se o problema é resultado de configurações de proxy, experimente o conector SQL Server Analysis Services no Power BI Desktop ou qualquer ferramenta externa própria ou de terceiros, como SQL Server Management Studio, para se conectar a qualquer workspace premium.

Consulte a seção estabelecendo uma conexão de cliente neste artigo para obter mais informações sobre como testar a conectividade XML/A geral.

A pasta de trabalho do Excel não abre

A pasta de trabalho do Excel pode falhar ao abrir com o erro "Falha na inicialização da fonte de dados. Verifique o servidor de banco de dados ou entre em contato com o administrador do banco de dados.". Se a pasta de trabalho contiver uma conexão com um modelo semântico do Power BI, verifique se a cadeia de conexão contém a propriedade "Catalog Rebound=True". Se a propriedade for encontrada, remova-a, salve a pasta de trabalho e tente abri-la novamente.

A propriedade "Catalog Rebound=True" é adicionada automaticamente pelo MSOLAP (Provedor OLE DB) do Analysis Services em versões mais recentes do Excel quando a conexão com o modelo semântico do Power BI é otimizada pelo provedor. Como a propriedade é mantida na pasta de trabalho, quando a mesma pasta de trabalho é aberta no Excel que está usando uma versão mais antiga do provedor que não dá suporte à otimização, o Excel não abrirá a pasta de trabalho.

"Catalog Rebound" destina-se apenas ao uso interno.

Alias de workspace/servidor

Ao contrário do Azure Analysis Services, não há suporte para aliases de nome de servidor para workspaces Premium.

DISCOVER_M_EXPRESSIONS

No momento, não há suporte para a DMV (exibição de gerenciamento de dados) DISCOVER_M_EXPRESSIONS no Power BI usando o ponto de extremidade XMLA. Os aplicativos podem usar o TOM (modelo de objetos Tabular) para obter as expressões M usadas pelo modelo de dados.

Limite de memória do comando de administração de recursos no Premium

As capacidades Premium usam a administração de recursos para garantir que nenhuma operação de modelo semântico exceda a quantidade de recursos de memória disponíveis para a capacidade, determinada pelo SKU. Por exemplo, uma assinatura P1 tem um limite de memória efetivo por artefato de 25 GB; para uma assinatura P2, o limite é de 50 GB; e, para uma assinatura P3, o limite é de 100 GB. Além do tamanho do modelo semântico (banco de dados), o limite de memória efetivo também se aplica às operações subjacentes de comando do modelo semântico, como Criar, Alterar e Atualizar.

O limite de memória efetivo para um comando é baseado no menor limite de memória da capacidade (determinado pelo SKU) ou no valor da propriedade XMLA DbpropMsmdRequestMemoryLimit.

Por exemplo, para uma capacidade P1, se:

• DbpropMsmdRequestMemoryLimit = 0 (ou não especificado), o limite de memória efetivo para o comando é de 25 GB.

• DbpropMsmdRequestMemoryLimit = 5 GB, o limite de memória efetivo para o comando é de 5 GB.

• DbpropMsmdRequestMemoryLimit = 50 GB, o limite de memória efetivo para o comando é de 25 GB.

Normalmente, o limite de memória efetivo para um comando é calculado com base na memória permitida para o modelo semântico pela capacidade (25 GB, 50 GB, 100 GB) e na quantidade de memória que o modelo semântico já está consumindo quando o comando começa a ser executado. Por exemplo, um modelo semântico que usa 12 GB em uma capacidade P1 permite um limite de memória efetivo de 13 GB para um novo comando. No entanto, o limite de memória efetivo pode ser mais restrito pela propriedade XMLA DbPropMsmdRequestMemoryLimit quando opcionalmente especificado por um aplicativo. Usando o exemplo anterior, se 10 GB for especificado na propriedade DbPropMsmdRequestMemoryLimit, o limite efetivo do comando terá uma redução adicional de 10 GB.

Se a operação de comando tentar consumir mais memória do que o permitido pelo limite, a operação falhará, e um erro será retornado. Por exemplo, o seguinte erro descreve que um limite de memória efetivo de 25 GB (capacidade P1) foi excedido porque o modelo semântico já consumiu 12 GB (12.288 MB) quando o comando começou a ser executado e um limite efetivo de 13 GB (13.312 MB) foi aplicado à operação de comando:

"Controle de recursos: essa operação foi cancelada porque não havia memória suficiente para concluir a execução. Aumente a memória da capacidade Premium na qual o modelo semântico está hospedado ou reduza o volume de memória do modelo semântico tomando medidas como limitar o volume de dados importados. Mais detalhes: memória consumida 13312 MB, limite de memória de 13312 MB, tamanho do banco de dados antes da execução do comando 12288 MB. Saiba mais: https://go.microsoft.com/fwlink/?linkid=2159753."

Em alguns casos, conforme mostrado no erro a seguir, a "memória consumida" é 0, mas a quantidade mostrada para o "tamanho do banco de dados antes da execução do comando" já é maior que o limite de memória efetivo. Isso significa que a operação não pôde iniciar a execução porque a quantidade de memória já usada pelo modelo semântico é maior que o limite de memória do SKU.

"Controle de recursos: essa operação foi cancelada porque não havia memória suficiente para concluir a execução. Aumente a memória da capacidade Premium na qual o modelo semântico está hospedado ou reduza o volume de memória do modelo semântico tomando medidas como limitar o volume de dados importados. Mais detalhes: memória consumida 0 MB, limite de memória de 25600 MB, tamanho do banco de dados antes da execução do comando 26000 MB. Saiba mais: https://go.microsoft.com/fwlink/?linkid=2159753."

Para evitar potencialmente exceder o limite de memória efetivo:

• Atualize o modelo semântico para um tamanho maior de capacidade Premium (SKU).
• Reduza o volume de memória do modelo semântico limitando o volume de dados carregados em cada atualização.
• Para operações de atualização por meio do ponto de extremidade XMLA, reduza o número de partições que estão sendo processadas em paralelo. Muitas partições sendo processadas em paralelo com um único comando podem exceder o limite de memória efetivo.

Conteúdo relacionado

• Conectividade de modelo semântico com o ponto de extremidade XMLA
• Automatizar tarefas de modelo semântico e workspace Premium com entidades de serviço
• Solução de problemas para análise no Excel
• Implantação de solução de modelo tabular