Solucionar problemas de conectividade de ponto de extremidade XMLA
Os pontos de extremidade XMLA no Power BI dependem do protocolo de comunicação nativo do Analysis Services para acessar modelos semânticos do Power BI. Por isso, a solução de problemas de ponto de extremidade XMLA é muito semelhante à solução de problemas de uma conexão típica do Analysis Services. No entanto, algumas diferenças em torno das dependências específicas do Power BI se aplicam.
Antes de começar
Antes de solucionar problemas de um cenário de ponto de extremidade XMLA, certifique-se de revisar os conceitos básicos abordados na conectividade do modelo semântico com o ponto de extremidade XMLA. Os casos de uso de endpoint XMLA mais comuns são abordados aqui. Outros guias de solução de problemas do Power BI, como Solucionar problemas de gateways - Power BI e Solucionar problemas de análise no Excel, também podem ser úteis.
Habilitando 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 capacidade A1 com apenas 2,5 GB de memória, você pode encontrar um erro nas configurações de Capacidade ao tentar definir o Ponto Final XMLA como Leitura/Gravação e, em seguida, selecionar Aplicar. O erro afirma "Houve um problema com suas configurações de carga de trabalho. Tente novamente daqui a pouco.".
Aqui estão algumas coisas para tentar:
- Limite o consumo de memória de outros serviços na capacidade, como fluxos de dados, a 40% ou menos, ou desative completamente um serviço desnecessário.
- Atualize a capacidade para uma SKU maior. Por exemplo, a atualização de uma capacidade A1 para A3 resolve esse problema de configuração sem ter que desabilitar os fluxos de dados.
Lembre-se, 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.
Estabelecendo uma conexão de cliente
Depois de habilitar o ponto de extremidade XMLA, é uma boa ideia testar a conectividade com um espaço de trabalho na capacidade. Para saber mais, consulte Conectando-se a um espaço de trabalho Premium. Além disso, leia a seção Requisitos de conexão para obter dicas úteis e informações sobre as limitações atuais de conectividade XMLA.
Conectando-se com uma entidade de serviço
Se você habilitou as configurações de locatário para permitir que as entidades de serviço usem APIs do Power BI, conforme descrito em Habilitar entidades de serviço, você pode se conectar a um ponto de extremidade XMLA usando uma entidade de serviço. Lembre-se de que a entidade de serviço requer o mesmo nível de permissões de acesso no espaço de trabalho ou no nível do 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
Palavra-passe
cert:thumbprint (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 incompletas da conta. Para entidades de serviço, certifique-se de especificar a ID do locatário juntamente com a ID do aplicativo usando o formato app:<appId>@<tenantId> e tente novamente."
Certifique-se de especificar o ID do locatário juntamente com o ID do aplicativo usando o formato correto.
Também é válido especificar o ID do aplicativo sem o ID do locatário. No entanto, nesse caso, você deve substituir o myorg alias na URL da fonte de dados pelo ID do locatário real. O Power BI pode então localizar a entidade de serviço no locatário correto. Mas, como prática recomendada, use o myorg alias e especifique o ID do locatário junto com o ID do aplicativo no parâmetro User ID.
Conectando-se com o Microsoft Entra B2B
Com suporte para o Microsoft Entra business-to-business (B2B) no Power BI, você pode fornecer aos usuários convidados externos acesso a modelos semânticos no ponto de extremidade XMLA. Verifique se a configuração Compartilhar conteúdo com usuários externos está habilitada no portal de Administração do Power BI. Para saber mais, consulte Distribuir conteúdo do Power BI para usuários convidados externos com o Microsoft Entra B2B.
Implantando um modelo semântico
Você pode implantar um projeto de modelo tabular no Visual Studio (SSDT) em um espaço de trabalho atribuído a uma capacidade Premium, da mesma forma que a um recurso de servidor no Azure Analysis Services. No entanto, ao implantar, há algumas considerações adicionais. Certifique-se de revisar a seção Implantar projetos de modelo do Visual Studio (SSDT) no artigo Conectividade do modelo semântico com o ponto de extremidade XMLA.
Implantando 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 dados no modelo semântico 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, especifique as credenciais da fonte de dados nas configurações do modelo semântico usando a interface do usuário do Power BI (Configurações de modelos>semânticos Credenciais>>da fonte de dados Editar credenciais). Depois de definir as credenciais da fonte de dados, o Power BI pode aplicar as credenciais a essa fonte de dados automaticamente para qualquer novo modelo semântico, depois que a implantação de metadados for bem-sucedida e o modelo semântico tiver sido criado.
Se o Power BI não puder vincular seu novo modelo semântico às credenciais da fonte de dados, você receberá um erro informando "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", como mostrado abaixo:
Para evitar a falha de processamento, defina as Opções de Processamento de Opções>de Implantação como Não Processar, conforme mostrado na imagem a seguir. Em seguida, o Visual Studio implanta apenas metadados. Em seguida, você pode configurar as credenciais da fonte de dados e clicar em Atualizar agora para o modelo semântico na interface do usuário do Power BI.
Novo projeto a partir de um modelo semântico existente
Não há suporte para a criação de um novo projeto tabular no Visual Studio importando os metadados de um modelo semântico existente. No entanto, você pode se conectar ao modelo semântico usando o SQL Server Management Studio, criar scripts para os metadados e reutilizá-los em outros projetos tabulares.
Migrando 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 suporta a maioria dos recursos e tipos de fonte de dados. Os níveis de compatibilidade posteriores são retrocompatíveis com os níveis anteriores.
Fornecedores de dados suportados
No nível de compatibilidade 1500, o Power BI suporta os seguintes tipos de fonte de dados:
- Fontes de dados do provedor (herdadas com uma cadeia de conexão nos metadados do modelo).
- Fontes de dados estruturadas (introduzidas com o nível de compatibilidade 1400).
- Declarações M embutidas de fontes de dados (como o Power BI Desktop as declara).
É recomendável usar fontes de dados estruturadas, que o Visual Studio cria por padrão ao passar pelo fluxo de dados Importar. No entanto, se você estiver planejando migrar um modelo existente para o Power BI que usa uma fonte de dados do provedor, verifique se a fonte de dados do provedor depende de um provedor de dados suportado. Especificamente, o driver Microsoft OLE DB para SQL Server e quaisquer drivers ODBC de terceiros. Para o Driver OLE DB para SQL Server, você deve alternar a definição da fonte de dados para o Provedor de Dados do .NET Framework para SQL Server. Para drivers ODBC de terceiros que podem não estar disponíveis no serviço do Power BI, você deve alternar para uma definição de fonte de dados estruturada.
Também é recomendável substituir o driver Microsoft OLE DB desatualizado para SQL Server (SQLNCLI11) em suas definições de fonte de dados do SQL Server pelo Provedor de Dados do .NET Framework para SQL Server.
A tabela a seguir fornece um exemplo de um provedor de dados do .NET Framework para cadeia de conexão do SQL Server substituindo uma cadeia de conexão correspondente para o driver OLE DB para SQL Server.
| Driver OLE DB para SQL Server | Fornecedor de Dados .NET Framework para SQL Server |
|---|---|
Provider=SQLNCLI11;Data Source=sqldb.database.windows.net;Initial Catalog=AdventureWorksDW;Trusted_Connection=yes; |
Data Source=sqldb.database.windows.net;Initial Catalog=AdventureWorksDW2016;Integrated Security=SSPI;Encrypt=true;TrustServerCertificate=false |
Fontes de partição de referência cruzada
Assim como existem vários tipos de fonte de dados, também há vários tipos de fonte de partição que um modelo tabular pode incluir para 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 fazer referência a fontes de dados do provedor ou fontes de dados estruturadas. Embora os modelos tabulares no Azure Analysis Services ofereçam suporte à referência cruzada desses vários tipos de fonte de dados e partição, o Power BI impõe uma relação mais rígida. As fontes de partição de consulta devem fazer referência a fontes de dados do provedor e as fontes de partição M devem fazer referência a fontes de dados estruturadas. Não há suporte para outras combinações no Power BI. Se você quiser migrar um modelo semântico de referência cruzada, a tabela a seguir descreve as configurações suportadas:
| Data source | Origem da partição | Comentários | Suportado com ponto de extremidade XMLA |
|---|---|---|---|
| Fonte de dados do provedor | Origem da partição de consulta | O mecanismo AS usa a pilha de conectividade baseada em cartucho para acessar a fonte de dados. | Sim |
| Fonte de dados do provedor | Origem da partição M | O mecanismo AS converte a fonte de dados do provedor em uma fonte de dados estruturada genérica e, em seguida, usa o mecanismo Mashup para importar os dados. | Não |
| Fonte de dados estruturada | Origem da partição de consulta | O mecanismo AS encapsula a consulta nativa na fonte da partição em uma expressão M e, em seguida, usa o mecanismo Mashup para importar os dados. | Não |
| Fonte de dados estruturada | Origem da partição M | O mecanismo AS usa o mecanismo Mashup para importar os dados. | Sim |
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 com base nas configurações do modelo semântico para gerenciar as credenciais da fonte de dados. Por esse motivo, certifique-se de selecionar Conta de Serviço se estiver criando uma Fonte de Dados do Provedor.
Processamento de grão fino
Ao acionar uma atualização agendada ou sob demanda no Power BI, o Power BI normalmente atualiza todo o modelo semântico. Em muitos casos, é mais eficiente realizar atualizações de forma mais seletiva. Você pode executar tarefas de processamento refinadas no SQL Server Management Studio (SSMS), conforme mostrado abaixo, ou usando ferramentas ou scripts de terceiros.
Substitui no comando Atualizar TMSL
As substituições no comando Atualizar (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 e-mail
Os modelos semânticos que são atualizados usando um ponto de extremidade XMLA não acionam uma assinatura de email.
Erros na capacidade Premium
Erro de conexão com o servidor no SSMS
Ao se conectar a um espaço de trabalho do Power BI com o SQL Server Management Studio (SSMS), 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 conectar-se a um espaço de trabalho do Power BI com o SSMS, verifique o seguinte:
- A configuração do ponto de extremidade XMLA está habilitada para a capacidade do seu locatário. Para saber mais, consulte Habilitar leitura-gravação XMLA.
- A configuração Permitir pontos de extremidade XMLA e Analisar no Excel com modelos semânticos locais está habilitada em Configurações de locatário.
- Você está usando a versão mais recente do SSMS. Faça o download do mais recente.
Execução de consultas no SSMS
Quando conectado a um espaço de trabalho 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 superior porque as bibliotecas de cliente se reconectarão automaticamente. Observe que as bibliotecas de cliente instaladas com o SSMS v18.7.1 ou inferior não oferecem suporte ao rastreamento de sessão. Transfira o SSMS mais recente.
Executando um comando large usando o ponto de extremidade XMLA
Ao executar um comando large 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 inferior para executar uma operação de atualização de longa duração (>1 min) em um modelo semântico em uma capacidade do Power BI Premium ou do Power BI Embedded , o SSMS pode exibir esse erro mesmo que a operação de atualização seja bem-sucedida. Isso ocorre devido a um problema conhecido nas bibliotecas de cliente onde o status da solicitação de atualização é rastreado incorretamente. Isso é resolvido no SSMS 18.8 e superior. Transfira 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. É frequentemente visto 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 novo banco de dados, você pode criar um modelo semântico vazio, por exemplo:
{
"create": {
"database": {
"name": "DatabaseName"
}
}
}
Depois de criar o novo modelo semântico, especifique o catálogo inicial e, em seguida, faça alterações no modelo semântico.
Outras aplicações e ferramentas cliente
Aplicativos e ferramentas cliente, como Excel, Power BI Desktop, 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 for de longa execução. Para atenuar possíveis erros, certifique-se de usar os aplicativos e ferramentas mais recentes que instalam versões recentes das bibliotecas de cliente do Analysis Services com atualizações regulares. Independentemente do aplicativo ou ferramenta, as versões mínimas necessárias da biblioteca do cliente para se conectar e trabalhar com modelos semânticos em uma capacidade Premium por meio do ponto de extremidade XMLA são:
| Biblioteca de cliente | Versão |
|---|---|
| MSOLAP | 15.1.65.22 |
| AMO | 19.12.7.0 |
| ADOMD | 19.12.7.0 |
Editando associações de função no SSMS
Ao usar o SQL Server Management Studio (SSMS) v18.8 para editar uma associação de função em um modelo semântico, o SSMS pode 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 aplicativo. Isso será resolvido em uma próxima versão. Entretanto, para contornar este erro, em Propriedades da Função, clique em Script e, em seguida, introduza 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 conectado ao vivo
Ao republicar um modelo semântico conectado ao vivo utilizando o conector do Analysis Services, o seguinte erro, "Há um modelo semântico/relatório existente com o mesmo nome. Exclua ou renomeie o modelo semântico existente e tente novamente." pode ser mostrado.
Isso ocorre devido ao modelo semântico que está sendo publicado ter uma cadeia de conexão diferente, mas ter o mesmo nome que o modelo semântico existente. Para resolver esse problema, exclua ou renomeie o modelo semântico existente. Certifique-se também de publicar novamente todos os aplicativos que dependem do relatório. Se necessário, os utilizadores a jusante deverão ser informados de que devem atualizar quaisquer marcadores com o novo endereço do relatório, a fim de garantir o seu acesso ao 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 do Live Connected ou abrir um modelo existente do Live Connected, 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 nos 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 os pontos de extremidade do serviço Power BI correspondentes para nuvens soberanas.
Para validar se o problema é resultado de configurações de proxy, tente o conector do SQL Server Analysis Services no Power BI Desktop ou qualquer ferramenta externa de primeira parte ou de terceiros, como o SQL Server Management Studio, para se conectar a qualquer espaço de trabalho 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.
Falha ao abrir a pasta de trabalho do Excel
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 provedor OLE DB do Analysis Services (MSOLAP) 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 oferece suporte à otimização, o Excel não conseguirá abrir a pasta de trabalho.
"Catalog Rebound" destina-se apenas a uso interno.
Alias de espaço de trabalho/servidor
Ao contrário do Azure Analysis Services, os aliases de nome de servidor não são suportados para espaços de trabalho Premium.
DISCOVER_M_EXPRESSIONS
O DMV DISCOVER_M_EXPRESSIONS modo de exibição de gerenciamento de dados (DMV) não é suportado atualmente no Power BI usando o ponto de extremidade XMLA. Os aplicativos podem usar o modelo de objeto tabular (TOM) para obter expressões M usadas pelo modelo de dados.
Limite de memória de comando que rege o recurso no Premium
As capacidades premium usam o controle de recursos para garantir que nenhuma operação de modelo semântico possa exceder a quantidade de recursos de memória disponíveis para a capacidade - determinada pela SKU. Por exemplo, uma subscrição P1 tem um limite de memória efetivo por item de 25 GB, para uma subscrição P2 o limite é de 50 GB e para uma subscrição 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 a operações de comando do modelo semântico subjacente, como Criar, Alterar e Atualizar.
O limite de memória efetivo para um comando é baseado no menor limite de memória da capacidade (determinado por 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 na memória permitida para o modelo semântico pela capacidade (25 GB, 50 GB, 100 GB) e pela 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 usando 12 GB em uma capacidade P1 permite um limite de memória efetivo para um novo comando de 13 GB. No entanto, o limite de memória efetivo pode ser ainda mais restringido pela propriedade XMLA DbPropMsmdRequestMemoryLimit quando especificado opcionalmente por um aplicativo. Usando o exemplo anterior, se 10 GB for especificado na propriedade DbPropMsmdRequestMemoryLimit, o limite efetivo do comando será reduzido para 10 GB.
Se a operação de comando tentar consumir mais memória do que o permitido pelo limite, a operação pode falhar e um erro é 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á consumia 12 GB (12288 MB) quando o comando iniciou a execução e um limite efetivo de 13 GB (13312 MB) foi aplicado para a operação de comando:
"Governança de recursos: esta operação foi cancelada porque não havia memória suficiente para terminar de executá-la. Aumente a memória da capacidade Premium onde esse modelo semântico está hospedado ou reduza o espaço de memória do seu modelo semântico fazendo coisas como limitar a quantidade de dados importados. Mais detalhes: memória consumida 13312 MB, limite de memória 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, como mostrado no erro a seguir, "memória consumida" é 0, mas a quantidade mostrada para "tamanho do banco de dados antes da execução do comando" já é maior do que o limite de memória efetiva. Isso significa que a operação falhou ao iniciar a execução porque a quantidade de memória já usada pelo modelo semântico é maior do que o limite de memória para a SKU.
"Governança de recursos: esta operação foi cancelada porque não havia memória suficiente para terminar de executá-la. Aumente a memória da capacidade Premium onde esse modelo semântico está hospedado ou reduza o espaço de memória do seu modelo semântico fazendo coisas como limitar a quantidade de dados importados. Mais detalhes: memória consumida 0 MB, limite de memória 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 potencialmente evitar exceder o limite de memória efetiva:
- Atualize para um tamanho de capacidade Premium (SKU) maior para o modelo semântico.
- Reduza o espaço ocupado pela memória do seu modelo semântico limitando a quantidade de dados carregados com 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 efetiva.