Gestión de errores en Power Automate

En todos los proyectos de software en general, existe la mala costumbre de centrarse en resolver el escenario idílico, un escenario en que todos los componentes de la aplicación funcionan perfectamente y en el que las acciones suceden según lo esperado. Como muchos ya sabréis, estos escenarios no se dan siempre, ya sea por un uso inadecuado por parte del usuario, mal diseño por parte del programador, o por errores que podíamos haber evitado haciendo algún tipo de validación o control. Por si no fuera suficiente, también existen errores que no podemos controlar, como, por ejemplo, el mal funcionamiento de la API de un tercero, una caída de la base de datos, o incluso, la propia desconexión de Internet cuando estamos utilizando software en la nube.

Power Automate no es una excepción, y dado que podemos utilizar distintos conectores o servicios en un mismo flujo, es especialmente importante dotar a este de una buena gestión de errores.

En este artículo, veremos cómo utilizar dos métodos de gestión de errores dentro de Power Automate:

Try / Catch / Finally

Como ocurre en muchos otros lenguajes de programación, en Power Automate también podemos utilizar esta funcionalidad. Su funcionamiento es simple. Si ocurre cualquier error no controlado, se detiene la ejecución del bloque Try, y se empieza a ejecutar el código, o en este caso las acciones, dentro del bloque Catch. El bloque Finally, sin embargo, se ejecutará siempre, existan o no errores.

Para crear estos 3 bloques, utilizaremos la acción Scope de Power Automate para identificar a cada uno de ellos. Dentro de cada bloque, añadiremos las acciones correspondientes.

De hecho, tenemos una plantilla disponible en Power Automate para probarlo fácilmente:

En esta plantilla, ya tenemos creados los 3 bloques por defecto, y además, en el bloque Catch, se envía un correo al usuario del flujo avisándole sobre el error.

Lo primero que haremos, es añadir una acción dentro del bloque Try, que recordad, es una acción del tipo Scope de Power Automate. En este caso, utilizaremos como ejemplo una consulta HTTP, que, dada una cierta IP, nos devolverá el país asociado. Evidentemente, podéis utilizar cualquier tipo de consulta o acción:

Una vez tengamos todas las acciones dentro del módulo Try, podemos probar el flujo. Si no se produce ningún error, veremos como el flujo omite el bloque Catch, y después del Try, salta directamente hacía el bloque Finally:

Ahora, modificaremos la acción HTTP, forzando a que devuelva un error, utilizando una URI falsa. En este caso, veremos que el flujo, después del error, entra primero en el bloque Catch, y posteriormente, en el bloque Finally. Importante recordar que todas las acciones del bloque Try que se encuentren después del error, no se ejecutarán.

Por lo tanto, utilizar los bloques Try / Catch / Finally, nos asegura que el flujo, por mucho que aparezcan errores sin controlar, terminará su ejecución correctamente. De hecho, si nos fijamos en la imagen anterior, vemos que el estado de esta última ejecución, en la que ha habido un error, es “ Test succedded “, ya que el flujo, ha podido llegar al final.

¿Que hubiera pasado si no utilizamos el bloque Catch? El flujo se detendría al detectar el error, sin ejecutar ninguna otra acción, y el estado del flujo quedaría en error.

Llegados a este punto, faltaría por explicar una pieza del puzzle: ¿cómo le indicamos a Power Automate que en caso de error tiene que dirigirse hacia el bloque Catch y no hacía el Finally? La solución la encontramos en la funcionalidad Configure run after:

Todas las acciones de Power Automate tienen disponible esta funcionalidad, y nos indica cual es la acción predecesora y cuando debe ejecutarse. En el caso del bloque Catch, vemos que la acción se ejecutará siempre y cuando la acción Try haya terminado con error (failed):

Sin embargo, la acción Finally, se ejecutará siempre después de la acción Catch, sea cual sea el estado con la que esta última haya terminado.

Es importante mencionar que por defecto, la opción Configure run after, aparece configurada para que se ejecute cuando la acción anterior ha terminado correctamente (Succedded).

Hemos comprobado que gracias a los bloques Try / Catch / Finally, todos los flujos pueden finalizar correctamente, aunque aparezcan errores no controlados. Por este motivo, mi recomendación es que utilicéis esta plantilla en todos vuestros flujos, y que dentro del bloque Catch, gestionéis las acciones necesarias en caso de error, como, por ejemplo:

• Envío de email/notificación
• Guardar el error en un log
• Deshacer una acción

Parallel branching

Este es otro de los métodos de gestión de errores que podemos utilizar en Power Automate. Se basa en la funcionalidad Configure run after que hemos visto en el punto anterior, y consiste en crear distintas ramas en función del estado en que termine determinada acción.

Por ejemplo, partiendo de la misma acción HTTP que en el ejemplo anterior, crearemos una rama para el caso que la solicitud HTTP termina con éxito, y otra rama, para cualquier otro caso. Para ello, utilizaremos la opción Add a parallel branch:

Una vez creadas las ramas, que podrían ser mas de 2, indicaremos en la primera acción de cada rama, cuando deben ejecutarse según el estado en que haya terminado la solicitud HTTP. En nuestro caso, devolveremos una respuesta al flujo (acción Response) en caso de que todo haya ido bien, y enviaremos un correo si ha habido algún error:

Hemos llegado al final de este artículo, en el que hemos visto que igual de importante es que un flujo responda correctamente ante un escenario idílico, que con una casuística con errores no controlados.

Follow the power!