Solución de problemas de conectividad de los puntos de conexión XMLA

  • Artículo

Los puntos de conexión XMLA en Power BI se basan en el protocolo de comunicación Analysis Services nativo para el acceso a los modelos semánticos de Power BI. Debido a esto, solucionar los problemas de los puntos de conexión XMLA es muy similar a solucionar los problemas de una conexión de Analysis Services típica. Sin embargo, se aplican algunas diferencias con respecto a las dependencias específicas de Power BI.

Antes de empezar

Antes de solucionar los problemas de un escenario de punto de conexión XMLA, asegúrese de revisar los conceptos básicos que se describen en Conectividad del modelo semántico con el punto de conexión de XMLA. En ese artículo se describen los casos de uso más comunes del punto de conexión XMLA. También pueden resultarle útiles otras guías de solución de problemas de Power BI, como Solución de problemas de puertas de enlace: Power BI y Solución de problemas de Analizar en Excel.

Habilitación del punto de conexión XMLA

El punto de conexión XMLA se puede habilitar tanto en las capacidades de Power BI Premium como en las de Power BI Embedded. En capacidades más pequeñas, como una capacidad A1 con solo 2,5 GB de memoria, puede encontrar un error en la configuración de la capacidad si intenta establecer el punto de conexión XMLA en Lectura/Escritura y, luego, seleccionar Aplicar. El error indica que hubo un problema con la configuración de la carga de trabajo y que debe volver a intentarlo más tarde.

Estas son algunas medidas que puede intentar:

  • Limite el consumo de memoria de otros servicios de la capacidad, como los Flujos de datos, a 40 % o menos, o bien deshabilite por completo un servicio innecesario.
  • Actualice la capacidad a una SKU mayor. Por ejemplo, actualizar de una capacidad A1 a una capacidad A3 permite solucionar este problema de configuración sin tener que deshabilitar los Flujos de datos.

Tenga en cuenta que también debe habilitar la Opción de exportación de datos de nivel de inquilino en el Portal de administración de Power BI. Esta opción también es necesaria para la característica Analizar en Excel.

Establecimiento de una conexión de cliente

Después de habilitar el punto de conexión XMLA, se recomienda probar la conectividad a un área de trabajo en la capacidad. Para más información, consulte Conexión a un área de trabajo Premium. No olvide leer la sección Requisitos de la conexión para ver sugerencias útiles e información sobre las limitaciones de conectividad XMLA actuales.

Conexión con una entidad de servicio

Si habilitó la opción de inquilino para permitir que las entidades de servicio usen las API de Power BI, tal como se describe en Habilitación de entidades de servicio, puede conectarse a un punto de conexión XMLA mediante una entidad de servicio. Tenga en cuenta que la entidad de servicio requiere el mismo nivel de permisos de acceso en el nivel de área de trabajo o de modelo semántico que los usuarios normales.

Para usar una entidad de servicio, asegúrese de especificar la información de identidad de la aplicación en la cadena de conexión de la manera siguiente:

  • User ID=<app:appid@tenantid>
  • Password=<application secret>

Por ejemplo:

Data Source=powerbi://api.powerbi.com/v1.0/myorg/Contoso;Initial Catalog=PowerBI_Dataset;User ID=app:91ab91bb-6b32-4f6d-8bbc-97a0f9f8906b@19373176-316e-4dc7-834c-328902628ad4;Password=6drX...;

Si aparece el siguiente mensaje de error:

"No es posible establecer una conexión con el modelo semántico debido a que la información de la cuenta no está completa. En el caso de las entidades de servicio, asegúrese de especificar el id. de inquilino junto con el id. de aplicación con la aplicación de formato:<appId>@<tenantId> y vuelva a intentarlo".

Asegúrese de especificar el id. del inquilino junto con el id. de la aplicación con el formato correcto.

También es válido especificar el id. de la aplicación sin el id. del inquilino. Sin embargo, en este caos debe reemplazar el alias myorg de la dirección URL del origen de datos por el id. del inquilino real. Power BI puede entonces ubicar la entidad de servicio en el inquilino correcto. Pero, como procedimiento recomendado, use el alias myorg y especifique el id. del inquilino en conjunto con el id. de la aplicación en el parámetro Id. de usuario.

Conexión con Microsoft Entra B2B

La compatibilidad con Microsoft Entra B2B en Power BI permite proporcionar a usuarios invitados externos acceso a los modelos semánticos a través del punto de conexión XMLA. Asegúrese de que la opción Compartir contenido con usuarios externos esté habilitada en el Portal de administración de Power BI. Para más información, consulte Distribución de contenido de Power BI a usuarios externos invitados con Microsoft Entra B2B.

Implementación de un modelo semántico

Puede implementar un proyecto de modelo tabular en Visual Studio (SSDT) en un área de trabajo asignada a una capacidad Premium, de forma muy parecida a un recurso de servidor en Azure Analysis Services. Sin embargo, cuando se implementa, existen algunas consideraciones adicionales. Asegúrese de revisar la sección Implementación de proyectos de modelo desde Visual Studio (SSDT) del artículo Conectividad del modelo semántico con el punto de conexión XMLA.

Implementación de un modelo nuevo

En la configuración predeterminada, Visual Studio intenta procesar el modelo como parte de la operación de implementación para cargar datos en el modelo semántico desde los orígenes de datos. Tal como se describe en Implementación de proyectos de modelo desde Visual Studio (SSDT), esta operación puede presentar un error porque las credenciales de origen de datos no se pueden especificar como parte de la operación de implementación. En su lugar, si las credenciales del origen de datos no están definidas todavía para ninguno de los modelos semánticos existentes, debe especificar las credenciales del origen de datos en la configuración del modelo semántico con la interfaz de usuario de Power BI (Modelos semánticos>Configuración>Credenciales del origen de datos>Editar credenciales). Una vez que se definen las credenciales del origen de datos, Power BI puede aplicarlas a este origen de datos de manera automática para cualquier modelo semántico nuevo, una vez que la implementación de los metadatos se ha realizado correctamente y se ha creado el modelo semántico.

Si Power BI no puede enlazar el modelo semántico nuevo a las credenciales del origen de datos, recibirá un error que indica "No se puede procesar la base de datos. Motivo: No se pudieron guardar las modificaciones en el servidor". con el código de error "DMTS_DatasourceHasNoCredentialError", tal como se muestra a continuación:

Model deployment error

Para evitar que haya errores en el procesamiento, establezca las Opciones de implementación>Opciones de procesamiento en No procesar, tal como se muestra en la imagen siguiente. Después, Visual Studio solo implementa metadatos. Después, puede configurar las credenciales del origen de datos y hacer clic en Actualizar ahora para el modelo semántico en la interfaz de usuario de Power BI.

Do not process option

Nuevo proyecto a partir de un modelo semántico existente

No se admite la creación de un proyecto tabular nuevo en Visual Studio mediante la importación los metadatos de un modelo semántico existente. Sin embargo, puede conectarse al modelo semántico mediante SQL Server Management Studio, crear scripts para los metadatos y volver a usarlos en otros proyectos tabulares.

Migración de un modelo semántico a Power BI

Se recomienda especificar el nivel de compatibilidad 1500 (o superior) para los modelos tabulares. Este nivel de compatibilidad admite la mayoría de las funcionalidades y los tipos de orígenes de datos. Los niveles de compatibilidad posteriores son compatibles con las versiones anteriores de los niveles.

Proveedores de datos admitidos

En el nivel de compatibilidad 1500, Power BI admite estos tipos de orígenes de datos:

  • Orígenes de datos del proveedor (heredados con una cadena de conexión en los metadatos del modelo).
  • Orígenes de datos estructurados (introducidos con el nivel de compatibilidad 1400).
  • Declaraciones de M insertadas de orígenes de datos (como Power BI Desktop los declara).

Se recomienda usar orígenes de datos estructurados, los que Visual Studio crea de forma predeterminada al pasar por el flujo de datos de importación. Sin embargo, si planea migrar un modelo existente a Power BI que usa un origen de datos del proveedor, asegúrese de que el origen de datos del proveedor se basa en un proveedor de datos compatible. En concreto, Microsoft OLE DB Driver for SQL Server y cualquier controlador ODBC de terceros. Para OLE DB Driver for SQL Server, debe cambiar la definición del origen de datos al proveedor de datos de .NET Framework para SQL Server. En el caso de los controladores ODBC de terceros que puedan no estar disponibles en el servicio Power BI, debe cambiar a una definición de origen de datos estructurados.

También se recomienda reemplazar la versión obsoleta de Microsoft OLE DB Driver for SQL Server (SQLNCLI11) en las definiciones del origen de datos de SQL Server por el proveedor de datos de .NET Framework para SQL Server.

En la tabla siguiente se proporciona un ejemplo de una cadena de conexión de proveedor de datos de .NET Framework para SQL Server que reemplaza una cadena de conexión correspondiente para OLE DB Driver for SQL Server.

Controlador OLE DB para SQL Server Proveedor de datos .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

Referencias cruzadas de orígenes de particiones

Del mismo modo que hay varios tipos de orígenes de datos, también hay varios tipos de orígenes de particiones que un modelo tabular puede incluir para importar datos a una tabla. En concreto, una partición puede usar un origen de partición de consulta o un origen de partición de M. A su vez, estos tipos de orígenes de particiones pueden hacer referencia a orígenes de datos de proveedor o a orígenes de datos estructurados. Si bien los modelos tabulares de Azure Analysis Services admiten la referencia cruzada de estos diversos tipos de particiones y orígenes de datos, Power BI exige una relación más estricta. Los orígenes de la partición de consulta deben hacer referencia a orígenes de datos del proveedor y los orígenes de particiones de M deben hacer referencia a orígenes de datos estructurados. No se admiten otras combinaciones en Power BI. Si desea migrar un modelo semántico de referencia cruzada, en la tabla siguiente se describen las configuraciones admitidas:

Origen de datos Origen de la partición Comentarios Compatible con el punto de conexión XMLA
Origen de datos del proveedor Origen de partición de consulta El motor de AS usa la pila de conectividad basada en cartuchos para acceder al origen de datos. Sí
Origen de datos del proveedor Origen de partición de M El motor de AS traduce el origen de datos del proveedor en un origen de datos estructurados genérico y, a continuación, usa el motor de mashup para importar los datos. No
Sincronización del origen de datos Origen de partición de consulta El motor de AS encapsula la consulta nativa del origen de la partición en una expresión M y, a continuación, usa el motor de mashup para importar los datos. No
Sincronización del origen de datos Origen de partición de M El motor de AS usa el motor de mashup para importar los datos. Sí

Orígenes de datos y suplantación

La configuración de suplantación que se puede definir para los orígenes de datos del proveedor no es pertinente para Power BI. Power BI usa un mecanismo distinto en función de la configuración del modelo semántico para administrar las credenciales del origen de datos. Por este motivo, asegúrese de seleccionar Cuenta de servicio si está creando un origen de datos del proveedor.

Impersonate service account

Procesamiento detallado

Al desencadenar una actualización programada o una actualización a petición en Power BI, Power BI habitualmente actualiza todo el modelo semántico. En muchos casos, resulta más eficaz hacer actualizaciones de manera más selectiva. Puede realizar tareas de procesamiento detallado en SQL Server Management Studio (SSMS) tal como se muestra a continuación, o bien mediante el uso de scripts o herramientas de terceros.

Process tables in SSMS

Invalidaciones en el comando Refresh de TMSL

Las invalidaciones en el comando Refresh (TMSL) permiten a los usuarios elegir otra definición de consulta de partición o de origen de datos para la operación de actualización.

Suscripciones de correo electrónico

Los modelos semánticos que se actualizan mediante un punto de conexión XMLA no desencadenan una suscripción de correo electrónico.

Errores de la capacidad Premium

Error de conexión al servidor en SSMS

Al conectarse a un área de trabajo de Power BI con SQL Server Management Studio (SSMS), es posible que se muestre el error siguiente:

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)

Al conectarse a un área de trabajo de Power BI con SSMS, asegúrese de lo siguiente:

Ejecución de consultas en SSMS

Cuando se conecta a un área de trabajo en una capacidad de Power BI Premium o Power BI Embedded, SQL Server Management Studio puede mostrar el siguiente error:

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.

Se trata de un mensaje informativo que se puede omitir en SSMS 18.8 y versiones posteriores porque las bibliotecas cliente se volverán a conectar de forma automática. Tenga en cuenta que las bibliotecas cliente instaladas con SSMS v18.7.1 o versiones posteriores no admiten el seguimiento de la sesión. Descargar la última versión de SSMS.

Ejecución de un comando grande con el punto de conexión XMLA

Al ejecutar un comando grande con el punto de conexión XMLA, puede obtener el siguiente error:

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

Cuando se utiliza SSMS v18.7.1 o una versión anterior para realizar una operación de actualización de larga duración (>1 min) de un modelo semántico en una capacidad de Power BI Premium o Power BI Embedded, SSMS puede mostrar este error aunque la operación de actualización se realice correctamente. Esto se debe a un problema conocido en las bibliotecas cliente en el que se realiza un seguimiento incorrecto del estado de la solicitud de actualización. Esto se resuelve en SSMS 18.8 y versiones posteriores. Descargar la última versión de SSMS.

Este error también puede producirse cuando es necesario redirigir una solicitud muy grande a otro nodo del clúster Premium. Aparece con frecuencia cuando se intenta crear o modificar un modelo semántico usando un script TMSL grande. En tales casos, el error normalmente se puede evitar especificando el catálogo inicial en el nombre de la base de datos antes de ejecutar el comando.

Al crear una nueva base de datos, puede crear un modelo semántico vacío, por ejemplo:

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

Después de crear el nuevo modelo semántico, especifique el catálogo inicial y, a continuación, realice cambios en el modelo semántico.

Otras aplicaciones y herramientas cliente

Las aplicaciones y herramientas cliente, como Excel, Power BI Desktop, SSMS o herramientas externas que se conectan a modelos semánticos de las capacidades de Power BI Premium y trabajan con él, pueden producir el siguiente error: El servidor remoto ha devuelto un error: (400) Solicitud incorrecta. El error puede deberse especialmente si una consulta DAX subyacente o un comando XMLA es de larga duración. Para mitigar posibles errores, asegúrese de usar las aplicaciones y herramientas más recientes que instalan versiones recientes de las bibliotecas cliente de Analysis Services con actualizaciones periódicas. Independientemente de la aplicación o herramienta, las versiones mínimas necesarias de la biblioteca cliente para conectarse a modelos semánticos y trabajar con ellos en una capacidad Premium mediante el punto de conexión XMLA son las siguientes:

Biblioteca cliente Versión
MSOLAP 15.1.65.22
AMO 19.12.7.0
ADOMD 19.12.7.0

Edición de las pertenencias a roles en SSMS

Si se usa la versión 18.8 de SQL Server Management Studio (SSMS) para editar una pertenencia a roles en un modelo semántico, SSMS puede mostrar el siguiente error:

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.’

Esto se debe a un problema conocido de la API REST de App Services. Esto se resolverá en una próxima versión. Mientras tanto, para soslayar este error, en Propiedades del rol, haga clic en Script y, después, escriba y ejecute el siguiente comando de TMSL:

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

Error de publicación: modelo semántico conectado dinámicamente

Al volver a publicar un modelo semántico conectado en directo mediante el conector de Analysis Services, aparece el siguiente error: "Hay un modelo semántico o informe existente con el mismo nombre. Elimine o cambie el nombre del modelo semántico existente y vuelva a intentarlo.".

Couldn't publish to Power BI error.

Esto se debe a que el modelo semántico que se publica tiene una cadena de conexión diferente, pero tiene el mismo nombre que el modelo semántico que ya existía. Elimine o cambie el nombre del modelo semántico existente para resolver este problema. Asegúrese también de volver a publicar cualquier aplicación que dependa del informe. Si es necesario, indique a los usuarios que actualicen los marcadores con la nueva dirección del informe para asegurarse de que acceden al informe más reciente.

Alias del servidor o el área de trabajo

A diferencia de Azure Analysis Services, no se admiten los alias de nombre de servidor para las áreas de trabajo de la versión Premium.

DISCOVER_M_EXPRESSIONS

En estos momentos, la vista de administración de datos DMV DISCOVER_M_EXPRESSIONS (DMV) no es compatible con Power BI al usar el punto de conexión de XMLA. Las aplicaciones pueden usar el Modelo de objetos tabulares (TOM) para obtener las expresiones M usadas por el modelo de datos.

Límite de memoria de comandos de control de recursos en Premium

Las capacidades Premium usan la regulación de recursos para asegurarse de que ninguna operación de modelo semántico única puede superar la cantidad de recursos de memoria disponibles para la capacidad, que determina el SKU. Por ejemplo, una suscripción P1 tiene un límite de memoria efectivo por elemento de 25 GB; para una suscripción P2, el límite es de 50 GB; y para una suscripción P3, 100 GB. Además del tamaño del modelo semántico (base de datos), el límite de memoria efectivo también se aplica a las operaciones de comando de modelo semántico subyacentes, como Crear, Modificar y Actualizar.

El límite de memoria efectivo para un comando se basa en el valor más bajo entre el límite de memoria de la capacidad (que determina el SKU) y el valor de la propiedad XMLA DbpropMsmdRequestMemoryLimit.

Por ejemplo, para una capacidad P1, si:

  • DbpropMsmdRequestMemoryLimit = 0 (o no está especificado), el límite de memoria efectivo para el comando es de 25 GB.

  • DbpropMsmdRequestMemoryLimit = 5 GB, el límite de memoria efectivo para el comando es de 5 GB.

  • DbpropMsmdRequestMemoryLimit = 50 GB, el límite de memoria efectivo para el comando es de 25 GB.

Normalmente, el límite de memoria efectivo para un comando se calcula en función de la memoria permitida para el modelo semántico por la capacidad (25 GB, 50 GB, 100 GB) y la cantidad de memoria que el modelo semántico ya está consumiendo cuando el comando empieza a ejecutarse. Por ejemplo, un modelo semántico que usa 12 GB en una capacidad P1 permite un límite de memoria efectivo para un comando nuevo de 13 GB. Sin embargo, el límite de memoria efectivo se puede restringir aún más mediante la propiedad XMLA DbPropMsmdRequestMemoryLimit cuando una aplicación lo especifique opcionalmente. Con el ejemplo anterior, si se especifica 10 GB en la propiedad DbPropMsmdRequestMemoryLimit, el límite efectivo del comando se reduce más todavía, a 10 GB.

Si la operación de comando intenta consumir más memoria de la que permite el límite, se puede producir un error en la operación y se devuelve un error. Por ejemplo, en el error siguiente se describe que se ha superado un límite de memoria efectivo de 25 GB (capacidad P1) porque el modelo semántico ya ha consumido 12 GB (12288 MB) cuando el comando ha iniciado la ejecución y se ha aplicado un límite efectivo de 13 GB (13312 MB) para la operación de comando:

"Regulación de recursos: se ha cancelado esta operación porque no había memoria suficiente para terminar de ejecutarla. Puede aumentar la memoria de la capacidad Premium donde se aloja este modelo semántico o reducir la superficie de memoria de su modelo semántico haciendo algunas cosas, como limitar la cantidad de datos importados. Más detalles: memoria consumida 13 312 MB, límite de memoria 13 312 MB, tamaño de la base de datos antes de la ejecución del comando 12 288 MB. Obtenga más información: https://go.microsoft.com/fwlink/?linkid=2159753".

En algunos casos, tal como se muestra en el error siguiente, "memoria consumida" es 0, pero la cantidad mostrada para "tamaño de la base de datos antes de la ejecución del comando" ya es mayor que el límite de memoria efectivo. Esto significa que la operación no ha podido iniciar la ejecución porque la cantidad de memoria que ya usa el modelo semántico es mayor que el límite de memoria del SKU.

"Regulación de recursos: se ha cancelado esta operación porque no había memoria suficiente para terminar de ejecutarla. Puede aumentar la memoria de la capacidad Premium donde se aloja este modelo semántico o reducir la superficie de memoria de su modelo semántico haciendo algunas cosas, como limitar la cantidad de datos importados. Más detalles: memoria consumida 0 MB, límite de memoria 25 600 MB, tamaño de la base de datos antes de la ejecución del comando 26 000 MB. Obtenga más información: https://go.microsoft.com/fwlink/?linkid=2159753".

Para evitar la posible superación del límite de memoria efectivo, haga lo siguiente:

  • Actualice a un tamaño de capacidad Premium (SKU) mayor para el modelo semántico.
  • Reduzca la superficie de memoria del modelo semántico mediante la limitación de la cantidad de datos cargados con cada actualización.
  • En el caso de las operaciones de actualización a través del punto de conexión XMLA, reduzca el número de particiones que se procesan en paralelo. Si hay demasiadas particiones que se procesan en paralelo con un solo comando se podría superar el límite de memoria efectivo.

Contenido relacionado