MuleSoft - Manejo de excepciones de Mule
En el caso de todos los proyectos, el hecho de las excepciones es que están destinadas a suceder. Por eso es importante capturar, categorizar y manejar las excepciones para que el sistema / aplicación no quede en un estado inconsistente. Existe una estrategia de excepción predeterminada que se aplica implícitamente a todas las aplicaciones de Mule. Revertir cualquier transacción pendiente automáticamente es la estrategia de excepción predeterminada.
Excepciones en Mule
Antes de profundizar en el manejo excepcional, debemos comprender qué tipo de excepciones pueden ocurrir junto con tres preguntas básicas que un desarrollador debe tener al diseñar controladores de excepciones.
¿Qué transporte es importante?
Esta pregunta tiene mucha relevancia antes de diseñar manejadores de excepciones porque no todos los transportes apoyan la transnacionalidad.
File o HTTPno admite transacciones. Por eso, si se produce una excepción en estos casos, debemos gestionarla manualmente.
Databasestransacciones de apoyo. Al diseñar controladores de excepciones en este caso, debemos tener en cuenta que las transacciones de la base de datos se pueden deshacer automáticamente (si es necesario).
En caso de REST APIs, debemos tener en cuenta que deben devolver los códigos de estado HTTP correctos. Por ejemplo, 404 para un recurso no encontrado.
¿Qué patrón de intercambio de mensajes se utilizará?
Al diseñar controladores de excepciones, debemos cuidar el patrón de intercambio de mensajes. Puede haber un patrón de mensaje sincrónico (solicitud-respuesta) o asincrónico (fuego-olvido).
Synchronous message pattern se basa en el formato de solicitud-respuesta, lo que significa que este patrón esperará una respuesta y se bloqueará hasta que se devuelva una respuesta o se agote el tiempo de espera.
Asynchronous message pattern se basa en el formato de olvido de fuego, lo que significa que este patrón asume que las solicitudes se procesarán en última instancia.
¿Qué tipo de excepción es?
Una regla muy simple es que manejará la excepción según su tipo. ¿Es muy importante saber si la excepción se debe a un problema técnico o del sistema oa un problema comercial?
Una excepción ocurrió por system/technical issue (como una interrupción de la red) debe manejarse automáticamente mediante un mecanismo de reintento.
Por otro lado, ocurrió una excepción by a business issue (como datos no válidos) no debe resolverse aplicando un mecanismo de reintento porque no es útil reintentar sin corregir la causa subyacente.
¿Por qué categorizar las excepciones?
Como sabemos que no todas las excepciones son iguales, es muy importante categorizar las excepciones. En un nivel alto, las excepciones se pueden clasificar en los dos tipos siguientes:
Excepciones comerciales
Las principales razones para la ocurrencia de excepciones comerciales son datos incorrectos o flujo de proceso incorrecto. Este tipo de excepciones no suelen ser de naturaleza recuperable y, por tanto, no es bueno configurar unrollback. Incluso aplicandoretryEl mecanismo no tendría ningún sentido porque no es útil volver a intentarlo sin corregir la causa subyacente. Para manejar tales excepciones, el procesamiento debe detenerse inmediatamente y la excepción debe devolverse como respuesta a una cola de mensajes no entregados. También se debe enviar una notificación a las operaciones.
Excepciones no comerciales
Las principales razones para la aparición de excepciones no comerciales son problemas del sistema o problemas técnicos. Este tipo de excepciones son de naturaleza recuperable y, por lo tanto, es bueno configurar unretry mecanismo para resolver estas excepciones.
Estrategias de manejo de excepciones
Mule tiene las siguientes cinco estrategias de manejo de excepciones:
Estrategia de excepción predeterminada
Mule aplica implícitamente esta estrategia a los flujos de Mule. Puede manejar todas las excepciones en nuestro flujo, pero también se puede anular agregando una estrategia de excepción catch, Choice o Rollback. Esta estrategia de excepción revertirá cualquier transacción pendiente y también registrará las excepciones. Una característica importante de esta estrategia de excepción es que también registrará la excepción si no hay transacción.
Como es la estrategia predeterminada, Mule implementa esto cuando ocurre algún error en el flujo. No podemos configurar en AnyPoint Studio.
Estrategia de excepción de reversión
Suponga que si no hay una solución posible para corregir el error, ¿qué hacer? Una solución es utilizar la estrategia de excepción de reversión, que revertirá la transacción junto con el envío de un mensaje al conector de entrada del flujo principal para volver a procesar el mensaje. Esta estrategia también es muy útil cuando queremos reprocesar un mensaje.
Example
Esta estrategia se puede aplicar a transacciones bancarias donde los fondos se depositan en una cuenta corriente o de ahorros. Podemos configurar una estrategia de excepción de reversión aquí porque, en caso de que ocurra un error durante la transacción, esta estrategia revierte el mensaje al principio en el flujo para reintentar el procesamiento.
Estrategia de captura de excepción
Esta estrategia detecta todas las excepciones que se lanzan dentro de su flujo principal. Anula la estrategia de excepción predeterminada de Mule al procesar todas las excepciones lanzadas por el flujo principal. Podemos utilizar una estrategia de captura de excepciones para evitar la propagación de excepciones a los conectores entrantes y a los flujos principales.
Esta estrategia también garantiza que una transacción procesada por el flujo no se deshaga cuando se produce una excepción.
Example
Esta estrategia se puede aplicar al sistema de reserva de vuelos en el que tenemos un flujo para procesar mensajes de una cola. Un enriquecedor de mensajes agrega una propiedad en el mensaje para la asignación de asiento y luego envía el mensaje a otra cola.
Ahora, si ocurre algún error en este flujo, el mensaje generará una excepción. Aquí, nuestra estrategia de captura de excepción puede agregar un encabezado con un mensaje apropiado y puede empujar ese mensaje fuera del flujo a la siguiente cola.
Estrategia de excepción de elección
En caso de que desee manejar la excepción en función del contenido del mensaje, la estrategia de excepción de elección sería la mejor opción. El funcionamiento de esta estrategia de excepción será el siguiente:
- Primero, captura todas las excepciones lanzadas dentro del flujo principal.
- A continuación, comprueba el contenido del mensaje y el tipo de excepción.
- Y, por último, dirige el mensaje a la estrategia de excepción adecuada.
Habría más de una estrategia de excepción como Catch o Rollback, definida dentro de la estrategia de excepción de elección. En caso de que no haya una estrategia definida bajo esta estrategia de excepción, entonces enrutará el mensaje a la estrategia de excepción predeterminada. Nunca realiza ninguna actividad de compromiso, reversión o consumo.
Estrategia de excepción de referencia
Esto se refiere a una estrategia de excepción común que se define en un archivo de configuración independiente. En caso de que un mensaje arroje una excepción, esta estrategia de excepción se referirá a los parámetros de manejo de errores definidos en una estrategia global de captura, reversión o excepción de elección. Al igual que la estrategia de excepción de elección, nunca realiza ninguna actividad de compromiso, reversión o consumo.