Errores a nivel de paso en Power BI / Power Query

Anteriormente en uno de mis blog. (here) Cubrí los tipos de errores que probablemente encuentres al usar Power BI / Power Query.

En esta serie de lógica condicional, he cubierto la palabra clave try en Power Query y cómo usar básicamente un IFERROR en su propio código, pero esto se hizo principalmente para manejar errores en el nivel de «row».

¿Qué pasaría si quisiéramos manejar los errores a nivel de paso? Ahí es donde nos centraremos en este blog.

les recomiendo que lean esto (url) y el blog anterior en esta serie antes de seguir leyendo.

¿Por qué tenemos errores de nivel de paso?

Cuando creamos una consulta con Power BI / Power Query, comúnmente usamos nuestro propio entorno, credenciales y sistema local. Esto significa que nuestra consulta ha sido probada específicamente para nosotros, pero esto no significa necesariamente que funcione para todos.

Mira, cada «Step» que se ve en la sección «Applied Steps», es básicamente una variable que depende del paso anterior. Esto significa que para alcanzar el «Last Steps», primero debe rastrear todas sus dependencias y calcularlas para alcanzar el «Step» deseado.

Ahora, ¿qué sucede si en alguno de esos pasos dependientes descubre que hay un error? Por ejemplo, el paso intenta hacer una transformación en una columna «Name», pero ese nombre de columna simplemente no existe en nuestra consulta.

Esto arrojará un error de nivel de paso y simplemente (detendrá por completo) el proceso. Nada más allá de ese punto será evaluado y el proceso simplemente se detendrá: el único resultado de la consulta será un mensaje de error que especifica por qué ocurrió el error.

¿Podemos tener nuestros propios mensajes de error?

Esto es algo que pensé que solo tenía sentido para los Conectores personalizados, ya que incluso puede especificar algunos custom handling basado en el encabezado de respuesta que obtienes de tu API REST, pero recientemente tuve una conversación con Reid Havens (website) y en realidad lo está probando con sus propias plantillas de Power BI, que es algo bastante bueno.

En resumen, sí, podemos tener nuestros propios mensajes de error.

Pero … ¿Cómo creamos nuestros propios mensajes de error?

Bueno, para eso podemos usar una función llamada Error.Record
que creará un registro con el campo necesario que necesita el error. Aquí hay un ejemplo de eso:

¿Cómo lo usamos? Bueno, la forma de usarlo es bastante simple. Todo lo que necesitas hacer es simplemente poner el error de la palabra clave antes y voilá:

La realidad es que realmente no necesitamos la función Error.Record. Simplemente nos ayuda con la creación del registro, pero puedes crearlo manualmente de esta manera:

¿Dónde uso ese error? ¿Qué gano con eso?

Si bien recomendaría usar solo los mensajes de error nativos que vienen con Power Query, hay algunas situaciones en las que sería una buena idea elaborar su propio mensaje de error. Una vez más, tiene MUCHO sentido cuando se trata de un conector personalizado de Power BI, ya que puede decir que cuando recibe un código de error 424 podría traducirse en algo significativo y comprensible para un ser humano.

Esto es algo que solo deben usar los usuarios avanzados en escenarios específicos.

Puede leer la documentación sobre cómo usar su propio mensaje de error en here y lo usaré como referencia.

El ejemplo: combinación de archivos de la vieja escuela

En el pasado (2014-2015), Power Query solía combinar «binarios». Han cambiado esa redacción para que sean «archivos» ya que el mecanismo y el conjunto de operaciones son diferentes.

En aquel entonces usaban un código similar a este:

Traducido al español, esto es lo que solía hacer:

1. Conectar a tu fuente
2. Eliminar todas las columnas excepto la que contienen los binarios.
3. Navegar a esa columna de binarios y transformarla en una lista
4. Usar Binary.Combine para que puedas combinar todos sus binarios en un solo binario grande.
5. Leer el binario recién combinado usando la función Csv.Document

El problema principal con ese enfoque es que solo funciona con archivos planos. En realidad, no con archivos más complejos como xml, Excel, json y otros. Esto significaba que si intentabas usar este enfoque, encontrabas un error, pero muchas personas no lo entendían.

¿Qué pasaría si creáramos una función que hiciera esa combinación binaria pero con un error más descriptivo?

Se verá así:

Algunas advertencias

Una vez que definas tu propio error personalizado, podrás de esta manera, reemplazar cualquier otro error que pueda detener la operación. Esto significa que si se produce algún error, este nuevo error será el que te arrojará, pero puedes gestionarlo por pasos, lo que llevaría mucho tiempo crearlo, pero tienes la capacidad de crearlo.

No olvides que a Power Query le encanta que algunos de sus valores sean evaluados perezosamente. Esto significa que podrían afectar la operación de prueba ya que esos valores deben evaluarse completamente para generar un error o no. Puedes aplicar esta evaluación utilizando cualquiera de las funciones de Buffer (Table.Buffer, List.Buffer, Binary.Buffer) dependiendo del tipo de valor que estés manejando.

Nuevamente, no puedo enfatizar esto lo suficiente, solo usarías esta técnica si es estrictamente necesario y te animo a que lo pienses dos veces antes de implementarla. A menos que sea específicamente para un conector personalizado de Power BI, en ese caso generalmente tiene un razonamiento REALMENTE bueno.