Mule 4.0 is the latest iteration of the Mule runtime engine. Since its release in 2010, Mule 3 has earned a global reputation across every major industry for its simplicity and small footprint. In planning for the fourth iteration of Mule, MuleSoft went back to the basics that guided the success of its predecessor to answer 4 key questions:
How do we make Mule even easier to use?
How do we simplify common tasks?
How do we ensure the runtime runs at its best, without manual tuning?
How do we reduce long-term maintenance costs by simplifying operations and upgrades?
Mule 4 innovatively delivers a vastly more powerful all-purpose engine for building application networks, while retaining everything users of Mule 3 loved; its lightweight runtime and extensibility.
What’s New in Mule 4?
In Mule 3, when we use DW and transform messages, we need to explicitly convert the message to a Java object so that the output can be used in Router components, For Each, etc. In Mule 4, you don’t need to explicitly convert messages to Java objects. Mule 4 will do it automatically for you.
New Database Connector
There’s a brand new Mule 4 Anypoint Connector for Database (DB) that you can use to connect to any relational database engine. Unlike other connectors such as File or FTP, this connector has a pretty similar UX compared to the one in Mule 3.x, with some considerable improvements, including:
Dynamic queries simplified
Dynamic queries simplified
- Streaming simplified
Anypoint Studio 7
Studio 7 will offer
- Transparent and easy Maven integration
- New Mule palette
- Improved visual designs and UX
- Support for Mule 4 Beta runtime
- A new way to store your application’s custom types
Connector updates are no longer bound to the Runtime updates. They are no longer stored inside Runtime- instead, they are distributed outside. It makes it easier to get the connector updates. So, one can update the whole Runtime to get all the updates of the connectors/components, or one can update only the specific connector/component. This gives us a lot of flexibility and can decrease the problems that we might have when updating the whole 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.
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.
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 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.
Batch Process Simplified 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.
Benefits of Migrating to Mule 4
Operations simplified: Mule 4’s simplified language and reduced management complexity allow users to speed up the on-ramping process and deliver applications faster. However, users familiar with the concepts of the previous versions of the runtime are not left behind; since the newest iteration of Mule only simplifies the day-to-day development.
Easier to learn: Mule 4 has been made easier to learn for users of varying technical knowledge. Mule 4 development requires less experience to leverage its capabilities. The essential skills like Java, Spring and Maven are optional in the Mule 4 landscape.
Enhanced productivity: Mule 4, provides another step towards enabling the idea of Citizen Integrators (integration by non-IT personnel). The ‘Anypoint Design Centre’ can be used by non-technical users to implement Mule flows and APIs. Simple web-based drag-and-drop tools embedded within the Anypoint Platform help accelerate the productivity within the organization.
Mule 4 Upgrade
A Mule 4 upgrade should be approached as a migration project. Mule 4 received an unprecedented amount of innovative updates and changes. In Mule 4, the testing framework has been updated to MUnit 2. Therefore, the application and test packages need to be updated or refactored to meet the latest specifications and standards.
Migrating to Mule 4 from a Mule version older than 3.8.x extends the challenge further. Applications which have runtimes older than Mule 3.8.x need to be upgraded to the latest 3.8.x or 3.9.x versions beforehand.