Por mucho tiempo se pensó en los orígenes de datos nube como la mejor solución para utilizar PowerBi por su inmediatez ante una actualización programada sin dependencia externas como sucedía en caso de un origen on premise que requiere una puerta de enlace.
Sin embargo, por buen tiempo estuve frente a empresas que elegían utilizar un gateway aunque el origen sea nube por el simple hecho que las puertas de enlace permiten agregar orígenes puntales a datos y compartirlos. Esto para que la canalización de los modelos semánticos tuviera un único acceso a datos.
Esto ya no es más necesario. En este artículo veremos como crear y compartir un origen de datos cloud para mantener esa filosofía de gateway pero sin la necesidad de usarlo.
El lanzamiento de Fabric trajo muchos lanzamientos espectaculares en el ecosistema de datos de Microsoft. Algunos fueron muy desarrollados por las redes y otros fueron quedando más resguardados. Uno de ellos es el que permite mantener conexiones a datos nube.
Como una empresa que busca estandarizar procesos de acceso a datos a desarrolladores o usuarios finales en una estrategia de self-service. Se vuelve indispensable tomar decisiones sobre los detalles de seguridad o normas de control. Una de esas reglas deseadas es que la herramienta de Bi llegue a un origen de datos cloud mediante credenciales y accesos estandarizados por el área de tecnología a las tablas que sean visibles. La idea es que las actualizaciones de modelos de datos viaje en un solo canal controlado que pueda analizarse posteriormente en los orígenes evitando infinidad de consultas y accesos de muchos usuarios a muchas tablas diferentes. Hace mucho tiempo no era posible y solo podíamos agregar una conexión usando una puerta de enlace para reutilizar la conexión. Si no usábamos una puerta y configurábamos las credenciales cloud felices de no usar un gateway, estabamos generando por cada modelo conexiones dependientes de desarrolladores y accesos varios de personas.
¿Por qué haríamos una conexión cloud en Fabric?
Como buena práctica, tener los orígenes cloud estandarizados de accesos y credenciales podemos mantener un margen de seguridad en el acceso a tablas y conexiones abiertas bajo un solo canal. Esto favorece la performance del origen que no debe abrir canales de acceso por la actualización de cada persona que configuro sus credenciales por modelos varios. Además, permite a desarrolladores configurar orígenes de datos sin necesidad de conocer las credenciales productivas. Basta con mapear la conexión que un Administrador delimitó.
NOTA: de manera restrictiva, los orígenes direct lake de lakehouse y warehouse fuerzan esta configuración para poder utilizarlo.
Suficiente texto, veamos como se hace.
¿Cómo agregamos una conexión?
Si vamos al menú de configuración de Fabric veremos que no solo es Configuración de puertas de enlace, sino también de conexiones.
Allí encontrarán la lista de todas las conexiones generadas por todos los usuarios cuando utilizan una conexión nube. Ahí verán que puede haber muy mucho creado por usuarios y que sería mejor controlarlo.
Para agregar una nueva conexión de origen cloud, podemos proceder de dos modos.
Por un lado, darle alta dentro de dicho menú estilo alta tradicional como indica la imagen:
Por otro lado, cuando publicamos un modelo semántico que tiene un origen nube por primera vez, en su configuración de actualizaciones programadas, podremos apreciar que el apartado de gateway ahora también es para conexiones nubes.
Con la opción de gateway apagada, podemos abrir el menú de maps to y poner a crear nueva:
Eso abrirá el menú inicial que mostramos en las pantallas de administración pero precargará algunos valores siendo mas simple su configuración. Si miramos bien la imagen vemos lo que sucede una vez que ya esta configurada. Aparecería "AdventureWorksDW2020" como una conexión que podemos mapear. De esa forma, linkeamos el modelo semántico a la conexión por el canal deseado.
Recordemos que, si usamos direct lake, esto será mandatorio para que el modelo este constantemente actualizado.
Compartir
Una vez definido el origen pasamos a compartirlo para que los desarrolladores puedan utilizar el canal. En el menú donde vemos las conexiones hay tres puntos en cada una. Seleccionamos "Manage users". Abrirá un menú a la derecha donde podemos buscar usuarios
Fíjense que al agregar un usuario tenemos tres permisos para darles. Lo más convencional sería que solo sean "User" para tener la posibilidad de configurar sus modelos semánticos. Quienes tengan el 2do nivel de acceso pueden compartirlo. Permitir compartir es una gran responsabilidad porque damos pie a un acceso que probablemente sea productivo de una persona hacia otras y no de quienes nosotros conocemos. Finalmente, ownership para mantener y administrar en equipo.
Una vez configurado esto, el usuario agregado podrá configurar su modelo semántico mapeando al origen ya sea para un modelo importado o el direct lake activo hacia lakehouse/warehouse.