• Overview
Mule 4 reduced management complexity, which enables us to speed up the on ramping process and deliver applications faster.
Below are the new changes happens in Mulesoft version 4.X.X
  • Event and Message Model
Mule 4 introduce a simplified Mule Event and Message model. Here the flows are triggered by an event.
An Event contains a Message and variables associated with it.
A Message is composed of a payload and its attributes (metadata, such as file size).
Variables hold arbitrary information, such as Messages, payload data, or attributes.
  • DataWeave 2.0
In Mule 4, DataWeave is now the default expression language.
DataWeave 2.0 has built-in streaming capabilities, this has many tasks:
      Events can be routed based on payload data, without first needing to convert them to Java objects.
      Binary data can easily be queried from an expression anywhere in your flow, for example, when logging.
      Larger than memory access to data happens transparently.

DataWeave 2.0 also has many improvements:
      Language simplifications. Everything is now a function.
      DataWeave scripts can now be packaged and reused, via the new imports and modules features.
      Support for multi-line comments.
      Support for calling static Java methods directly from DataWeave.
  • Streaming Management
Mule 4 automatically handles data streams for users.
Streaming is working with data in the runtime because:
      Data can be read multiple times or accessed randomly using the DataWeave expression language without side effects.
      Data can be sent to multiple places, without the user caching that data in memory first.
      Users can customize whether data is stored on disk using streaming strategies.
      Users can transparently access larger than memory data.

  • Non-Blocking, Self-Tuning Runtime
Mule 4 includes new runtime that is based on a non-blocking.
This non-blocking IO calls avoid performance problems due to incorrect processing strategy configurations.
Because of this new engine, we no longer have to configure exchange patterns.
In this new Runtime, flows always function synchronously. If we wish to achieve asynchronous type patterns, we can use the async processor.
In this new Runtime, we can now inform the runtime if it is a CPU intensive, CPU light, or IO intensive operation. As a result, Mule 4 removes complex tuning requirements to achieve best performance.
  • Enrich Events Directly from Connectors & Modules
Now possible to define a target (or target variable), which saves the result in a variable:
http:request target="myVar" config-ref="requestConfig" method="GET" url="http: //mulesoft.com"
This saves the Mule message in the myVar variable to be accessed later. This reduces flow complexity by removing the need for an enricher.

We can also control what is stored in the variable using the targetValue attribute.
Example :- http:request target="myVar" targetValue="#[attributes.statusCode]" ...
  • Simplified Error Handling and New Try Scope
Exception strategies are replaced by error handlers allowing you to catch errors based on both type and arbitrary expressions.
We can configure your error handlers to catch errors so that the flow can keep processing, or they can be re-propagated.
There is a new Try Scope, which allows us to catch errors in the middle of a flow without having to create a new flow, specifically to catch that error.
  • Batch as scope
In Mule 3, batch jobs were top-level, similar like flows. But in Mule 4 it is now a scope, that can present inside a flow. Which makes easy to understand, invoke dynamically, and interact with other components.
There are also no longer a special set of variables (i.e. recordVars) for batch. We can now use flow variables directly. This reduces the complexity and makes it easier to write/read batch jobs.
  • Classloader Isolation
Mule 4 loads each Module in its own classloader.
Mule 4 isolate the modules from internal Mule code making runtime upgrades a lot simpler.
Mule 4 isolate the modules from internal Mule code making runtime upgrades a lot simpler. So that we no need to do any changes in runtime or in connectors.
      Connectors are now distributed outside the runtime, making it possible to:
    1. Get latest connector enhancements and fixes without upgrade our runtime.
    2. Upgrade our runtime version without breaking compatibility with other modules.
      There is classloader isolation between your application, the runtime, and connectors. So that any library changes that happen internally will not affect our app.
      There is now a well-defined Mule API, so you can be sure we are using supported APIs.

  • Improved in Mule App configuration
Mule 4 help us to configure environment specific properties.
With Mule 4 we can now define application-specific properties in a YAML file inside our application.
These will be the default properties for your application and you can override them using system properties.
  • Connectors and Modules Updates
  • Database Connector
    Here are the list of database connector :
        Bulk operations have been separated so that operations do not change behavior depending on the received payload
        The connector will use Mule’s new streaming framework to handle large data sets.
        DataWeave transformations can be involve inside the insert/update operations

  • File and FTP Connectors
    The File and FTP connectors have been improved so that they are operation based and share the same set of operations.

  • JMS Connector
    The JMS connector has been updated to utilize the new, simplified connector experience.
    In addition to the JMS listener and sender, we can also consume messages in the middle of a flow using the JMS consume operation.

  • Scripting Module
    The scripting module is now updated for Mule 4, enabling us to now embed our Groovy, Ruby, Python, or JavaScript scripts inside Mule flows.

  • Spring module
    Mule 4 decouples the Mule internals from Spring, ensuring that users don’t need to know Spring to learn Mule and enables Spring users to select which version of spring they run.
    To use Spring beans, now we add the Spring module to your application, and simply import our Spring bean files.
    Example : spring:config name="springConfig" files="beans.xml"

  • VM Connector
    In addition to the VM listener and sender, we can also consume messages in the middle of a flow using the VM consume operation.

  • Other Modules and Connectors
    All other modules and connectors that have been updated have been updated to be consistent with the overall Mule 4 experience, but have otherwise gone through no functionality changes unless explicitly noted in their release notes.

If you got some knowledge about "What is new in Mule 4?", please follow with me in next topic to understand about "Event and Message Model".

Comments