What’s New in Mule 4
Mule 4’s simplified language and reduced management complexity enables you to speed up the on ramping process and deliver applications faster.
If you are familiar with the concepts of the previous versions of the runtime, check the sections below to learn what’s changing in Mule Runtime v4.0.
Simplified Event and Message Model
Mule 4 includes a simplified Mule Event and Message model. In Mule 4, Flows are triggered by an Event. An Event has 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. This simplified message model makes it easier to work with data in a consistent way across connectors without information being overwritten.
DataWeave 2.0: The New Mule Expression Language
In Mule 3, users had to contend with learning both the Mule Expression Language (MEL) and DataWeave. MEL forced users to convert their payloads from binary data, such as XML or JSON documents, into Java objects, so they could write expressions which access that data, for example when routing to a specific location.
In Mule 4, DataWeave is now the default expression language. Combined with the built-in streaming capabilities, this simplifies many common 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 features 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.
For details, see the links to DataWeave documentation.
Streaming Management
Mule 4 automatically handles data streams for users. This greatly simplifies 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 transparently access larger than memory data.
-
Users can customize whether data is stored on disk using streaming strategies.
Non-Blocking, Self-Tuning Runtime
Mule 4 includes a new execution engine that is based on a non-blocking runtime. This is a task-oriented execution model allowing you to take advantage of non-blocking IO calls and avoid performance problems due to incorrect processing strategy configurations.
As a result of this new engine, you no longer have to configure exchange patterns. Instead, flows always function synchronously. If you wish to achieve asynchronous type patterns such as fire and forget, you can use the <async> processor.
Each Mule event processor can now inform the runtime if it is a CPU intensive, CPU light, or IO intensive operation. This helps the runtime to self-tune for different workloads dynamically, removing the need for you to manage thread pools manually. As a result, Mule 4 removes complex tuning requirements to achieve optimum performance.
Enrich Events Directly from Connectors/Modules
For any given module operation, it is 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.
You can also control what is stored in the variable using the targetValue attribute. For example, if you wanted to only store the response code from an HTTP request, you could do the following:
<http:request target="myVar" targetValue="#[attributes.statusCode]" .../>Simplified Connectors and Modules Experience
Mule 4 introduces more consistency around modules and connectors, creating one unified experience for how to interact with Mule components.
Transports have been completely replaced by Mule Modules. Modules and connectors can be created and managed using the Mule SDK, which provides a single way to extend Mule.
Simplified Error Handling and New Try Scope
Mule 4 includes a simplified way to manage errors. Instead of dealing with Java exceptions directly, there is now an Error concept built directly into Mule. Furthermore, Mule Modules and Connectors declare what Errors may occur for any given operation. This makes it easy for you to discover possible errors at design time and catch them.
Exception strategies are replaced by error handlers allowing you to catch errors based on both type and arbitrary expressions.
You can configure your error handlers to catch errors so that the flow can keep processing, or they can be re-propagated.
There is also a new Try Scope, which allows you to catch errors in the middle of a flow without having to create a new flow, specifically to catch that error.
Batch is easier to use and is now a scope
In Mule 3, batch jobs were top-level concerns, similar flows. But we’ve simplified this so it is now a scope that can live inside a flow–– making it easier to understand, invoke dynamically, and interact with other Mule components. There are also no longer a special set of variables (i.e. recordVars) for batch. You can now just use flow variables directly; this reduces the complexity and makes it easier to learn how to write batch jobs.
Improved Upgradeability with Classloader Isolation
Mule 4 loads each Module in its own classloader, isolating the modules from internal Mule code making runtime upgrades a lot simpler by protecting you from changes by the runtime or connectors:
-
Connectors are now distributed outside the runtime, making it possible to:
-
Get connector enhancements and fixes without having to upgrade your runtime.
-
Upgrade your runtime version without breaking compatibility with other modules.
-
-
There is now a well-defined Mule API, so you can be sure you’re using supported APIs.
-
There is classloader isolation between your application, the runtime, and connectors, so that any library changes that happen internally will not affect your app.
Improved support for configuration
Mule 4 features an easier way to configure environment specific properties, which is Spring-optional. With it, you can now define application-specific properties in a YAML file inside your application. These will be the default properties for your application and you can override them using system properties. In the future, we’ll also be using this metadata to provide an improved configuration management UI from runtime manager.
Connectors and Modules Updates
Database Connector
The database connector has undergone minor updates:
-
Bulk operations have been separated so that operations do not change behavior depending on the received payload
-
There’s single experience for executing static and dynamic queries.
-
DataWeave transformations can be embedded inside the insert/update operations so that you can construct the datasets you want to send to the DB without having a side effect on the message or using enrichers
-
The connector will use Mule’s new streaming framework to handle large data sets.
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. This enables many new capabilities:
-
The ability to read files or fully list directories’ contents on demand, unlike the old transport (which only provided a polling inbound endpoint)
-
Top level support for common file system operations such as copying, moving, renaming, deleting, creating directories, and more
-
Support for locking files on the file system level
-
Advanced file matching functionality
-
Support for local files, FTP, SFTP and FTPS
JMS Connector
The JMS connector has been updated to utilize the new, simplified connector experience. In addition to the JMS listener and sender, you 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 you to now embed your Groovy, Ruby, Python, or JavaScript scripts inside Mule flows. You can inject data from the Mule message into your code using the new parameters configuration attribute.
<script:execute engine="groovy">
<script:code>
return "$payload $prop1 $prop2"
</script:code>
<script:parameters>
#[{prop1: "Received", prop2: "A-OK"}]
</script:parameters>
</script:execute>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 you add the Spring module to your application, and simply import your Spring bean files.
<spring:config name="springConfig" files="beans.xml"/>Mule SDK
The Mule SDK is a successor to the Anypoint Connector Devkit. It enables developers to easily extend Mule and create new Mule modules which can be shared in Exchange. Unlike Mule 3, where there were multiple ways to create extensions, the Mule 4 SDK provides a single way to extend Mule, assuring consistency and upgradeability of components. It was used to build all Mule 4 modules and connectors.
While similar to DevKit in many respects, it features many improvements:
-
The SDK does not generate code, which enables extensions to get new runtime features without having to be re-released
-
Transactions support
-
Request-Response message sources support
-
Dynamic configurations
-
Router support
-
Non Blocking operations
-
Classloading isolation