Migración de aplicaciones de varios clientes al modelo de perfiles de entidad de servicio

En este artículo se describe cómo puede obtener una mejor escalabilidad mediante la migración de las aplicaciones de varios clientes de análisis integrados de Power BI al modelo de perfiles de entidad de servicio.

Los perfiles de entidad de servicio facilitan la administración del contenido organizativo en Power BI y usan sus capacidades de forma más eficaz.

Nota

Este artículo está dirigido a organizaciones que ya tienen una aplicación que admite varios clientes desde un único inquilino de Power BI.

No todas las aplicaciones se benefician del modelo de entidad de servicio. Por ejemplo, las siguientes aplicaciones no deben migrar:

  • Aplicaciones pequeñas que mantienen una entidad de servicio con un pequeño número de objetos.
  • Aplicaciones que usan una entidad de servicio múltiple por cliente

Prerrequisitos

Es importante leer sobre los perfiles de entidad de servicio antes de iniciar la migración.

También debe seguir estos pasos:

Screenshot of Admin portal switch.

Migración a perfiles de entidad de servicio

La migración a perfiles de entidad de servicio implica los pasos siguientes:

  1. Cree perfiles, un perfil por cliente.
  2. Organice las áreas trabajo.
  3. Cambie el código de la aplicación para usar perfiles.
  4. Pruebe la aplicación con el modelo de perfiles.
  5. Limpie los permisos redundantes.

Crear perfiles (obligatorios)

Use la API REST de perfiles con la entidad de servicio que creó para crear un perfil para cada cliente.

Es recomendable guardar una asignación de cada identificador de cliente de datos con su identificador de perfil correspondiente en la base de datos. Necesitará esta asignación más adelante para realizar llamadas API con el perfil de inquilino.

Organizar las áreas de trabajo

La manera más fácil de administrar los datos es mantener un área de trabajo por cliente. Si la aplicación ya usa este modelo, no es necesario crear nuevas áreas de trabajo. Sin embargo, todavía tiene que proporcionar a cada perfil de Administrador acceso al área de trabajo correspondiente mediante la API Agregar usuario de grupo.

Si no tiene un área de trabajo por cliente, use el perfil correspondiente para llamar a API Crear usuario de grupo para crear un área de trabajo para cada cliente.

Organizar elementos en las áreas de trabajo

Ahora debería tener un perfil y un área de trabajo para cada cliente. Si ha creado nuevas áreas de trabajo en el paso anterior, debe importar elementos (como informes y modelos semánticos) en estas áreas de trabajo. Los modelos semánticos que importe dependen de la solución actual:

  • Si la aplicación usa un modelo semántico independiente para cada cliente, el diseño del modelo semántico puede funcionar tal cual.

  • Si la aplicación usa un modelo semántico con seguridad de nivel de fila (RLS) para proporcionar datos diferentes a distintos clientes, puede obtener una mejor escalabilidad mediante la creación de un modelo semántico independiente para cada cliente y el uso de perfiles como se describe en este artículo.

  • Después de superar las limitaciones de escalabilidad mediante perfiles y orígenes de datos independientes, puede obtener aún más separación de datos mediante RLS con perfiles.

    • Si se basa en RLS dinámico, se devolverá el nombre del perfil en la función DAX UserName().
    • Si usa roles estáticos de RLS e invalida al generar el token de inserción, puede continuar haciendo esto.

Una vez que los elementos estén listos, impórtelos en las áreas de trabajo pertinentes. Para automatizar el proceso, considere la posibilidad de usar la API de importación.

Cambiar el código de la aplicación para usar perfiles

Una vez que tenga perfiles con acceso de Administrador a las áreas de trabajo pertinentes y una base de datos con asignación que muestre qué perfil representa el cliente, puede realizar los cambios de código necesarios. Se recomienda mantener dos flujos de código en paralelo y exponer gradualmente el flujo de código de perfiles a los clientes.

Realice los siguientes cambios en el código:

  • Cambio de código de autorización

    • Si utiliza un usuario maestro en la aplicación de Microsoft Entra ID, cambie el código de adquisición del token. Lea Inserción con la entidad de servicio para obtener información sobre cómo crear un token de Microsoft Entra de solo aplicación.
    • Si usa una entidad de servicio y ha creado una nueva para los perfiles, ajuste el código para usar el identificador y los secretos de la entidad de servicio correctos.
  • Cambio de código de administración

    Algunas aplicaciones tienen código de administración que automatiza la incorporación de un nuevo cliente tras el registro. A menudo, el código de administración usa las API REST de Power BI para crear áreas de trabajo e importar contenido. La mayoría de este código debe permanecer igual, pero es posible que tenga que adaptar los detalles siguientes:

    • Cada vez que cree un nuevo inquilino de cliente, cree un nuevo perfil de servicio para que sea el creador y el administrador del área de trabajo para ese inquilino.
    • Si decide reorganizar el contenido de Power BI, edite el código para reflejar los cambios.
  • Cambio de código de token de inserción

    Reemplace el autor de la llamada API. Asegúrese de que un perfil llama a la API GenerateToken porque en el modelo de perfiles, solo el perfil específico tiene acceso al contenido del cliente.

Validación

Es recomendable probar exhaustivamente la aplicación antes de moverla al modelo de perfiles. Los informes pueden cargarse incluso si hay errores en el código de la aplicación SaaS porque no eliminó los permisos anteriores en las áreas de trabajo.

Limpiar después de la migración

Ahora que finalizó la migración y validó los resultados, quite lo que ya no necesita.

  • Limpiar código: es posible que quiera deshabilitar las rutas de acceso de código antiguas para asegurarse de que solo está ejecutando código nuevo que se base en perfiles.
  • Limpieza de áreas de trabajo y permisos en Power BI: si ha creado nuevas áreas de trabajo, puede eliminar las áreas de trabajo antiguas que ya no están en uso. Si ha reutilizado las mismas áreas de trabajo, es posible que desee eliminar los permisos anteriores (como los permisos de usuario maestro) en el área de trabajo.

¿Tiene más preguntas? Pruebe a preguntar a la comunidad de Power BI