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 usan un punto de conexión XMLA para admitir la conectividad de plataforma abierta desde aplicaciones y herramientas cliente de Microsoft y de terceros.

Puntos de conexión XMLA

Las áreas de trabajo usan el protocolo XML for Analysis (XMLA) para las comunicaciones entre aplicaciones cliente y el motor que administra las áreas de trabajo de Power BI y los modelos semánticos. 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, está habilitada la conectividad de solo lectura mediante el punto de conexión para la carga de trabajo de modelos semánticos en una capacidad. Con las herramientas y aplicaciones de visualización de datos de solo lectura puede consultar datos del modelo semántico, metadatos, eventos y esquema.

Se pueden habilitar las operaciones de lectura y escritura mediante el punto de conexión. La lectura y escritura proporciona más administración de modelos semánticos, gobernanza, modelado semántico avanzado, depuración y supervisión. Cuando se habilita, los modelos semánticos tienen más paridad con las herramientas y procesos 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 muchas propiedades de servidor de Analysis Services. Para revisar estas propiedades, 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 usuario único : la aplicación usa una sola cuenta de usuario o una identidad de aplicación para acceder a un modelo semántico de Power BI a través del punto de conexión XMLA. Algunos ejemplos de aplicaciones de usuario único incluyen herramientas de desarrollo, scripts de administración y procesos automatizados. Estas aplicaciones pueden realizar tareas como el modelado de datos y las tareas administrativas que modifican los metadatos de un modelo semántico, una operación de copia de seguridad o restauración o desencadenan una actualización de datos. La identidad de la aplicación o la cuenta de usuario 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 multiusuario : 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.

• Áreas de trabajo Premium por usuario (PPU): la aplicación debe requerir que cada usuario 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 u otra identidad de aplicación para realizar tareas en nombre de usuarios individuales. Cada usuario debe tener su propia cuenta de Power BI para abrir informes, acceder a modelos semánticos y ejecutar consultas.
• En el caso de las á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

Aplicaciones y herramientas comunes que se usan con Azure Analysis Services y SQL Server Analysis Services que ahora son compatibles con modelos semánticos de Power BI Premium:

Microsoft Excel : 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. Solo lectura es necesaria para las operaciones de consulta. Requiere la versión Click-to-Run 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, incluidas la edición gratuita Community, admiten extensiones de proyectos de Analysis Services. Requiere la extensión versión 2.9.14 o posterior para implementar modelos tabulares en un área de trabajo Premium. El modelo debe estar en el nivel de compatibilidad 1500 o superior para implementar. Requiere lectura y escritura XMLA en la tarea de modelos semánticos. Para 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 a nivel fino y guionización de metadatos de modelo semántico mediante el Lenguaje de Scripting de Modelos Tabulares (TMSL). Requiere solo lectura para las operaciones de consulta. Requiere lectura y escritura para los metadatos de scripting. Requiere SSMS versión 18.9 o posterior. Descargue SSMS.

SQL Server Profiler : SQL Server Profiler se instala con SSMS, permite el seguimiento y la depuración de eventos de 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. Requiere SQL Server Profiler versión 18.9 o posterior. Los usuarios deben especificar el modelo semántico (catálogo inicial) al conectarse con el punto de conexión XMLA. Para obtener más información, consulteSQL Server Profiler for Analysis Services.

Asistente para la implementación de Analysis Services: instalado con SSMS, esta herramienta permite la implementación de proyectos de modelos tabulares creados en Visual Studio en Analysis Services y áreas de trabajo Premium. Se puede ejecutar de forma interactiva o desde la línea de comandos para la automatización. Se requiere lectura y escritura XMLA. Para más información, consulte Asistente para la implementación de Analysis Services.

Cmdlets de PowerShell - Utilice los cmdlets de Analysis Services para automatizar tareas de gestión de modelos semánticos, como las operaciones de actualización. Requiere lectura y escritura XMLA. Requiere la versión 21.1.18256 o posterior del módulo sqlServer de PowerShell. Los cmdlets de Azure Analysis Services en el módulo Az.AnalysisServices no se admiten para los modelos semánticos de Power BI. Para más información, consulte la Referencia de PowerShell de Analysis Services.

Generador de informes de Power BI : una herramienta para crear informes paginados. Cree una definición de informe que especifique los datos que se van a recuperar, dónde obtenerlos y cómo mostrarlos. Puede obtener una vista previa del informe en el Generador de informes y, a continuación, publicar el informe en el servicio Power BI. Requiere XMLA de lectura únicamente. Para más información, consulte Generador de informes de Power BI.

Editor tabular 2.x : una herramienta de código abierto para crear, mantener y administrar modelos tabulares mediante un editor intuitivo y ligero. Una vista jerárquica muestra todos los objetos del modelo tabular. Organiza los objetos mediante carpetas de visualización compatibles con la edición de propiedades de selección múltiple y el resaltado de sintaxis DAX. Requiere XMLA en modo de solo lectura para las operaciones de consulta. Requiere lectura y escritura para las operaciones de metadatos. Para más información, consulte Editor tabular 2.x.

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 XMLA de solo lectura para las operaciones de consulta. Para más información, consulte daxstudio.org.

ALM Toolkit : herramienta de comparación de esquemas de código abierto para modelos semánticos de Power BI, que se usan con más frecuencia en escenarios de administración del ciclo de vida de las aplicaciones (ALM). Realice la implementación entre entornos y conserve los datos históricos de actualización incremental. Diferenciar y combinar 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 más información, consulte alm-toolkit.com.

Tercero - incluye aplicaciones y herramientas de visualización de datos de cliente que pueden conectarse, consultar y consumir modelos semánticos en áreas de trabajo Premium. 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 XMLA de solo lectura o de lectura y escritura dependerá de las operaciones.

Bibliotecas de cliente

Las aplicaciones y herramientas cliente no se comunican directamente con el punto de conexión XMLA. En su lugar, usan bibliotecas cliente como una capa de abstracción. Estas son las mismas bibliotecas 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 la extensión de proyectos de Analysis Services para Visual Studio instalan las tres bibliotecas cliente y las actualizan junto con actualizaciones de aplicaciones y extensiones normales. Los desarrolladores pueden usar las bibliotecas cliente para compilar aplicaciones personalizadas. En algunos casos, especialmente con aplicaciones de terceros, si no se instala con la aplicación, podría ser necesario instalar versiones más recientes de las bibliotecas cliente. Las bibliotecas cliente se actualizan mensualmente. Para obtener más información, consulte Bibliotecas Cliente para conectarse a Analysis Services.

Optimización de modelos semánticos para operaciones de escritura habilitando modelos grandes

Al usar el punto de conexión XMLA para la administración de modelos semánticos con operaciones de escritura, se recomienda habilitar el modelo semántico para modelos grandes. Esto reduce la sobrecarga de las operaciones de escritura, lo que puede hacer que sean considerablemente más rápidas. Para los modelos semánticos de más de 1 GB (después de la compresión), la diferencia puede ser significativa. Para obtener más información, consulte Modelos grandes en Power BI Premium.

Habilitación de la lectura y escritura de XMLA

De forma predeterminada, la capacidad Premium o las cargas de trabajo del modelo semántico Premium por usuario tienen habilitada la configuración de la propiedad del punto de conexión XMLA para solo lectura. Esto significa que las aplicaciones solo pueden consultar un modelo semántico. Para que las aplicaciones realicen operaciones de escritura, la propiedad Punto de conexión XMLA debe estar habilitada para lectura y escritura.

Para activar las funciones de lectura y escritura en una capacidad Premium

1. Seleccione Configuración>Portal de administración.

2. En el portal de administración, seleccione Configuración> de capacidad Nombre de capacidad dePower BI Premium>.

3. Expanda Cargas de trabajo. En la configuración Punto de conexión XMLA, seleccione Lectura y escritura. La configuración del punto de conexión XMLA se aplica a todas las áreas de trabajo y los modelos semánticos que estén asignados a la capacidad.

   

Para activar lectura y escritura para Premium Por Usuario

1. Seleccione Configuración>Portal de administración.
2. En el portal de administración, seleccione Premium por usuario.
3. Expanda Configuración de carga de trabajo del modelo semántico. En la configuración del Punto de conexión 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 en 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 fuera 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 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 invitados B2B acceden a áreas de trabajo en un inquilinato diferente, el nombre de ese inquilinato debe especificarse en la dirección URL del origen de datos. Por ejemplo, cuando se invita a un usuario de contoso.com al cliente de fabrikam.com y se le concede permiso para acceder al "Área de trabajo de ventas", debe utilizar la siguiente 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 URL de conexión del espacio de trabajo

En configuración del área de trabajo>Premium>Conexión del área de trabajo, seleccione Copiar.

Requisitos de conexión

Catálogo inicial

Con algunas herramientas, como SQL Server Profiler, debe especificar un catálogo inicial, que es el modelo semántico (base de datos) al que conectarse en el área de trabajo. En el cuadro de diálogo Conectar con el servidor, seleccione Opciones>propiedades> de conexiónConectar a la base de datos, escriba el nombre del modelo semántico.

Nombres de área de trabajo duplicados

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 área de trabajo, es posible que reciba el siguiente mensaje:

No se puede conectar a powerbi://api.powerbi.com/v1.0/[tenant name]/[workspace name].

Para solucionarlo, además del nombre del espacio de trabajo, especifique ObjectIDGuid. Puede copiar ObjectIDGuid desde el objectID del área de trabajo en 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 - aaaabbbb-0000-cccc-1111-dddd2222eeee.

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 tanto el nombre del modelo semántico como 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 cambiados de nombre pueden tardar hasta unos minutos en aparecer.

Modelos semánticos no compatibles

Los siguientes modelos semánticos no son accesibles mediante el punto de conexión XMLA. Estos modelos semánticos no aparecerán en el área de trabajo en SSMS ni 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 más información, consulte Introducción a los modelos semánticos entre áreas de trabajo.
• Modelos semánticos con datos push utilizando la API REST.
• Modelos semánticos en Mi área de trabajo.
• Modelos semánticos del libro de trabajo de Excel.

Alias de servidor o área de trabajo

Los alias de nombre de servidor, compatibles con Azure Analysis Services, no se admiten para las áreas de trabajo Premium.

Security

Además de que la propiedad Punto de conexión XMLA esté habilitada para lectura y escritura por el administrador de capacidad, la configuración a nivel de arrendatario 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 Análisis en Excel (AIXL) que se conectan al punto de conexión XMLA, la configuración de nivel de inquilino Los usuarios pueden trabajar con modelos semánticos en Excel mediante una conexión dinámica también deben estar habilitadas. Esta configuración está habilitada de forma predeterminada.

Permitir puntos de conexión XMLA y Analizar en Excel con modelos semánticos locales es una configuración de integración.

Los usuarios pueden trabajar con modelos semánticos en Excel mediante una conexión dinámica es una configuración de exportación y compartición.

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 = deshabilitada	XMLA: no permitido Analizar en Excel: no permitido	XMLA: permitido Analizar en Excel: no permitido
Los usuarios pueden trabajar con modelos semánticos en Excel mediante una conexión dinámica = habilitada	XMLA: no permitido Analizar en Excel: permitido	XMLA: permitido Analizar en Excel: permitido

El acceso a través del punto de conexión XMLA respetará la pertenencia a grupos de seguridad establecido en el nivel de área de trabajo o aplicación.

Los colaboradores del área de trabajo y superiores tienen permisos para escribir en el modelo semántico, que son prácticamente 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 TMSL en SSMS.

Los usuarios con permisos para crear un modelo semántico son equivalentes a los usuarios que pueden leer bases de datos de Analysis Services. Pueden conectarse a modelos semánticos y explorarlos para su consumo y visualización. Se respetan las reglas de seguridad de nivel de fila (RLS) y no pueden ver metadatos del modelo semántico interno.

Las operaciones que requieren permisos de administrador del servidor de Analysis Services (en lugar de administrador de base de datos) en general no se admiten.

Para más información, consulte Permisos de modelo semántico y Roles en áreas de trabajo.

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 el identificador de Entra de Microsoft del inquilino y debe tener permisos de lectura y compilación 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. Se producirá un error en la conexión y se devolverá un error.

También puede realizar la suplantación especificando uno o varios roles de área de trabajo en la propiedad de la cadena de conexión Roles. Con la propiedad Roles, puede probar la degradación de miembros de rol de permisos de escritura a permisos de lectura. Los permisos de rol siguientes se aplican en función de la cuenta del usuario que ha iniciado sesión:

• Si el usuario que realiza la suplantación es un administrador del área de trabajo, que es eficazmente el mismo que un administrador de servidor en Analysis Services, no es necesario ser miembro de ninguno de los roles especificados.

• Si el usuario que realiza la suplantación no es un administrador del espacio de trabajo, debe pertenecer a uno o varios de los roles especificados; de lo contrario, se devuelve un error de usuario no encontrado o de falta de permisos.

Roles de modelo

Con el punto de conexión XMLA, se pueden definir los roles, la pertenencia a roles, la seguridad de nivel de fila (RLS) y la seguridad de nivel de objeto (OLS) para los usuarios en el Microsoft Entra ID del inquilino. Los roles de modelo en Power BI solo se usan para RLS y OLS. Use el modelo de seguridad de Power BI para controlar los permisos más allá de RLS y OLS.

En el caso de los proyectos de modelos tabulares creados 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 en Power BI, los roles se pueden definir en Power BI Desktop antes de publicarlos en el servicio. La pertenencia a roles se especifica en el servicio Power BI. SSMS también se puede usar para crear y administrar roles. En la mayoría de los casos, las definiciones de objetos de rol se pueden escribir scripts usando TMSL para crear o modificar el objeto Roles. Los scripts TMSL se pueden ejecutar en SSMS o con el cmdlet Invoke-ASCmd de PowerShell.

Se aplican las limitaciones siguientes al trabajar con roles a través del punto de conexión XMLA:

• El único permiso para un rol que se puede establecer para los modelos semánticos es el permiso de lectura. Se conceden otros permisos mediante el modelo de seguridad de Power BI.
• Los principales de servicio no funcionan con RLS y OLS, y no se pueden agregar como miembros de roles del modelo.
• Se requiere permiso de compilación para un modelo semántico para el acceso de lectura a través del punto de conexión XMLA, independientemente de la existencia de roles de modelo semántico.

Establecimiento de credenciales de origen de datos

Los metadatos especificados a través del 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 en el servicio Power BI.

Principales del servicio

Los principios de servicio son un registro de aplicación de Microsoft Entra que usted crea en su inquilino para realizar operaciones de recursos y servicios sin supervisión. Son un tipo único de identidad de usuario con un nombre de aplicación, un identificador de aplicación, un identificador de inquilino y un secreto de cliente o un certificado para una contraseña. Power BI Premium usa la misma funcionalidad de principal de servicio que Power BI Embedded.

Las entidades de servicio se pueden usar con el punto de conexión XMLA para automatizar tareas de administración de modelos semánticos, como aprovisionamiento de áreas de trabajo, despliegue de modelos y actualización semántica de modelos con:

• PowerShell
• Azure Automation
• Azure Logic Apps
• Aplicaciones cliente personalizadas

Para más información, consulte Automatización del área de trabajo Premium y tareas de modelo semántico con entidades de servicio.

Detección de modelos semánticos

Cuando la configuración a nivel de inquilino Bloquear volver a publicar y deshabilitar la actualización de paquetes está habilitada, un usuario solo podrá descubrir aquellos modelos semánticos usando el Endpoint XMLA del cual son propietarios. Si un usuario no es el propietario de un modelo semántico, es equivalente a un lector de base de datos de Analysis Services, incluso cuando es administrador,miembro o colaborador en el área de trabajo.

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 Deployment Server especificada para el proyecto y cómo se especifican las credenciales del origen de datos para que las operaciones de procesamiento puedan importar datos de orígenes de datos al nuevo modelo semántico en el área de trabajo.

Para implementar un proyecto de modelo tabular creado en Visual Studio, establezca la dirección URL de conexión del área de trabajo en la propiedad Project Deployment Server . En Visual Studio, en el Explorador de soluciones, haga clic con el botón derecho en propiedades > En la propiedad Server , pegue la dirección URL de conexión del área de trabajo.

Cuando se especifica la propiedad Deployment Server, se puede implementar el proyecto.

Cuando se implementa la primera vez, se crea un modelo semántico en el área de trabajo mediante metadatos de model.bim. Como parte de la operación de implementación, después de crear el modelo semántico en el área de trabajo a partir de metadatos del modelo, se producirá un error en el procesamiento para cargar datos en el modelo semántico desde orígenes de datos.

El procesamiento falla porque, a diferencia de la implementación en una instancia de Azure o de SQL Server Analysis Services, donde se le solicita que proporcione credenciales del origen de datos como parte del proceso de implementación, al implementar en un área de trabajo Premium no se pueden especificar credenciales del origen de datos como parte de la operación de implementación. En su lugar, después de que la implementación de metadatos se haya realizado correctamente y se cree 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 programada o la actualización desde SQL Server Management Studio para cargar datos en el modelo semántico.

Se observa la propiedad Opción de Procesamiento de Despliegue especificada en el proyecto en Visual Studio. Sin embargo, si un origen de datos no tiene credenciales especificadas en el servicio Power BI, aunque la implementación de metadatos se realice correctamente, se producirá un error en el procesamiento. Puede establecer la propiedad en No procesar, lo que impide que los intentos se procesen como parte de la implementación. Es posible que desee volver a establecer la propiedad en Default 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 especificar la dirección URL del área de trabajo en el nombre del servidor y debe usar Active Directory - Universal con autenticación MFA .

Conexión a un área de trabajo mediante SSMS

1. En SQL Server Management Studio, seleccione Conectar>con el servidor.

2. 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 está 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 generar scripts de metadatos, consulte:

• Creación de scripts de Analysis Services
• Lenguaje de Secuencias de Comandos de Modelos Tabulares (TMSL)

Actualización del modelo semántico

El punto de conexión XMLA permite una amplia gama de escenarios para funcionalidades de actualización específicas mediante SSMS, automatización con PowerShell, Azure Automation y Azure Functions mediante TOM. Por ejemplo, puede actualizar determinadas particiones históricas de actualización incremental 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 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 semántica del modelo 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 actualización 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 (Dynamic Management Views - DMV)

Las DMV de Analysis Services proporcionan visibilidad de los metadatos del modelo semántico, el linaje y el uso de recursos. Las DMV disponibles para realizar consultas en Power BI a través del punto de conexión XMLA están limitadas, como máximo, a las que requieren permisos de administrador de base de datos. Algunas DMV, por ejemplo, no son accesibles porque requieren permisos de administrador del servidor de Analysis Services.

Modelos semánticos creados por Power BI Desktop

Metadatos mejorados

Las operaciones de escritura xmlA en modelos semánticos creados en Power BI Desktop y publicados en un área de trabajo Premium requieren metadatos mejorados. Para más información, consulte Metadatos del modelo semántico mejorado.

Precaución

En este momento, una operación de escritura en un modelo semántico creado en Power BI Desktop impide que se descargue como un archivo PBIX. Asegúrese de conservar su archivo PBIX original.

Declaración del origen de datos

Al conectarse a orígenes de datos y consultar datos, Power BI Desktop usa expresiones M de Power Query como declaraciones de origen de datos en línea. Aunque se admite en áreas de trabajo Premium, la declaración del origen de datos insertado 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 mediante declaraciones de orígenes de datos estructurados o de proveedor . Con el punto de conexión XMLA, Premium también admite orígenes de datos estructurados y de proveedor, pero no como parte de las declaraciones en línea de orígenes de datos de Power Query M en los modelos de Power BI Desktop. Para más información, consulte Descripción de los proveedores.

Power BI Desktop en modo de conexión en vivo

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, los datos no necesitan replicarse localmente, lo que facilita a los usuarios consumir modelos semánticos. Hay dos maneras en que los usuarios pueden conectarse:

• Seleccione Modelos semánticos de Power BI y, a continuación, seleccione un modelo semántico para crear un informe. Esta es la manera recomendada para que los usuarios se conecten dinámicamente a modelos semánticos. Este método proporciona una experiencia de detección mejorada que muestra el nivel de aprobación de los modelos semánticos. Los usuarios no necesitan buscar y realizar un seguimiento de las direcciones URL del área de trabajo. Para buscar un modelo semántico, los usuarios simplemente escriben el nombre del modelo semántico o desplazan para encontrar el modelo semántico que buscan.

  

• Con Obtener Data>Analysis Services, especifique un nombre de área de trabajo de Power BI Premium como una dirección URL, seleccione Conectar en directo y, a continuación, en Navegador, seleccione un modelo semántico. En este caso, Power BI Desktop usa el punto de conexión XMLA para conectarse al modelo semántico como si fuera un modelo de datos de Analysis Services.

  

Las organizaciones que tienen informes existentes conectados en directo a los modelos de datos de Analysis Services y que piensan migrar a modelos semánticos Premium solo tienen que cambiar la dirección URL del nombre del servidor en transformar>.

Registros de auditoría

Cuando las aplicaciones se conectan a un área de trabajo, el acceso a través de puntos de conexión XMLA se registra en los registros de auditoría de Power BI con las siguientes operaciones:

Nombre amigable de la operación	Nombre de la operación
Conectado al modelo semántico de Power BI desde una aplicación externa	ConectarDesdeAplicaciónExterna
Actualización del modelo semántico de Power BI solicitada desde una aplicación externa	RefrescarConjuntoDeDatosDesdeAplicaciónExterna
Creación de un modelo semántico de Power BI a partir de una aplicación externa	CrearConjuntoDeDatosDesdeAplicaciónExterna
Modelo semántico de Power BI editado desde una aplicación externa	EditarConjuntoDeDatosDesdeAplicaciónExterna
Modelo semántico de Power BI eliminado de una aplicación externa	EliminarConjuntoDeDatosDeAplicaciónExterna

Para más información, consulte Auditoría de Power BI.

Consideraciones y limitaciones

Los modelos semánticos predeterminados de Power BI no se pueden modificar mediante el punto de conexión XMLA.

Contenido relacionado

Para obtener más información relacionada con este artículo, consulte:

• Escenarios de uso de Power BI: Administración avanzada de modelos de datos
• ¿Preguntas? Pruebe a preguntar a la comunidad de Power BI
• ¿Sugerencias? Ideas para contribuir a mejorar Power BI