¿Qué hay de nuevo en Mule 4.4?

La última versión del Runtime 4.4.0 de Mule lleva con nosotros ya unos cuantos meses, desde Octubre del 2021, pero si aún así sigues dudando de si debes o no actualizar tus aplicaciones Mule a ella, si aún no tienes claro qué aporta esta versión respecto a la 4.3.0 y si no tienes claro qué versión utilizar en tu próximo desarrollo, vamos a dar un repaso rápido a las características más destacables que nos ha traído (bugfixes aparte).

Gestión del correlationId

Cuando Mule crea un nuevo evento, genera un *Java Universally Unique Identifier* (UUID) llamado *correlationId* antes de enviar el evento al siguiente procesador del flujo. Este ID le permite correlacionar diferentes entradas de registro con una ejecución en concreto.

Podemos usar este id para seguir todo el historial de un evento que haya provocado un error, por ejemplo.

Para obtener un correlationId, Mule primero comprueba si hay uno en el mensaje de origen (por ejemplo, un mensaje JMS o un listener HTTP con la cabecera X-CORRELATION-ID). Si el origen no establece uno, Mule genera uno utilizando su propio generador.

A partir de ahora, podemos crear nuestro propio generador. En principio no parece una gran idea, pero podría ser necesario si:

  • Tu empresa tiene un formato propio
  • Otros sistemas tienen otro formato o longitud, lo que hace imposible hacer un rastreo correcto

Podemos generar nuestro patrón una configuración de este estilo:

```xml
<configuration correlationIdGeneratorExpression="#[<custom_generator_expression>]"/>
```

Mejoras en el sistema de logging

Se ha incorporado un nuevo *Mapped Diagnostic Context (MDC)*, que enriquece el logging y mejora el seguimiento al proporcionar más contexto o información en los logs para los eventos de Mule.

Por defecto, Mule registra dos entradas MDC

  • Procesador, que muestra la ubicación del evento actual
  • Evento, que muestra el correlationId del evento.

Utilizando este módulo podremos añadir, eliminar y borrar variables del contexto de log para un determinado evento de Mule y este contexto de log existirá para toda la ejecución del evento correspondiente.

Si quieres ampliar esto, puedes acceder a MuleSoft.

mulesoft

Dataweave 2.4.0

Con esta nueva versión del runtime vamos a poder hacer uso de la nueva versión de Dataweave. Para no hacer demasiado largo este artículo, simplemente comentaremos las principales novedades, dejando para otra ocasión entrar al detalle en ellas:

- Posibilidad de leer automáticamente *larger-than-memory strings*. Cuando se utiliza la *indexed reader strategy* y se procesa un string con un tamaño superior a 1,5 MB, DataWeave divide automáticamente el valor en trozos para evitar problemas de falta de memoria.

- Nuevas propiedades de lectura y escritura para trabajar con formatos de datos. Por ejemplo, el escritor XML permite ahora definir espacios de nombres en el nivel raíz. Puedes consultarlos en este enlace sobre las nuevas funciones de DataWeave.

- Nuevos módulos, funciones, tipos, anotaciones y variables. Algunos son experimentales y podrían variar en el futuro. Puedes consultarlos en este enlace sobre funciones, módulos y características de Dataweave 2.4.0.

- Algunas funciones se han sobrecargado para poder manejar valores *null.*

Módulo de Mule Tracing

Este módulo nos permite mejorar los logs añadiendo, eliminando y borrando todas las variables del *logging context* para un determinado evento de Mule. También le permite modificar el correlationId durante la ejecución del flujo. De hecho, tiene relación con lo que hemos comentado antes sobre los correlationId.

Puede que esta funcionalidad mereciera un artículo completo, así que os animo a echar un vistazo a este artículo sobre Tracing Module 1.0.

Mencionar que podemos hacer cosas como:

  • Modificar correlation ID durante la ejecución de un flujo.
  • Configurar variables de *logging*

Mecanismo de “Feature Flagging”

Se ha incorporado un mecanismo de marcado de características que permite a las aplicaciones cambiar el comportamiento en función de la versión mínima de Mule requerida.

Esto garantiza la retrocompatibilidad con versiones anteriores, ya que permite que las aplicaciones sigan funcionando en versiones más modernas del runtime, mientras que las nuevas aplicaciones pueden aprovechar las últimas correcciones de errores.

Este mecanismo es automático. Para cada aplicación desplegadas, Mule determina qué características están habilitadas o deshabilitadas en función de la versión Mule mínima configurada en el archivo descriptor de la aplicación (mule-artifact.json).

Por defecto, el runtime deshabilita cualquier característica nueva o corrección de errores que no sea compatible con aplicaciones que se ejecuten en versiones anteriores. Sin embargo, es posible gestionar los *feature flag* configurados para cada aplicación o para todas las aplicaciones que se ejecutan en la misma instancia.

Cómo configurar los *feature flag*

Para una aplicación

Para hacer esto, podemos cambiar el valor minMuleVersion en el archivo mule-artifact.json de la aplicación. Esta configuración indica a la instancia que ejecute esta aplicación implementando todas las características y correcciones de errores que se publicaron en esa versión concreta y deshabilitando las características y correcciones de errores que están activas por defecto en versiones más modernas.

Por ejemplo, puedes ejecutar una aplicación usando el runtime 4.4.0 indicando a la instancia que aplique sólo las características que no cambian la funcionalidad del núcleo hasta Mule 4.1.0

Un ejemplo de un archivo `mule-artifact.json` sería:

```json
{
  "minMuleVersion": "4.1.0"
}
```

Para una instancia

Una forma alternativa de configurar los *feature flag* es utilizando las propiedades del sistema. En este caso, puedes activar o desactivar cada uno de los *feature flag* disponibles. Esto hará que todas las aplicaciones desplegadas en la misma instancia se comportarán de la misma manera.

Un ejemplo de un archivo `wrapper.conf` sería:

```json
…
wrapper.java.additional.999=-DHONOUR_RESERVED_PROPERTIES_PROPERTY=true
wrapper.java.additional.1000=-DCOMPUTE_CONNECTION_ERRORS_IN_STATS_PROPERTY=false
```

 

Para consultar la lista de *feature flag* disponibles, puedes ir consultar este artículo sobre configurar feature flags.

Queda esta lista como una visión por encima de lo que ha venido nuevo, que podremos ampliar en otros artículos.

De momento, quedamos a la espera de qué traerá la siguiente versión y cuándo lo hará.

Referencias

 

 

 

Tags

He leído y acepto la política de privacidad
Acepto recibir emails sobre actividades de recruiting NTT DATA