Desarrollo de aplicaciones multiinquilino escalables con la inserción de Power BI

En este artículo se describe cómo desarrollar una aplicación multiinquilino que inserta contenido de Power BI y a la vez consigue los niveles más altos de escalabilidad, rendimiento y seguridad. Al diseñar e implementar una aplicación con perfiles de entidad de servicio, puede crear y administrar una solución multiinquilino que consta de decenas de miles de inquilinos de clientes que pueden entregar informes a audiencias de más de 100 000 usuarios.

Los perfiles de entidad de servicio son una característica que facilita la administración del contenido organizativo en Power BI y permite usar las capacidades de forma más eficaz. Sin embargo, el uso de perfiles de entidad de servicio puede agregar complejidad al diseño de la aplicación. Por lo tanto, solo debe usarlos cuando sea necesario conseguir una escala significativa. Se recomienda usar perfiles de entidad de servicio cuando tenga muchas áreas de trabajo y más de 1000 usuarios de aplicaciones.

Puede lograr la inserción de Power BI mediante dos escenarios de inserción diferentes: Insertar para la organización e Insertar para el cliente.

El escenario de Insertar para la organización se aplica cuando la audiencia de la aplicación consta de usuarios internos. Los usuarios internos tienen cuentas organizativas y deben autenticarse con el identificador de Microsoft Entra. En este escenario, Power BI es un software como servicio (SaaS). A veces, el escenario se conoce como de Usuario propietario de los datos.

El escenario de Insertar para el cliente se aplica cuando la audiencia de la aplicación consta de usuarios externos. La aplicación es responsable de autenticar a los usuarios. Para acceder a contenido de Power BI, la aplicación se basa en una identidad de inserción (entidad de servicio o cuenta de usuario maestra de Microsoft Entra) para autenticarse con Microsoft Entra. En este escenario, Power BI es una plataforma como servicio (PaaS). A veces, el escenario se conoce como de Aplicación propietaria de los datos.

Desarrollo de aplicaciones multiinquilino

Si está familiarizado con Microsoft Entra, la palabra inquilino podría llevarle a pensar en un inquilino de Microsoft Entra. Sin embargo, el concepto de inquilino es diferente en el contexto de la creación de una solución multiinquilino que inserta contenido de Power BI. En este contexto, se crea un inquilino de cliente en nombre de cada cliente para el que la aplicación inserta contenido de Power BI mediante el escenario de Insertar para el cliente. Normalmente, se aprovisiona cada inquilino de cliente mediante la creación de una única área de trabajo de Power BI.

Para crear una solución multiinquilino escalable, debe poder automatizar la creación de nuevos inquilinos de cliente. El aprovisionamiento de un nuevo inquilino de cliente normalmente implica escribir código que use la API REST de Power BI para crear un área de trabajo de Power BI, crear modelos semánticos importando archivos de Power BI Desktop (.pbix), actualizar parámetros de origen de datos, establecer credenciales de origen de datos y configurar la actualización del modelo semántico programado. En el diagrama siguiente se muestra cómo se pueden agregar elementos de Power BI, como informes y modelos semánticos, a áreas de trabajo para configurar inquilinos de clientes.

Al desarrollar una aplicación que usa el escenario de Insertar para el cliente, es posible realizar llamadas a la API REST de Power BI mediante una identidad de inserción que sea una cuenta de usuario maestra o una entidad de servicio. Se recomienda usar una entidad de servicio en el caso de aplicaciones de producción. Proporciona la mayor seguridad y, por este motivo, es el enfoque que recomienda Microsoft Entra. Además, admite una mejor automatización y escalado, y hay menos sobrecarga de administración. Sin embargo, requiere derechos de administrador de Power BI para configurar y administrar.

Mediante el uso de una entidad de servicio, puede evitar problemas comunes asociados a cuentas de usuario maestras, como errores de autenticación en entornos en los que los usuarios deben iniciar sesión mediante la autenticación multifactor (MFA). El uso de una entidad de servicio también es coherente con la idea de que el escenario de Insertar para el cliente se basa en la inserción de contenido de Power BI mediante una mentalidad de PaaS en lugar de una mentalidad de SaaS.

Limitación de 1000 áreas de trabajo

Al diseñar un entorno multiinquilino que implemente el escenario de Insertar para el cliente, asegúrese de tener en cuenta que la identidad de inserción no puede tener acceso concedido a más de 1000 áreas de trabajo. El servicio Power BI impone esta limitación para garantizar un buen rendimiento al realizar llamadas a la API REST. El motivo de esta limitación está relacionado con la forma en que Power BI mantiene los metadatos relacionados con la seguridad para cada identidad.

Power BI usa metadatos para realizar un seguimiento de las áreas de trabajo y los elementos del área de trabajo a los que puede acceder una identidad. En efecto, Power BI debe mantener una lista de control de acceso (ACL) independiente para cada identidad en su subsistema de autorización. Cuando una identidad realiza una llamada a la API REST para acceder a un área de trabajo, Power BI debe realizar una comprobación de seguridad con la ACL de la identidad para asegurarse de que tiene autorización. El tiempo necesario para determinar si el área de trabajo de destino está dentro de la ACL aumenta exponencialmente a medida que aumenta el número de áreas de trabajo.

Considere un escenario en el que se han configurado dos aplicaciones multiinquilino para usar una sola entidad de servicio. Ahora piense en el caso que la primera aplicación haya creado 990 áreas de trabajo, mientras que la segunda aplicación haya creado 1010 áreas de trabajo. Desde una perspectiva de compatibilidad, la primera aplicación se encuentra dentro de los límites admitidos, mientras que la segunda aplicación no lo está.

Ahora compare estas dos aplicaciones exclusivamente desde una perspectiva de rendimiento. No hay tanta diferencia, porque las ACL para ambas entidades de servicio han dejado que los metadatos de sus ACL crezcan hasta un punto en el que degradará el rendimiento en cierto modo.

Esta es la observación clave: el número de áreas de trabajo creadas por una entidad de servicio tiene un impacto directo en el rendimiento y la escalabilidad. Una entidad de servicio que sea miembro de 100 áreas de trabajo ejecutará llamadas a la API REST más rápidamente que una entidad de servicio que sea miembro de 1000 áreas de trabajo. Del mismo modo, una entidad de servicio que sea miembro de 10 áreas de trabajo ejecutará llamadas a la API REST más rápidamente que una entidad de servicio que sea miembro de 100 áreas de trabajo.

Administración del aislamiento de los modelos semánticos y las credenciales del origen de datos

Otro aspecto importante al diseñar una aplicación multiinquilino es aislar los inquilinos del cliente. Es fundamental que los usuarios de un inquilino de cliente no vean los datos que pertenecen a otro inquilino de cliente. Por lo tanto, debe comprender cómo administrar la propiedad del modelo semántico y las credenciales del origen de datos.

Titularidad del modelo semántico

Cada modelo semántico de Power BI tiene un único propietario, que puede ser una cuenta de usuario o una entidad de servicio. La titularidad del modelo semántico es necesaria para configurar la actualización programada y establecer los parámetros del modelo semántico.

Si es necesario, puede transferir la propiedad del modelo semántico a otra cuenta de usuario o entidad de servicio. Puede hacerlo en el servicio Power BI o mediante la operación TakeOver de la API REST. Al importar un archivo de Power BI Desktop para crear un nuevo modelo semántico mediante una entidad de servicio, la entidad de servicio se establece automáticamente como propietaria del modelo semántico.

Credenciales del origen de datos

Para conectar un modelo semántico a su origen de datos subyacente, el propietario del modelo semántico debe establecer las credenciales del origen de datos. Power BI cifra y almacena en caché las credenciales del origen de datos. A partir de este punto, Power BI usa esas credenciales para autenticarse con el origen de datos subyacente al actualizar los datos (para importar tablas de almacenamiento) o ejecutar consultas de paso a través (para tablas de almacenamiento de DirectQuery).

Se recomienda aplicar un patrón de diseño común al aprovisionar un nuevo inquilino de cliente. Puede ejecutar una serie de llamadas a la API REST con la identidad de la entidad de servicio:

1. Cree un área de trabajo nueva.
2. Asocie el área de trabajo nueva a una capacidad dedicada.
3. Importe un archivo de Power BI Desktop para crear un modelo semántico.
4. Establezca las credenciales de origen del modelo semántico para ese modelo semántico.

Al finalizar estas llamadas a la API REST, la entidad de servicio será un administrador del área de trabajo nueva y el propietario del modelo semántico y las credenciales del origen de datos.

Es posible que una entidad de servicio cree credenciales de origen de datos compartidas por modelos semánticos en diferentes áreas de trabajo entre inquilinos del cliente, como se muestra en el diagrama siguiente.

Cuando los modelos semánticos que pertenecen a distintos inquilinos de cliente comparten las credenciales del origen de datos, los inquilinos del cliente no están totalmente aislados.

Estrategias de diseño anteriores a los perfiles de entidad de servicio

Comprender las estrategias de diseño antes de que la característica de perfil de entidad de servicio esté disponible puede ayudarle a apreciar la necesidad de la característica. Anteriormente, los desarrolladores creaban las aplicaciones multiinquilino mediante una de las tres estrategias de diseño siguientes:

• Entidad de servicio única
• Agrupación de entidades de servicio
• Una entidad de servicio por área de trabajo

Existen pros y contras asociados a cada una de estas estrategias de diseño.

La estrategia de diseño de una entidad de servicio única requiere una sola creación de un registro de aplicación de Microsoft Entra. Por lo tanto, implica menos sobrecarga administrativa que las otras dos estrategias de diseño, porque no hay ningún requisito para crear más registros de aplicaciones de Microsoft Entra. Esta estrategia también es la más sencilla de configurar porque no requiere escribir código adicional que cambie el contexto de llamada entre entidades de servicio al realizar llamadas a la API REST. Sin embargo, un problema con esta estrategia de diseño es que no se escala. Solo admite un entorno multiinquilino que puede crecer hasta 1000 áreas de trabajo. Además, el rendimiento se degradará con toda seguridad a medida que se conceda a la entidad de servicio acceso a un mayor número de áreas de trabajo. También hay un problema con el aislamiento del inquilino del cliente, porque la entidad de servicio única se convierte en el propietario de cada modelo semántico y de todas las credenciales de datos en todos los inquilinos del cliente.

La estrategia de diseño de agrupación de entidades de servicio se usa normalmente para evitar la limitación de 1000 áreas de trabajo. Permite que la aplicación se escale a cualquier número de áreas de trabajo agregando el número correcto de entidades de servicio al grupo. Por ejemplo, un grupo de cinco entidades de servicio permite escalar verticalmente hasta 5000 áreas de trabajo; un grupo de 80 entidades de servicio permite escalar verticalmente hasta 80 000 áreas de trabajo, etc. Sin embargo, aunque esta estrategia permite escalar a un gran número de áreas de trabajo, tiene varias desventajas. En primer lugar, requiere escribir código adicional y almacenar metadatos para permitir el cambio de contexto entre entidades de servicio al realizar llamadas a la API REST. En segundo lugar, implica más esfuerzo administrativo porque deberá crear registros de aplicaciones de Microsoft Entra siempre que necesite aumentar el número de entidades de servicio del grupo.

Además, la estrategia de agrupación de entidades de servicio no está optimizada para el rendimiento porque permite que las entidades de servicio se conviertan en miembros de cientos de áreas de trabajo. Tampoco es ideal desde la perspectiva del aislamiento del inquilino del cliente, ya que las entidades de servicio pueden convertirse en propietarias del modelo semántico y las credenciales de datos compartidas entre los inquilinos del cliente.

La estrategia de diseño de una entidad de servicio por área de trabajo implica la creación de una entidad de servicio para cada inquilino del cliente. Desde una perspectiva teórica, esta estrategia ofrece la mejor solución, ya que optimiza el rendimiento de las llamadas a la API REST, a la vez que proporciona un aislamiento verdadero para modelos semánticos y credenciales de origen de datos en el nivel de área de trabajo. Sin embargo, lo que funciona mejor en teoría no es siempre lo que funciona mejor en la práctica. Esto se debe a que el requisito de crear una entidad de servicio para cada inquilino del cliente no resulta algo práctico para muchas organizaciones. El motivo es que algunas organizaciones tienen procesos de aprobación formales o implican una excesiva sobrecarga para crear registros de aplicaciones de Microsoft Entra. Estas razones pueden hacer imposible conceder a una aplicación personalizada la autoridad que se necesita para crear registros de aplicaciones de Microsoft Entra a petición y de la manera automatizada que requiere la solución.

En escenarios menos comunes en los que se ha concedido permisos adecuados a una aplicación personalizada, puede usar Microsoft Graph API para crear registros de aplicaciones de Microsoft Entra a petición. Sin embargo, la aplicación personalizada suele ser compleja de desarrollar e implementar porque de alguna manera debe realizar un seguimiento de las credenciales de autenticación para cada registro de aplicaciones de Microsoft Entra. También debe obtener acceso a esas credenciales siempre que necesite autenticar y adquirir tokens de acceso para entidades de servicio individuales.

Perfiles de entidad de servicio

Los perfiles de entidad de servicio se diseñaron para facilitar la administración del contenido organizativo en Power BI y el uso de las capacidades de forma más eficaz. Ayudan a abordar tres desafíos específicos que implican la mínima cantidad de esfuerzo y sobrecarga para los desarrolladores. Estos desafíos incluyen:

• Escalado a un gran número de áreas de trabajo.
• Optimización del rendimiento de las llamadas a la API REST.
• Aislamiento de modelos semánticos y credenciales de origen de datos en el nivel de inquilino del cliente.

Al diseñar una aplicación multiinquilino mediante perfiles de entidad de servicio, puede beneficiarse de las ventajas de las tres estrategias de diseño (descritas en la sección anterior) y a la vez evitar sus desventajas asociadas.

Los perfiles de entidad de servicio son cuentas locales que se crean en el contexto de Power BI. Una entidad de servicio puede usar la operación Profiles de la API REST para crear nuevos perfiles de entidad de servicio. Una entidad de servicio puede crear y administrar su propio conjunto de perfiles de entidad de servicio para una aplicación personalizada, como se muestra en el diagrama siguiente.

Siempre hay una relación de elementos principales y secundarios entre una entidad de servicio y los perfiles de entidad de servicio que crea. No se puede crear un perfil de entidad de servicio como una entidad independiente. Alternativamente, se crea un perfil de entidad de servicio mediante una entidad de servicio específica y esa entidad de servicio actúa como elemento principal del perfil. Además, un perfil de entidad de servicio nunca es visible para las cuentas de usuario u otras entidades de servicio. Solo la entidad de servicio que lo creó puede ver y usar un perfil de entidad de servicio.

Microsoft Entra no reconoce los perfiles de entidad de servicio

Aunque la propia entidad de servicio y su registro de aplicaciones subyacentes de Microsoft Entra se conocen como Microsoft Entra, Microsoft Entra ID no sabe nada sobre los perfiles de entidad de servicio. Esto se debe a que Power BI crea perfiles de entidad de servicio y solo existen en el subsistema del servicio Power BI que controla la seguridad y la autorización de Power BI.

El hecho de que los perfiles de entidad de servicio no se conocen con Microsoft Entra ID tiene ventajas y desventajas. La principal ventaja es que una aplicación del escenario de Insertar para el cliente no necesita permisos especiales de Microsoft Entra para crear perfiles de entidad de servicio. También significa que la aplicación puede crear y administrar un conjunto de identidades locales independientes de Microsoft Entra.

Sin embargo, también existen inconvenientes. Dado que Microsoft Entra no reconoce los perfiles de entidad de servicio, no se puede agregar un perfil de entidad de servicio a un grupo de Microsoft Entra para concederle implícitamente acceso a un área de trabajo. Además, los orígenes de datos externos, como una base de datos de Azure SQL o Azure Synapse Analytics, no pueden reconocer perfiles de entidad de servicio como identidad al conectarse a una base de datos. Por lo tanto, la estrategia de diseño de una entidad de servicio por área de trabajo (crear una entidad de servicio para cada inquilino del cliente) podría ser una mejor opción cuando hay un requisito para conectarse a estos orígenes de datos mediante una entidad de servicio independiente con credenciales de autenticación únicas para cada inquilino del cliente.

Los perfiles de entidad de servicio son entidades de seguridad de primer nivel

Aunque Microsoft Entra no reconoce los perfiles de entidad de servicio, Power BI los reconoce como entidades de seguridad de primera clase. Al igual que una cuenta de usuario o una entidad de servicio, puede agregar perfiles de entidad de servicio a un rol de área de trabajo (como administrador o miembro). También puede convertirlo en propietario de un modelo semántico y propietario de las credenciales del origen de datos. Por estos motivos, la creación de un nuevo perfil de entidad de servicio para cada nuevo inquilino de cliente es un procedimiento recomendado.

Ejecución de llamadas a la API REST como perfil de entidad de servicio

La aplicación puede ejecutar llamadas a la API REST mediante la identidad de un perfil de entidad de servicio. Esto significa que puede ejecutar una secuencia de llamadas a la API REST para aprovisionar y configurar un nuevo inquilino de cliente.

1. Cuando un perfil de entidad de servicio crea un área de trabajo, Power BI agrega automáticamente ese perfil como administrador del área de trabajo.
2. Cuando un perfil de entidad de servicio importa un archivo de Power BI Desktop para crear un modelo semántico, Power BI establece ese perfil como propietario del modelo semántico.
3. Cuando un perfil de entidad de servicio establece las credenciales del origen de datos, Power BI establece ese perfil como propietario de las credenciales del origen de datos.

Es importante comprender que una entidad de servicio tiene una identidad en Power BI que es independiente y distinta de las identidades de sus perfiles. Esto le aporta diversas posibilidades, como desarrollador. Puede ejecutar llamadas a la API REST mediante la identidad de un perfil de entidad de servicio. Como alternativa, puede ejecutar llamadas a la API REST sin un perfil, que usa la identidad de la entidad de servicio principal.

Se recomienda ejecutar llamadas a la API REST como entidad de servicio principal al crear, ver o eliminar perfiles de entidad de servicio. Debe usar el perfil de entidad de servicio para ejecutar todas las demás llamadas a la API REST. Estas otras llamadas pueden crear áreas de trabajo, importar archivos Power BI Desktop, actualizar parámetros de modelo semántico y establecer credenciales de origen de datos. También pueden recuperar metadatos de elementos del área de trabajo y generar tokens de inserción.

Considere un ejemplo en el que necesita configurar un inquilino de cliente para un cliente denominado Contoso. El primer paso realiza una llamada a la API REST para crear un perfil de entidad de servicio con su nombre para mostrar establecido en Contoso. Esta llamada se realiza mediante la identidad de la entidad de servicio. Todos los pasos de configuración restantes usan el perfil de entidad de servicio para completar las tareas siguientes:

1. Cree un área de trabajo.
2. Asociar el área de trabajo a una capacidad.
3. Importar un archivo de Power BI Desktop.
4. Establezca los parámetros del modelo semántico.
5. Establecer credenciales de origen de datos.
6. Configurar la actualización de datos programada.

Es importante comprender que el acceso al área de trabajo y su contenido deben realizarse mediante la identidad del perfil de entidad de servicio que se usó para crear el inquilino del cliente. También es importante comprender que la entidad de servicio principal no necesita acceso al área de trabajo ni a su contenido.

Uso de las operaciones de la API REST de Profiles (Perfiles)

El grupo de operaciones de la API REST de Profiles (Perfiles) consta de operaciones que crean y administran perfiles de entidad de servicio:

• Create Profile
• Delete Profile
• Get Profile
• Get Profiles
• Update Profile

Creación de un perfil de entidad de servicio

Use la operación de la API REST Create Profile (Crear perfil) para crear un perfil de entidad de servicio. Debe establecer la propiedad displayName en el cuerpo de la solicitud para proporcionar un nombre para mostrar para el nuevo inquilino. El valor debe ser único en todos los perfiles que pertenecen a la entidad de servicio. Se producirá un error en la llamada si ya existe otro perfil con ese nombre para mostrar para la entidad de servicio.

Una llamada correcta devuelve la propiedad id, que es un GUID que representa el perfil. Al desarrollar aplicaciones que usan perfiles de entidad de servicio, se recomienda almacenar los nombres para mostrar de perfil y sus valores de identificador en una base de datos personalizada. De este modo, es sencillo que la aplicación recupere los identificadores.

Si está programando con el SDK de .NET de Power BI, puede usar el método Profiles.CreateProfile, que devuelve un objeto ServicePrincipalProfile que representa el nuevo perfil. Hace que sea sencillo determinar el valor de la propiedad id.

Este es un ejemplo de cómo crear un perfil de entidad de servicio y concederle acceso al área de trabajo.

// Create a service principal profile
string profileName = "Contoso";

var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);

// Retrieve the ID of the new profile
Guid profileId = profile.Id;

// Grant workspace access
var groupUser = new GroupUser {
    GroupUserAccessRight = "Admin",
    PrincipalType = "App",
    Identifier = ServicePrincipalId,
    Profile = new ServicePrincipalProfile {
        Id = profileId
    }
};

pbiClient.Groups.AddGroupUser(workspaceId, groupUser);

En el servicio Power BI, en el panel Acceso del área de trabajo, puede determinar qué identidades, incluidas las entidades de seguridad, tienen acceso.

Eliminación de un perfil de entidad de servicio

Use la operación de la API REST Delete Profile (Eliminar perfil) para eliminar un perfil de entidad de servicio. Solo la entidad de servicio principal puede llamar a esta operación.

Si está programando con el SDK de .NET de Power BI, puede usar el método Profiles.DeleteProfile.

Recuperación de todos los perfiles de entidad de servicio

Use la operación de la API REST Get Profiles (Obtener perfiles) para recuperar una lista de perfiles de entidad de servicio que pertenecen a la entidad de servicio que realiza la llamada. Esta operación devuelve una carga útil JSON que contiene las propiedades id y displayName de cada perfil de entidad de servicio.

Si está programando con el SDK de .NET de Power BI, puede usar el método Profiles.GetProfiles.

Ejecución de llamadas a la API REST mediante un perfil de entidad de servicio

Hay dos requisitos para realizar llamadas a la API REST mediante un perfil de entidad de servicio:

• Debe pasar el token de acceso para la entidad de servicio principal en el encabezado Authorization (Autorización).
• Debe incluir un encabezado denominado X-PowerBI-profile-id con el valor del identificador del perfil de entidad de servicio.

Si usa el SDK de .NET de Power BI, puede establecer explícitamente el valor del encabezado X-PowerBI-profile-id pasando el identificador del perfil de entidad de servicio.

// Create the Power BI client
var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBIClient(uriPowerBiServiceApiRoot, tokenCredentials);

// Add X-PowerBI-profile-id header for service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
pbiClient.HttpClient.DefaultRequestHeaders.Add("X-PowerBI-profile-id", profileId);

// Retrieve workspaces by using the identity of service principal profile
var workspaces = pbiClient.Groups.GetGroups();

Como se muestra en el ejemplo anterior, una vez que agregue el encabezado X-PowerBI-profile-id al objeto PowerBIClient, es sencillo invocar métodos, como Groups.GetGroups, para que se ejecuten mediante el perfil de entidad de servicio.

Hay una manera más cómoda de establecer el encabezado X-PowerBI-profile-id para un objeto PowerBIClient. Para inicializar el objeto, pase el identificador del perfil al constructor.

// Create the Power BI client
string profileId = "11111111-1111-1111-1111-111111111111";

var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBiClient(uriPowerBiServiceApiRoot, tokenCredentials, profileId);

A medida que programa una aplicación multiinquilino, es probable que tenga que cambiar entre la ejecución de llamadas como la entidad de servicio principal y la ejecución de llamadas como un perfil de entidad de servicio. Un enfoque útil para administrar el cambio de contexto es declarar una variable de nivel de clase que almacena el objeto PowerBIClient. Posteriormente, puede crear un método auxiliar que establezca la variable con el objeto correcto.

// Class-level variable that stores the PowerBIClient object
private PowerBIClient pbiClient;

// Helper method that sets the correct PowerBIClient object
private void SetCallingContext(string profileId = "") {

    if (profileId.Equals("")) {
        pbiClient = GetPowerBIClient();    
    }
    else {
        pbiClient = GetPowerBIClientForProfile(new Guid(profileId));
    }
}

Cuando necesite crear o administrar un perfil de entidad de servicio, puede llamar al método SetCallingContext sin parámetros. De este modo, puede crear y administrar perfiles mediante la identidad de la entidad de servicio.

// Always create and manage profiles as the service principal
SetCallingContext();

// Create a service principal profile
string profileName = "Contoso";

var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);

Cuando necesite crear y configurar un área de trabajo para un nuevo inquilino de cliente, querrá ejecutar ese código como perfil de entidad de servicio. Por lo tanto, debe llamar al método SetCallingContext pasando el identificador del perfil. De este modo, puede crear el área de trabajo mediante la identidad del perfil de entidad de servicio.

// Always create and set up workspaces as a service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
SetCallingContext(profileId);

// Create a workspace
GroupCreationRequest request = new GroupCreationRequest(workspaceName);
Group workspace = pbiClient.Groups.CreateGroup(request);

Después de usar un perfil de entidad de servicio específico para crear y configurar un área de trabajo, debe seguir usando ese mismo perfil para crear y configurar el contenido del área de trabajo. No es necesario invocar el método SetCallingContext para completar la instalación.

Ejemplo de desarrollador

Le recomendamos que descargue una aplicación de ejemplo denominada AppOwnsDataMultiTenant.

Esta aplicación de ejemplo se desarrolló mediante .NET 6 y ASP.NET, y muestra cómo aplicar las instrucciones y recomendaciones descritas en este artículo. Puede revisar el código para aprender a desarrollar una aplicación multiinquilino que implemente el escenario de Insertar para el cliente mediante perfiles de entidad de servicio.

Contenido relacionado

Para más información sobre este artículo, consulte los recursos siguientes:

• Perfiles de entidad de servicio para aplicaciones de varios inquilinos en Power BI Embedded
• Migración de aplicaciones de varios clientes al modelo de perfiles de entidad de servicio
• Grupo de operaciones de la API REST de Power BI de Profiles (Perfiles)
• • Aplicación de ejemplo AppOwnsDataMultiTenant
• ¿Tiene alguna pregunta? Pruebe a preguntar a la comunidad de Power BI
• ¿Sugerencias? Ideas para contribuir a mejorar Power BI