Conectividad del modelo semántico con el punto de conexión XMLA
Las áreas de trabajo de Power BI Premium, Premium por usuario y Power BI Embedded admiten la conectividad de plataforma abierta de Microsoft y las aplicaciones y herramientas cliente de terceros mediante el uso de un punto de conexión XMLA.
Puntos de conexión XMLA
En las áreas de trabajo se usa el protocolo XML for Analysis (XMLA) para las comunicaciones entre las aplicaciones cliente y el motor que administra las áreas de trabajo y los modelos semánticos de Power BI. Estas comunicaciones se realizan a través de lo que normalmente se denominan puntos de conexión XMLA. XMLA es el protocolo de comunicación que usa el motor de Microsoft Analysis Services, que ejecuta el modelado semántico, la gobernanza, el ciclo de vida y la administración de datos de Power BI. Los datos enviados a través del protocolo XMLA están totalmente cifrados.
De forma predeterminada, la conectividad de solo lectura que usa el punto de conexión está habilitada para la carga de trabajo de los modelos semánticos de una capacidad. Al ser de solo lectura, las herramientas y aplicaciones de visualización de datos pueden consultar los datos del modelo semántico, así como los metadatos, los eventos y el esquema.
Mediante el punto de conexión se pueden habilitar operaciones de lectura y escritura. Estas operaciones proporcionan más administración de modelos semánticos, gobernanza, modelado semántico avanzado, depuración y supervisión. Cuando la lectura y escritura está habilitada, los modelos semánticos tienen más paridad con los procesos y las herramientas de modelado tabular de nivel empresarial de Azure Analysis Services y SQL Server Analysis Services.
Propiedades del servidor de Analysis Services
Power BI Premium admite propiedades adicionales del servidor de Analysis Services. Para revisarlas, consulte Propiedades del servidor en Analysis Services.
Términos de uso
El uso del punto de conexión XMLA está sujeto a:
Aplicación de un solo usuario: la aplicación usa una única cuenta de usuario o identidad de aplicación para acceder a un modelo semántico de Power BI por medio del punto de conexión XMLA. Algunos ejemplos de aplicaciones de usuario único incluyen herramientas de desarrollo, scripts de administrador y procesos automatizados. Estas aplicaciones pueden realizar tareas como el modelado de datos y tareas administrativas que alteren los metadatos de un modelo semántico, una operación de copia de seguridad o restauración, o desencadenar una actualización de datos. La cuenta de usuario o identidad de aplicación que usa la aplicación cliente para acceder a un modelo semántico debe tener una licencia Premium por usuario (PPU) válida, a menos que el modelo semántico resida en una capacidad Premium.
Aplicación de varios usuarios: la aplicación proporciona a varios usuarios acceso a un modelo semántico de Power BI. Por ejemplo, una aplicación de nivel intermedio que integra un modelo semántico en una solución empresarial y accede al modelo semántico en nombre de sus usuarios empresariales.
- En áreas de trabajo Premium por usuario (PPU), la aplicación debe exigir a cada usuario que inicie sesión en Power BI. Para cada usuario, la aplicación usa un token de acceso para acceder a los modelos semánticos. La aplicación no puede usar una cuenta de servicio ni otra identidad de aplicación para realizar tareas en nombre de usuarios individuales. Cada usuario debe usar su propia cuenta de Power BI para abrir informes, acceder a modelos semánticos y ejecutar consultas.
- En áreas de trabajo Premium, la aplicación puede usar una cuenta de servicio o una identidad de aplicación en nombre de los usuarios finales sin necesidad de que cada usuario inicie sesión en Power BI.
Aplicaciones y herramientas cliente
Herramientas y aplicaciones más comunes que se usan con Azure Analysis Services y SQL Server Analysis Services que ahora son compatibles con los modelos semánticos de Power BI Premium:
Microsoft Excel: las tablas dinámicas de Excel son una de las herramientas más comunes que se usan para resumir, analizar, explorar y presentar datos de resumen de modelos semánticos de Power BI. Se requiere solo lectura para las operaciones de consulta. Requiere la versión Hacer clic y ejecutar de Office 16.0.13612.10000 o posterior.
Visual Studio con proyectos de Analysis Services: conocido como SQL Server Data Tools(SSDT). SSDT es una herramienta de creación de modelos de nivel empresarial para los modelos tabulares de Analysis Services. Todas las ediciones de Visual Studio 2017 y posteriores, incluida la edición gratuita Community, admiten extensiones de proyectos de Analysis Services. Requiere la versión 2.9.14 de la extensión, o una posterior, para implementar modelos tabulares en un área de trabajo Premium. El modelo debe estar en el nivel de compatibilidad 1500 o superior para poder implementarse. Requiere lectura y escritura de XMLA en la carga de trabajo de los modelos semánticos. Para obtener más información, consulte Herramientas para Analysis Services.
SQL Server Management Studio (SSMS): admite consultas DAX, MDX, y XMLA. Realice operaciones de actualización específicas y scripting de metadatos de modelos semánticos mediante el lenguaje de scripting de modelos tabulares (TMSL). Requiere solo lectura para las operaciones de consulta. Requiere lectura y escritura para el scripting de metadatos. Se necesita la versión 18.9 o posterior de SSMS. Descargue SSMS.
SQL Server Profiler: SQL Server Profiler se instala con SSMS, y permite el seguimiento y la depuración de eventos del modelo semántico. Aunque oficialmente está en desuso para SQL Server, Profiler se sigue incluyendo en SSMS y todavía se admite para Analysis Services y Power BI. Se requiere la versión de SQL Server Profiler 18.9 o una posterior. El usuario debe especificar el modelo semántico (catálogo inicial) al conectarse con el punto de conexión XMLA. Para obtener más información, vea SQL Server Profiler para Analysis Services.
Asistente para la implementación de Analysis Services: instalada con SSMS, esta herramienta proporciona la implementación de proyectos de modelos tabulares creados de Visual Studio para áreas de trabajo de Analysis Services y Premium. Se puede ejecutar de forma interactiva o desde la línea de comandos para la automatización. Se requiere lectura y escritura de XMLA. Para obtener más información, consulte el Asistente para implementación de Analysis Services.
Cmdlets de PowerShell: use cmdlets de Analysis Services para automatizar las tareas de administración del modelo semántico, como las operaciones de actualización. Requiere lectura y escritura de XMLA. Requiere la versión 21.1.18256 o posterior del módulo SqlServer de PowerShell. Los cmdlets de Azure Analysis Services del módulo Az.AnalysisServices no se admiten con los modelos semánticos de Power BI. Para obtener más información, vea Referencia de Analysis Services PowerShell.
Power BI Report Builder: una herramienta para crear informes paginados. Cree una definición de informe que especifique qué datos recuperar, de dónde obtenerlos y cómo mostrarlos. Puede obtener una vista previa del informe en Report Builder y luego publicarlo en el servicio Power BI. Requiere solo lectura de XMLA. Para obtener más información, vea Power BI Report Builder.
Editor tabular: herramienta de código abierto para crear, mantener y administrar modelos tabulares con un editor intuitivo y ligero. Una vista jerárquica muestra todos los objetos del modelo tabular. Los objetos se organizan por carpetas de presentación con compatibilidad con la edición de propiedades de selección múltiple y el resaltado de sintaxis de DAX. Requiere solo lectura de XMLA para las operaciones de consulta. Requiere lectura y escritura para las operaciones de metadatos. Para obtener más información, vea tabulareditor.github.io.
DAX Studio: una herramienta de código abierto para la creación, el diagnóstico, el ajuste del rendimiento y el análisis de DAX. Entre las características se incluyen la exploración de objetos, el seguimiento integrado, los desgloses de la ejecución de consultas con estadísticas detalladas y resaltado y aplicación de formato de sintaxis de DAX. Requiere solo lectura de XMLA para las operaciones de consulta. Para más información, vea daxstudio.org.
ALM Toolkit: una herramienta de comparación de esquemas de código abierto para modelos semánticos de Power BI, que se suele usar para escenarios de administración del ciclo de vida de las aplicaciones (ALM). Realice la implementación en todos los entornos y retenga los datos históricos de actualización incremental. Compare y combine archivos de metadatos, ramas y repositorios. Reutilización de definiciones comunes entre modelos semánticos. Requiere solo lectura para las operaciones de consulta. Requiere lectura y escritura para las operaciones de metadatos. Para obtener más información, visite alm-toolkit.com.
Terceros: se incluyen aplicaciones y herramientas de visualización de datos de cliente que se pueden conectar a áreas de trabajo Premium, así como consultar y consumir modelos semánticos de este origen. La mayoría de las herramientas requieren las versiones más recientes de las bibliotecas cliente MSOLAP, pero algunas pueden usar ADOMD. El punto de conexión de XMLA de solo lectura, o de lectura y escritura, depende de las operaciones.
Bibliotecas de cliente
Las aplicaciones y herramientas cliente no se comunican directamente con el punto de conexión de XMLA. En su lugar, usan bibliotecas de cliente como una capa de abstracción. Estas son las mismas bibliotecas de cliente que las aplicaciones usan para conectarse a Azure Analysis Services y SQL Server Analysis Services. Las aplicaciones de Microsoft como Excel, SQL Server Management Studio (SSMS) y extensión de proyectos de Analysis Services para Visual Studio instalan las tres bibliotecas de cliente y las actualizan junto con las actualizaciones de aplicaciones y extensiones normales. Los desarrolladores también pueden usar las bibliotecas cliente para compilar aplicaciones personalizadas. En algunos casos, en especial con las aplicaciones de terceros, si no se instalan con la aplicación, podría ser necesario instalar versiones más recientes de las bibliotecas cliente. Las bibliotecas de cliente se actualizan mensualmente. Para más información, vea Bibliotecas de cliente para la conexión a Analysis Services.
Optimización de modelos semánticos para operaciones de escritura mediante la habilitación de modelos grandes
Cuando se usa el punto de conexión de XMLA para la administración de modelos semánticos con operaciones de escritura, se recomienda habilitar el modelo semántico para modelos de gran tamaño. Esto reduce la sobrecarga de las operaciones de escritura, lo que puede hacer que sean considerablemente más rápidas. En el caso de los modelos semánticos de más de 1 GB (después de la compresión), la diferencia puede ser importante. Para obtener más información, consulte Modelos grandes en Power BI Premium.
Habilitación de lectura y escritura de XMLA
De manera predeterminada, la capacidad Premium o las cargas de trabajo del modelo semántico Premium por usuario tienen habilitada la configuración de la propiedad de punto de conexión de XMLA para solo lectura. Esto significa que las aplicaciones solo pueden consultar un modelo semántico. Para que las aplicaciones puedan realizar operaciones de escritura, la propiedad del punto de conexión de XMLA debe estar habilitada para lectura y escritura.
Habilitación de la lectura y escritura para una capacidad Premium
Seleccione Configuración>Portal de administración.
En el portal de administración, seleccione Configuración de la capacidad>Power BI Premium> nombre de la capacidad.
Expanda Cargas de trabajo. En el parámetro Punto de conexión de XMLA, seleccione Lectura y escritura. El parámetro de la propiedad del punto de conexión de XMLA se aplica a todas las áreas de trabajo y modelos semánticos asignados a la capacidad.
Habilitación de la lectura y escritura para Premium por usuario
- Seleccione Configuración>Portal de administración.
- En el Portal de administración, seleccione Premium por usuario.
- Expanda Configuración de carga de trabajo del modelo semántico. En el parámetro Punto de conexión de XMLA, seleccione Lectura y escritura.
Conexión a un área de trabajo Premium
Las áreas de trabajo asignadas a una capacidad tienen una cadena de conexión con un formato de dirección URL. Por ejemplo:
powerbi://api.powerbi.com/v1.0/[tenant name]/[workspace name].
Las aplicaciones que se conectan al área de trabajo usan la dirección URL, como si se tratase de un nombre de servidor de Analysis Services. Por ejemplo:
powerbi://api.powerbi.com/v1.0/contoso.com/Sales Workspace.
Nota:
Actualmente no se admite la conexión a Mi área de trabajo mediante el punto de conexión de XMLA.
Usuarios B2B e invitados
Cuando los usuarios acceden a un área de trabajo en su inquilino principal, la sección nombre del inquilino de la dirección URL se puede reemplazar por myorg. Por ejemplo:
powerbi://api.powerbi.com/v1.0/myorg/Sales Workspace.
Cuando los usuarios B2B\invitados acceden a áreas de trabajo en un inquilino diferente, ese nombre de inquilino debe especificarse en la dirección URL del origen de datos. Por ejemplo, cuando se invita a un usuario de contoso.com al inquilino de fabrikam.com y se concede permiso a "Área de trabajo de ventas", debe usar la siguiente dirección URL para conectarse:
powerbi://api.powerbi.com/v1.0/fabrikam.com/Sales Workspace.
Para determinar el nombre de dominio principal y el identificador de un inquilino, inicie sesión en Azure Portal, seleccione Microsoft Entra ID en el menú principal y a continuación, anote la información en la página Información general de Microsoft Entra. Para obtener más información, consulte Buscar el identificador de inquilino de Microsoft Entra y el nombre de dominio principal.
Para obtener la dirección URL de la conexión del área de trabajo
En el área de trabajo Configuración>Premium>Conexión del área de trabajo, seleccione Copiar.
Requisitos de la conexión
Catálogo inicial
Con algunas herramientas, como SQL Server Profiler, debe especificar un catálogo inicial, que es el modelo semántico (la base de datos) al que se va a conectar en el área de trabajo. En el cuadro de diálogo Conectarse al servidor, seleccione Opciones>Propiedades de conexión>Conectar a base de datos y escriba el nombre del modelo semántico.
Nombres del área de trabajo duplicada
Las áreas de trabajo de la validación de Power BI impiden la creación o el cambio de nombre de las áreas de trabajo con nombres duplicados. Al conectarse a un área de trabajo con el mismo nombre que otra, podría recibir el error siguiente:
No se puede conectar a powerbi://api.powerbi.com/v1.0/[tenant name]/[workspace name].
Para solucionarlo, además del nombre del área de trabajo, especifique ObjectIDGuid. Puede copiar ObjectIDGuid desde el valor de objectID del área de trabajo de la dirección URL. Anexe el valor de objectID a la dirección URL de conexión. Por ejemplo:
powerbi://api.powerbi.com/v1.0/myorg/Contoso Sales - 9d83d204-82a9-4b36-98f2-a40099093830.
Nombre del modelo semántico duplicado
Para conectarse a un modelo semántico con el mismo nombre que otro modelo semántico en la misma área de trabajo, anexe el GUID del modelo semántico al nombre del modelo semántico. Puede obtener el nombre del modelo semántico y el GUID cuando se conecta al área de trabajo en SSMS.
Retraso en los modelos semánticos mostrados
Al conectarse a un área de trabajo, los cambios de los modelos semánticos nuevos, eliminados y cuyo nombre ha cambiado pueden tardar unos minutos en aparecer.
Modelos semánticos no compatibles
Los modelos semánticos siguientes no son accesibles mediante el punto de conexión de XMLA. Estos modelos semánticos no aparecerán en el área de trabajo en SSMS o en otras herramientas:
- Modelos semánticos basados en una conexión dinámica a un modelo de Azure Analysis Services o SQL Server Analysis Services.
- Modelos semánticos basados en una conexión dinámica a un modelo semántico de Power BI en otra área de trabajo. Para obtener más información, consulte Introducción a los modelos semánticos en áreas de trabajo.
- Modelos semánticos con datos de inserción mediante la API REST.
- Modelos semánticos en Mi área de trabajo.
- Modelos semánticos del libro de Excel.
Alias del servidor o el área de trabajo
Los alias de nombre de servidor, que se admiten en Azure Analysis Services, no son compatibles con las áreas de trabajo Premium.
Seguridad
Además de que el administrador de capacidad habilite la lectura y escritura de la propiedad del punto de conexión XMLA, la opción de nivel de inquilino Permitir puntos de conexión XMLA y Analizar en Excel con modelos semánticos locales debe estar habilitada en el portal de administración. Si necesita generar archivos de Analizar en Excel (AIXL) que se conecten al punto de conexión de XMLA, la configuración a nivel de inquilino Los usuarios pueden trabajar con modelos semánticos en Excel usando una conexión dinámica también debería estar habilitada. Ambas opciones están habilitadas de forma predeterminada.
Permitir puntos de conexión XMLA y Analizar en Excel con modelos semánticos locales es una opción de integración.
Los usuarios pueden trabajar con modelos semánticos en Excel usando una conexión dinámica es una configuración de exportación y uso compartido.
En la tabla siguiente se describen las implicaciones de ambas configuraciones:
| Configuración | Permitir puntos de conexión XMLA y Analizar en Excel con modelos semánticos locales = deshabilitado | Permitir puntos de conexión XMLA y Analizar en Excel con modelos semánticos locales = habilitado |
|---|---|---|
| Los usuarios pueden trabajar con modelos semánticos en Excel mediante una conexión dinámica = deshabilitado | XMLA: no permitido Analizar en Excel: no permitido |
XMLA: permitido Analizar en Excel: no permitido |
| Los usuarios pueden trabajar con modelos semánticos de Power BI en Excel mediante una conexión dinámica = habilitado | XMLA: no permitido Analizar en Excel: permitido |
XMLA: permitido Analizar en Excel: permitido |
El acceso a través del punto de conexión de XMLA respetará la pertenencia a grupos de seguridad establecida en el nivel de área de trabajo o aplicación.
Los colaboradores del área de trabajo y roles superiores tienen permisos para escribir modelos semánticos, que son los mismos que los de los administradores de bases de datos de Analysis Services. Pueden implementar nuevos modelos semánticos desde Visual Studio y ejecutar scripts de TMSL en SSMS.
Los usuarios con permisos para compilar modelos semánticos son equivalentes a los lectores de base de datos de Analysis Services. Pueden conectarse a los modelos semánticos y examinarlos para su uso y visualización. Se respetan las reglas de seguridad de nivel de fila (RLS) y no pueden ver los metadatos del modelo semántico interno.
En general, las operaciones que requieren permisos de administrador del servidor de Analysis Services (en lugar de administrador de base de datos) no se admiten.
Suplantación
La suplantación de usuario mediante la propiedad de cadena de conexión EffectiveUserName se admite al conectarse a modelos semánticos del área de trabajo Premium. La cuenta especificada en EffectiveUserName debe estar en Microsoft Entra ID del inquilino y debe tener los permisos Read y Build para el modelo semántico al que se está conectando. Si la cuenta no tiene permisos de lectura y compilación, Power BI no puede suplantar la cuenta de usuario. La conexión no se establece y se devuelve un error.
También puede realizar la suplantación especificando uno o varios roles de área de trabajo en la propiedad Roles de la cadena de conexión. Con la propiedad Roles, puede probar la degradación de los miembros del rol con permisos de escritura a permisos de lectura. Los siguientes permisos de rol se aplican en función de la cuenta del usuario que haya iniciado sesión:
Si el usuario que realiza la suplantación es administrador del área de trabajo, que en realidad equivale a administrador de servidor en Analysis Services, no es necesario que sea miembro de ninguno de los roles especificados.
Si el usuario que realiza la suplantación no es administrador del área de trabajo, debe pertenecer a uno o varios de los roles especificados; de lo contrario, se devuelve un error de tipo usuario no encontrado o sin permisos.
Roles de modelo
Con el punto de conexión XMLA, los roles, la pertenencia a roles, la seguridad de nivel de fila (RLS) y la seguridad de nivel de objeto (OLS) se pueden definir para los usuarios en Microsoft Entra ID del inquilino. Los roles de modelo de Power BI se usan solo para RLS y OLS. Use el modelo de seguridad de Power BI para controlar los permisos por encima de RLS y OLS.
En el caso de los proyectos de modelos tabulares que se crean en Visual Studio, los roles se pueden definir mediante el administrador de roles en el diseñador de modelos. En el caso de los modelos semánticos de Power BI, se pueden definir roles en Power BI Desktop antes de publicarlos en el servicio. La pertenencia a roles se especifica en el servicio Power BI. También se puede usar SSMS para crear y administrar roles. En la mayoría de los casos, las definiciones de objetos de roles pueden programarse mediante TMSL para crear o modificar el objeto Roles. Los scripts de TMSL se pueden ejecutar en SSMS o con el cmdlet Invoke-ASCmd de PowerShell.
Al trabajar con roles de conjunto de datos mediante el punto de conexión XMLA, se aplican las siguientes limitaciones:
- El único permiso para un rol que se puede establecer para modelos semánticos es el de lectura. Otros permisos se conceden mediante el modelo de seguridad de Power BI.
- Las entidades de servicio no funcionan con RLS y OLS y no se pueden agregar como miembros de rol de modelo.
- El permiso de compilación para un modelo semántico es necesario para el acceso de lectura a través del punto de conexión de XMLA, independientemente de la existencia de roles de modelo semántico.
Configuración de credenciales de origen de datos
Los metadatos especificados mediante el punto de conexión XMLA pueden crear conexiones a orígenes de datos, pero no pueden establecer credenciales de origen de datos. En su lugar, las credenciales se pueden establecer en la página de configuración del modelo semántico del servicio Power BI.
Entidades de servicio
Las entidades de servicio son un registro de aplicación de Microsoft Entra que crea en el inquilino para realizar operaciones de nivel de servicio y recursos desatendidos. Se trata de un tipo único de identidad de usuario con el nombre de la aplicación, el identificador de la aplicación, el identificador del inquilino y el secreto de cliente o el certificado como contraseña. Power BI Premium usa la misma funcionalidad de entidad de servicio que Power BI Embedded.
También se pueden usar entidades de servicio con el punto de conexión XMLA para automatizar tareas de administración de modelos semánticos tales como el aprovisionamiento de áreas de trabajo, la implementación de modelos y la actualización de modelos semánticos, mediante:
- PowerShell
- Azure Automation
- Azure Logic Apps
- Aplicaciones cliente personalizadas
Para obtener más información, consulte Automatización de tareas de modelo semántico y área de trabajo Premium con entidades de servicio.
Implementación de proyectos de modelo desde Visual Studio (SSDT)
La implementación de un proyecto de modelo tabular en Visual Studio en un área de trabajo Premium es muy similar a la implementación en un servidor de Azure o SQL Server Analysis Services. Las únicas diferencias se encuentran en la propiedad del servidor de implementación especificada para el proyecto y en cómo se especifican las credenciales del origen de datos para que las operaciones de procesamiento puedan importar datos de orígenes de datos en el nuevo modelo semántico del área de trabajo.
Para implementar un proyecto de modelo tabular creado en Visual Studio, establezca la dirección URL de la conexión del área de trabajo en la propiedad Servidor de implementación del proyecto. En Visual Studio, en Explorador de soluciones, haga clic con el botón derecho en el proyecto >Propiedades. En la propiedad Servidor, pegue la dirección URL de la conexión del área de trabajo.
Cuando se ha especificado la propiedad Servidor de implementación, se puede implementar el proyecto.
Cuando se implementa la primera vez, se crea un modelo semántico en el área de trabajo utilizando los metadatos de model.bim. Como parte de la operación de implementación, una vez creado el modelo semántico en el área de trabajo desde los metadatos del modelo, el procesamiento para cargar los datos en el modelo semántico a partir de los orígenes de datos producirá un error.
El procesamiento produce errores porque, a diferencia de la implementación en una instancia de Azure o SQL Server Analysis Server, donde se le solicitan las credenciales de origen de datos como parte de la operación de implementación, al implementar en un espacio de trabajo Premium no se pueden especificar las credenciales de origen de datos como parte de la operación de implementación. En su lugar, una vez que la implementación de metadatos se ha realizado correctamente y se ha creado el modelo semántico, las credenciales del origen de datos se especifican en el servicio Power BI en la configuración del modelo semántico. En el área de trabajo, seleccione Modelos semánticos>Configuración>Credenciales del origen de datos>Editar credenciales.
Cuando se especifican las credenciales del origen de datos, puede actualizar el modelo semántico en el servicio Power BI, configurar la actualización de la programación o procesar (actualizar) desde SQL Server Management Studio para cargar datos en el modelo semántico.
Se observa la propiedad Opción de procesamiento especificada en el proyecto de Visual Studio. Sin embargo, si un origen de datos aún no tiene credenciales especificadas en el servicio Power BI, aunque la implementación de los metadatos se realice correctamente, se producirá un error de procesamiento. Puede establecer la propiedad en No procesar, que impide que los intentos se procesen como parte de la implementación. Es posible que quiera volver a establecer la propiedad en el valor Predeterminado porque, una vez especificadas las credenciales del origen de datos en la configuración del origen de datos para el nuevo modelo semántico, el procesamiento como parte de las operaciones de implementación posteriores se realizará correctamente.
Conectarse con SSMS
El uso de SSMS para conectarse a un área de trabajo es igual que conectarse a un servidor de Azure o SQL Server Analysis Services. La única diferencia es que se especifica la dirección URL del área de trabajo en el nombre del servidor y se debe usar la autenticación Active Directory - Universal con MFA.
Conexión a un área de trabajo con SSMS
En SQL Server Management Studio, seleccione Conectar>Conectar con el servidor.
En Tipo de servidor, seleccione Analysis Services. En Nombre del servidor, escriba la dirección URL del área de trabajo. En Autenticación, seleccione Active Directory - Universal con MFA y, después, en Nombre de usuario, escriba el identificador de usuario de la organización.
Cuando se haya conectado, el área de trabajo se muestra como un servidor de Analysis Services, y los modelos semánticos del área de trabajo se muestran como bases de datos.
Para más información sobre el uso de SSMS para programar metadatos, consulte:
Actualización del modelo semántico
El punto de conexión de XMLA habilita una amplia gama de escenarios para la funcionalidad de actualización específica mediante SSMS, la automatización con PowerShell, Azure Automation y Azure Functions mediante TOM. Por ejemplo, puede actualizar ciertas particiones históricas de actualizaciones incrementales sin tener que volver a cargar todos los datos históricos.
A diferencia de la configuración de la actualización en el servicio Power BI, las operaciones de actualización a través del punto de conexión de XMLA no se limitan a 48 actualizaciones al día, y no se impone el tiempo de espera de actualización programado.
La fecha, la hora y el estado de las operaciones de actualización del modelo semántico que incluyen una transacción de escritura a través del punto de conexión XMLA se registran y se muestran en el historial de actualizaciones del modelo semántico.
Nota:
Las operaciones de actualización realizadas por el punto de conexión XMLA no actualizan automáticamente las cachés de iconos. Las cachés de iconos solo se actualizan cuando un usuario accede al informe.
Vistas de administración dinámica (DMV)
Las vistas de administración dinámica de Analysis Services proporcionan visibilidad de metadatos del modelo semántico, así como su linaje y uso de recursos. Las vistas de administración dinámica disponibles para realizar consultas en Power BI a través del punto de conexión de XMLA se limitan a, como máximo, las que requieren permisos de administrador de base de datos. Por ejemplo, no se puede tener acceso a algunas vistas de administración dinámica porque requieren permisos de administrador de servidor de Analysis Services.
Modelos semánticos creados por Power BI Desktop
Metadatos mejorados
Las operaciones de escritura de XMLA en modelos semánticos creados en Power BI Desktop y que se publican en un área de trabajo Premium requieren metadatos mejorados. Para obtener más información, consulte Uso de metadatos de modelos semánticos mejorados.
Precaución
En este momento, una operación de escritura en un modelo semántico creado en Power BI Desktop impide que se descargue de nuevo como archivo PBIX. Asegúrese de conservar el archivo PBIX original.
Declaración del origen de datos
Al conectarse a orígenes de datos y consultar datos, Power BI Desktop utiliza expresiones de Power Query M como declaraciones de orígenes de datos en línea. Aunque se admite en áreas de trabajo Premium, la declaración de origen de datos en línea de Power Query M no es compatible con Azure Analysis Services ni SQL Server Analysis Services. En su lugar, las herramientas de modelado de datos de Analysis Services como Visual Studio crean metadatos con declaraciones de origen de datos de tipo estructurado o proveedor. Con el punto de conexión de XMLA, Premium también admite orígenes de datos estructurados y de proveedor, pero no como parte de las declaraciones de orígenes de datos en línea de Power Query M en modelos de Power BI Desktop. Para obtener más información, consulte Descripción de los proveedores.
Power BI Desktop en modo de conexión directa
Power BI Desktop puede conectarse a un modelo semántico de Power BI Premium mediante una conexión dinámica. Con una conexión dinámica, no es necesario replicar los datos localmente. Así, es más fácil que los usuarios consuman modelos semánticos. Los usuarios pueden conectarse de dos maneras:
Seleccione Modelos semánticos de Power BI y, a continuación, seleccione un modelo semántico para crear un informe. Esto es lo que se recomienda a los usuarios para conectarse a los modelos semánticos de forma dinámica. Este método mejora la detección, ya que muestra el nivel de aprobación de los modelos semánticos. No es necesario que los usuarios busquen y realicen un seguimiento de las URL del área de trabajo. Para buscar un modelo semántico, los usuarios simplemente escriben el nombre del modelo semántico o se desplazan hasta encontrar el modelo semántico que buscan.
Con Obtener datos>Analysis Services, especifique un nombre de área de trabajo de Power BI Premium como dirección URL, seleccione Conectarse en directo y, luego, en el Navegador, seleccione un modelo semántico. En este caso, Power BI Desktop usa el punto de conexión XMLA para conectarse dinámicamente al modelo semántico como si fuera un modelo de datos de Analysis Services.
Las organizaciones que tienen informes existentes conectados dinámicamente a los modelos de datos de Analysis Services y pretenden migrar a los modelos semánticos Premium solo tienen que cambiar la URL del nombre del servidor en Transformar datos>Configuración del origen de datos.
Registros de auditoría
Cuando las aplicaciones se conectan a un área de trabajo, el acceso a través de puntos de conexión de XMLA se registra en los registros de auditoría de Power BI con las operaciones siguientes:
| Nombre descriptivo de la operación | Nombre de operación |
|---|---|
| Conectado al modelo semántico de Power BI desde una aplicación externa | ConnectFromExternalApplication |
| Actualización del modelo semántico de Power BI solicitada desde una aplicación externa | RefreshDatasetFromExternalApplication |
| Modelo semántico de Power BI creado a partir de una aplicación externa | CreateDatasetFromExternalApplication |
| Modelo semántico de Power BI editado desde una aplicación externa | EditDatasetFromExternalApplication |
| Modelo semántico de Power BI eliminado de la aplicación externa | DeleteDatasetFromExternalApplication |
Para más información, vea Auditoría de Power BI.
Consideraciones y limitaciones
Los modelos semánticos predeterminados de Power BI no pueden modificarse usando el punto de conexión XMLA.
Contenido relacionado
Para más información relacionada con este artículo, consulte: