Privacidad de Datos y la Formula Firewall en Power BI / Power Query

  • Facebook
  • Twitter
  • LinkedIn

¿Alguna vez te ha salido un error similar a estos?

Formula.Firewall: Consulta ‘Merge1’ (paso ‘Origen’) está accediendo a fuentes de datos que tienen niveles de privacidad que no pueden usarse juntos. Por favor reconstruye esta combinación de datos.

Formula.Firewall: Consulta ‘Query1’ (paso ‘Añadir personalizado’) hace referencia a otras consultas o pasos, entonces puede ser que acceda directamente a una fuente de datos. Por favor reconstruye esta combinación de datos.

Este es un artículo de blog en el que discutiré este tema específico para responder 3 preguntas:

  • POR QUÉ existe
  • Qué causa este error
  • Cómo descubrir fácilmente la causa de este error

Antes de comenzar… Definamos un concepto / función:

¿Qué es Privacidad de Datos (Data Privacy) en Power Query / Power BI?

Cada vez que te conectas a una fuente de datos, necesitas definir 2 cosas para esa conexión:

  • Método de Autenticación – puede ser implícito (cuando te conectas a un archivo en tu computadora) o explícito (una nueva ventana de autenticación aparecerá con las opciones disponibles)

  • Nivel de Privacidad –esto es normalmente una ventana opcional, pero puedes seleccionar desde Ninguno (predefinido), Público, Organizacional o Privado. Puedes ver esto si vas a ‘Configuración de fuente de datos’ –> ‘Editar permisos’

La parte en la que nos queremos enfocar ahora es en los Niveles de Privacidad y aquí hay una tabla sencilla que describe las opciones disponibles:

Configuración Description
Privado Una fuente de datos privada está aislada completamente de las demás fuentes de datos. Contiene información sensible o confidencial
Organizacional Una fuente de datos organizacional está aislada de todas las fuentes de datos públicas, pero es visible para otras fuentes de datos organizacionales
Público Una fuente de datos da visibilidad de los datos contenidos en la fuente a cualquiera.

Aquí hay un breve resumen que Ehren del equipo de Power Query me envió para entender mejor esto:

  • Datos Públicos pueden ser envíados a fuentes marcadas como Público/Organizacional/Privado.
  • Datos Organizacionales pueden ser envíados a fuentes marcadas como Organizacional/Privado (pero no a fuetnes Públicas).
  • Datos Privados no pueden ser envíados a ninguna otra fuente (tampoco a otras fuentes Privadas).

¿Por qué existe este error Formula.Firewall?

Los Niveles de Privacidad actúan como un cortafuegos o “puerta”. Es un mecanismo de protección para la Privacidad de tus Datos.

El Cortafuegos existe para prevenir el envío accidental de datos desde una fuente a otra.

En un mundo ideal, marcarías todas tus fuentes de datos de forma correcta para que este sistema pueda evitar que envíes información importante y sensible a otra fuente que quizás no debería tener acceso a ella.

La filtración de datos es una cosa bastante seria y queremos evitarla. Esta es la razón por la que tenemos este sistema “defensivo” dentro del cual se encuentra la Privacidad de Datos o el sistema de Cortafuegos de Fórmula.

¿¿¿¿¿Cómo es que mis datos terminan en una fuente totalmente distinta a la de origen???? Eso, amigos míos, sucede debido a algo llamado Query Folding.

En resumen, Query Folding es el proceso en el que el código M se traduce al lenguaje nativo de consulta de una fuente de datos.

A veces incluso puedes verificar si está sucediendo un Query Folding al hacer clic derecho en uno de los pasos de tu consulta y seleccionar la opción “Ver consulta nativa”:

Todo esto se hace por motivos de desempeño y para cargar la mayor cantidad posible de trabajo a la fuente de datos en lugar de cargar TODOS los datos a tu PC y trabajar localmente porque sí.

Por favor ten en cuenta que incluso con el botón Ver consulta nativa en gris, el Query Folding puede que aún esté sucediendo en el fondo. Por ejemplo, si te conectas a una fuente OData, no podrás ver el “Ver consulta nativa” pero la mayoría de las acciones estarán siendo “folded” o acopladas / dobladas.

Query folding y la evaluación perezosa (lazy evaluation) serán un tema que cubriré en otro artículo más adelante. Por el momento, la explicación de Ehren sobre el impacto del Query Folding en el Cortafuegos de Fórmula es perfecta:

Como parte del proceso de folding, PQ a veces puede determinar que la forma más eficiente de ejecutar un enredo de comandos es tomar los datos de una fuente y pasarlos a otra. Por ejemplo, si unes un archivo pequeño en formato CSV junto a una tabla gigante en formato SQL, probablemente no querrás que PQ lea el archivo CSV, lea toda la tabla SQL y finalmente los una en tu computadora. Probablemente prefieras que PQ convierta los datos CSV a una declaración SQL y luego pida a la base de datos SQL que haga la unión.

Esto es el principal culpable de todo y la razón principal por la cual no existe una aproximación de tipo “un modelo único para todos”.

Esto es porque el folding de la consulta puede comportarse de manera diferente dependiendo de los pasos en tu consulta y no querrás deshacerte de la optimización de datos porque te conviene que las consultas le saquen el máximo provecho donde pueda ser aplicada.

Ehren del equipo de Data Integrations (los muchachos detrás de Power Query y la Get Data Experience moderna) iniciaron una discusión que profundiza en lo que sucede dentro del proceso del Cortafuegos. Si eres un usuario avanzado y te interesa aprender lo que sucede tras bambalinas del cortafuegos de fórmulas, entonces esta es una discusión y un artículo que te resultará muy interesante. Échale un vistazo aquí.

La entrada del blog que estás leyendo en este momento es más bien un resumen para que puedas entender mejor cómo es el Cortafuegos de Fórmulas y qué son los Niveles de Privacidad de Datos.

¿Cuál es el beneficio de los Niveles de Privacidad de Datos?

Antes de lanzarnos de lleno a los errores, esta función (el Cortafuegos de Fórmulas) no se lleva los laureles porque no es tan visible como las otras funciones.

¿Por qué querría yo cambiar mi forma de trabajar y fijar los niveles de privacidad para cada una de mis fuentes?

Déjame darte un ejemplo de los beneficios del Cortafuegos de Fórmulas (sin ningún error):

  • Tenemos 1 archivo CSV que está guardado en SharePoint Online – este archivo contiene un valor que queremos usar como Parámetro. Está en el encabezado de una de las hojas y básicamente nos indica a qué Territorio pertenece el archivo y qué datos necesitamos sacar de la base de datos. Así es como se ve la consulta:

  • Tenemos una base de datos SQL Server con MILLONES de registros – no queremos cargar esos millones de registros, más bien estamos interesados en obtener datos usando el parámetro del archivo CSV. Así es como se vería la consulta:

AQUÍ es donde el Query Folding es extremadamente importante. NO quieres cargar todos los datos, únicamente filtrarlos.

Solamente quieres obtener los datos ya filtrados de la base de datos y por eso es que existe el Query Folding.

Hemos llegado hasta aquí. Tenemos 2 consultas, pero aún no hay interacción entre ellas:

Lo siguiente que debemos hacer es filtrar la columna de Territorio en la consulta “SalesOrderHeader”, la cual viene de la base de datos:

usamos una palabra marcadora como “Panamá” y luego modificamos el código para usar el nombre de la consulta que tiene el argumento que queremos usar.

El resultado debería verse así:

Nuestro diagrama final se verá así:

Ahora hagamos unas pruebas para ver lo está sucediendo.

Lo primero que haremos es configurar los Niveles de Privacidad de Datos de cada fuente de datos.

Para hacerlo, asegúrate que estás en la ventana del editor de Power Query y:

  1. Ve al menú Inicio
  2. Haz clic en Data Source Settings
  3. Cuando aparezca la ventana Configuración origen de datos, selecciona la fuente de datos que quieres editar
  4. Clic en Editar permisos
  5. En la ventana Editar permisos, selecciona el nivel de privacidad.

En este ejemplo, estoy configurando ambas fuentes para que tengan un Nivel de Privacidad Organizacional.

Cuando regreso a la consulta de ventas SalesOrderHeader, puedo hacer clic en el último paso y ver que la opción “Ver consulta nativa” esté habilitada. Al hacer clic veo esto:

¡Échale un vistazo al texto resaltado en amarillo! Esto es esencialmente la prueba que Power Query presenta para saber que no estamos descargando los millones y millones de registros de la base de datos, estamos únicamente obteniendo los datos de Francia ya que es el valor en la consulta “SalesTerritory” que viene del archivo CSV. Así es como funciona el Query Folding con múltiples fuentes de datos.

¿Y qué sucede cuando configuramos la base de datos con un nivel de privacidad?

Bueno, sucede que la opción “Ver consulta nativa” estará en gris y tras bambalinas el Query Folding está siendo ejecutado basándose únicamente en las transformaciones que estás haciendo con los pasos previos al que involucra el valor del CSV / Consulta SharePoint.

El Query Folding funciona únicamente para lo que sucede dentro de la Fuente de Datos específica (base de datos SQL Server). Cuando llega el momento de unir los datos con otras fuentes, el Query Folding se detendrá.

En esencia estás trabajando con una copia local de tu base de datos y por lo tanto únicamente estarás filtrando los datos utilizando el valor en el CSV de SharePoint.

A la vez, este es un gran beneficio si quieres prevenir que información sensible sea enviada a esta base de datos en lugar de un único parámetro.

¿Qué activa el error Formula.Firewall?

En la mayoría de casos, es el hecho que una consulta tiene 2 o más fuentes de datos que intentan trabajar juntas, pero una o varias de ellas tienen un nivel de privacidad incompatible O niveles de privacidad no definidos.

En un sentido más técnico, el Query Folding es el culpable de todo ya que trata de combinar varias fuentes de datos para tener un mejor desempeño, pero para que esto suceda y sea resuelto debemos conocer la causa del problema. Es decir, eso que activa el error Formula.Firewall.

El error en ‘La consulta está accediendo a fuentes de datos que tienen niveles de privacidad que no pueden usarse juntos’

Formula.Firewall: Consulta ‘Merge1’ (paso ‘Origen’) está accediendo a fuentes de datos que tienen niveles de privacidad que no pueden usarse juntos.  Por favor reconstruye la combinación de datos.

El mensaje de error hace referencia directa a la tabla que mostré previamente en esta entrada del blog.

In short, what’s happening is that within the same query, you’re trying to access multiple data sources and they’ve been set up with incompatible privacy levels, meaning that you need to head over to the Data Source Settings window and set up your ALL your data sources in that query to the same privacy level; either ALL Public or ALL Organizational.

En palabras sencillas, lo que sucede es que dentro de la misma consulta, estás tratando de acceder a varias fuentes de datos y están configuradas de forma que sus niveles de privacidad incompatibles, lo que significa que debes ir a la ventana Configuración de fuentes de datos y configurar TODAS tus fuentes de datos de la consulta al mismo nivel de privacidad; ya sea TODAS públicas o TODAS organizacionales.

Al terminar con esto verás que el problema habrá desaparecido.

Error ‘La Consulta hace referencia a otras consultas o pasos, puede que no acceda directamente a la fuente de datos’

Este es probablemente el error más común, especialmente para los que usan una Tabla dentro de un libro en Power Query para Excel.

La leyenda en persona, (mi amigo) Ken Puls ya ha escrito sobre esto aquí.

En su artículo de blog, Ken explica cómo segmentar tus consultas en etapas:

  1. Importa tus Datos y realiza la mayoría de pasos que puedan resultar en el folding de la consulta de esas consultas base (Staging Query 1,2 y 3 en el diagrama)
  2. Haz referencia a tus consultas base y haz las transformaciones finales / moldeado y cárgalo todo a Excel o a tu Modelo de Datos

Ese método parece funcionar bastante bien pero, ¿por qué aparece ese error?

Algunas personas aún se encuentran con ese error incluso después de haber leído el artículo del blog y como cualquier persona, quisieran saber por qué sigue apareciendo.

La Respuesta: tu consulta es lo que me gusta denominar Consulta “encadenada”.

¿Qué es una Consulta “encadenada”? Es un término que yo inventé, pero es mi forma de nombrar a una consulta que tiene referencias “fuera del marco” de la consulta actual.

Al decir “fuera del marco” me refiero a que tienes múltiples fuentes de datos en una consulta y que una de esas fuentes no ha sido definida / determinada / evaluada correctamente.

¿Cuándo sucede esto? El escenario más común donde he visto que esto sucede es con consultas que tratan de conectar a un servicio web o una REST API y donde necesitas evaluar un paso (o consulta) y luego usar el resultado para una siguiente, y luego sigue sucediendo lo mismo hasta que terminas en un ciclo / iteración / paginación. Si te sale este error, por favor cuéntame más acerca sobre tu escenario en la sección de comentarios

¿Qué opciones tengo para arreglarlo? Tienes 3 opciones:

  1. Ignorar los Niveles de Privacidad – Probablemente ya has leído esta opción antes, pero puedes activar la casilla para ignorar los niveles de privacidad. Esto funcionará de forma local, pero no en el servicio web Power BI.
  2. Crear un Conector Personalizado Power BI –Esta es por mucho la MEJOR opción, ya que puedes asegurarte que tus consultas funcionan de forma óptima y trabajan sin contratiempos en el servicio web también. Eso sin mencionar que también tienes algunas funciones que son únicas en los conectores personalizados como leer los encabezados de respuesta de tus llamadas y configurar el flujo de tu OAuth 2.0. Tristemente, esto está únicamente disponible en Power BI, pero si vas a trabajar únicamente dentro de Excel entonces la primera opción será suficiente.
  3. Incrustar o enmascarar fuentes de datos dentro de funciones personalizadas – este método hará que tus fuentes de datos no sean visibles en los Niveles de privacidad de datos al principio, pero puedes ajustar sus consultas para definir la fuente de datos al principio y luego aplicar una función.

En lo que respecta a esa última opción (o método # 3)

Hace mucho tiempo (2015-2016), hubieras tenido que hacer una movida tipo MacGyver para “agregar una nueva fuente de datos” dentro de Power Query.

Por ejemplo, si tu SaaS tenía un REST API, pero no tenía el conector en Power BI, podías usar la función Web.Contents para obtener los datos usando solicitudes de tipo GET.

Claro que necesitarías saber código M y leer toda la documentación de la API para lograr que sucediera, pero las cosas se complicarían en un santiamén dependiendo de cosas como el método de Autenticación, paginación y aceleración.

Después de TODO tu arduo trabajo al crear esas consultas para obtener tus datos, publicarías tu reporte al Servicio Power BI solo para toparte con que tus consultas no pueden ser actualizadas en el servicio:

Esto me sucedió varias veces y a pesar que hay algunas formas de resolverlo, únicamente me hicieron sentir como si estuviera en medio de un campo minado… y soy terrible jugando Buscaminas.

Hay algunas cuestiones muy técnicas detrás del por qué deberías usar un Conector Personalizado en vez de escribir las consultas directamente con Web.Contents y están principalmente relacionadas con los Niveles de Privacidad y el cortafuegos de Fórmulas.

Si alguna vez consideras conectarte a una fuente que no esté en la lista de la ventana “Get Data”, te recomiendo que crees un Conector Personalizado para ello y si necesitas ayuda para crear uno para tu compañía, no dudes en contactarme.