Curso de Mulesoft en español || Punto de control 2 Error Handler

Punto de Control 2

En el punto de control 2 vamos a repasar los conceptos teóricos para poder pasar al siguiente nivel y no perderos con definiciones que no acabáis de entender. Ya sé que la teoría es un rollo, pero voy a intentar que no se os atragante con algún que otro dibujito. ¿Os parece?

En este bloque hemos aprendido a manipular los errores de un evento de Mule utilizando diferentes niveles. ¿Los recuerdas?…espero que sí.

Errores no manipulables

Una aplicación de Mulesoft puede tener errores de sistema, externos al propio evento que se crea al ejecutar una Mule Application.

Los errores de sistema son lanzados, obviamente, a nivel de sistema y no involucran al evento de Mule. Esto sucede durante el despliegue de una Mule Application o cuando la conexión de un sistema externo falla.

La consecuencia de este tipo de errores es que no son manipulables por Mulesoft porque no dependen de la propia aplicación, se puede revisar en los Logs los errores de configuración o realizar estrategias de reconexión contra estos sistemas externos.

Si observáis la siguiente imagen, el error sucede fuera de la Mule Application, por lo tanto, es imposible manipular ese error, salvo realizar una solicitud nueva y cruzar los dedos para que sea satisfactoria.

Errores manipulables

Los errores de Mulesoft se pueden manipular cuando ocurre dentro de un Flow, por lo tanto, está envuelto en un evento de Mule.

¿Cómo sería el flujo?

Un componente, de tipo Event Source, inicia un evento de Mule.
Un error sucede en el evento.
La ejecución del evento se para y va a buscar el Error Handler configurado. Por orden:
1. Proceso (Try-Scope).
2. Flow.
3. Global.
4. Por defecto.
Finalmente, sea el Error Handler que sea, el Event Source devolverá lo que contenga el Body de Response o Error Response (dependiendo si es On Error Propagate o On Error Continue).

A continuación, os dejo un diagrama con el orden y prioridades de los Error Handler según el nivel.

Recordar también que los SubFlows no pueden tener Error Handlers, pero se podría añadir un Try-Scope dentro del él para poder manipular los errores. Pequeño truquito.

Alcance y tipos de errores

Los Error Handlers, independientemente del nivel, pueden tener diferentes alcances, o como le llaman en inglés, Error Scopes. Estos Error Scopes se identifican por los Error Types, uno de los componentes del objeto Error, explicado en la clase Revisar y manipular errores por defecto.

Si se tienen múltiples Error Scopes con diferentes Error Types, el orden de comprobación será según su posición, por lo tanto, la primera posición será la primera en comprobarse. En el caso del ejemplo que muestro, el primer Error Type a comprobar será AMERICAN-FLIGHTS-API:FORBIDDEN.

Estos Error Scopes pueden ser de dos tipos:

On Error Propagate. Manipula y devuelve un error, muestra el contenido del Body del apartado Error Response del Event Source. Propaga el error a los Flows que hay por encima (Parent Flows), cuando se llama por Flow Reference a otro Flow (Child Flow), y este devuelve un error, la respuesta que le llegará al Parent Flow será de error.
On Error Continue. Manipula y devuelve un mensaje satisfactorio, muestra el contenido del Body del apartado Response del Event Source. No propaga el error a los Flows que hay por encima (Parent Flows), cuando se llama por Flow Reference a otro Flow (Child Flow), y este devuelve un error, la respuesta que le llegará al Parent Flow será satisfactoria.

Error Handler de APIKit

Por defecto, las Mule Application, si se crean según la metodología que indica Mulesoft, mediante una API Specification, se generan automáticamente los Error Handlers que controlan los Error Types de tipo HTTP.

Esto es gracias al componente APIKit Router, que se encarga de enrutar, basándose en el RAML definido en la API Specification, con los Flows de la Mule Application. Estos Flows tienen como Event Source un HTTP Listener, por lo tanto, los Error Types que lanzarán serán de este tipo. La nomenclatura del Error Type, por ejemplo, APIKIT:BAD_REQUEST. El Error Scope que se añade por defecto es On Error Propagate, para propagar el error a capas superiores (ya lo veremos en niveles más avanzados).

Espero que os haya gustado el bloque 2 del nivel 4. Para finalizar, os dejo un pequeño test del punto de control 2 para validar vuestros conocimientos y poder seguir dándole caña afianzando conocimientos.

Si quieres saber más o necesitas ayuda personalizada, puedes suscribirte a mis servicios en el siguiente enlace

➡️ SUSCRIBIRSE A INGENIERO BINARIO ⬅️

¡Ponte a prueba con el test del punto de control 2!

Clases del curso

< Volver al curso