Introduction
After gaining huge popularity with mule 3, Mulesoft decided to release mule 4 with a drastic change. They re-implemented the engine, re-structured the Mule message, wiped out mule expression language, redesigned error handling and many more. Due to some fundamental changes in mule 3, they could not come up with any migration tool for migrating mule 3 to mule 4. Moreover, they had to extend the support for mule 3 till March 20, 2021, and extended support till March 20, 2024.
Many organization already built their API platforms based on mule 3 and now evaluating the mule 4 to migrate. A common question is: is it worth it? Let’s have a quick glance at the differences between mule 3 and mule 4.
Differences between Mule 3 and Mule 4:
1. Mule runtime engine:
After gaining huge attention by mule 3, many organization started to build plenty of micro-services, APIs, ETLs and integration interfaces in their large enterprise settings. Although mule 3 helped developers to reduce development steps and increase productivity, achieving great performance was still a challenge in large enterprise volume. Mulesoft did not wait any longer and brought mule 4. They develop a self-tuning runtime engine in mule 4 that dynamically allocates resources, threads and the thread-pool. Depending on the situation, whether it is CPU or IO sensitive, the runtime engine smartly and automatically assigns thread pools to any mule 4 connectors. Manual configuration of the thread pool exists through conf/scheduler-pools.conf file.
2. Project structure
Mulesoft introduced a new version of Anypoint Studio, i.e. version 7 that only runs mule 4 application and Anypoint studio 6.x.x or below can only run mule 3. Mule 3 project structure is not recognized by Anypoint studio 7.x.x
There were two types of projects in mule 3: Mule project and Mulesoft application with Maven project. However, it is simplified in mule 4 by only keeping one option. All mule 4 applications are Maven based now. Eventually, Anypoint studio 7.x.x embeds maven and a default configuration which is not the case in Anypoint studio 6.x.x or below.
There is also another big change in mule 4 which is: mule 4 application is no longer a deployable zip package, it’s now actually a jar file. A jar can be distributed for deployment as well as for sharing with others. Import option in Anypoint studio 7.x.x can build the Mule project from the jar (if it is built accordingly).
3. Mule message structure:
Mule Message in mule 3 comprised of two parts: message header and payload. Message header again consists of some properties, mainly inbound and outbound. Variables in mule 3 are metadata of the message.
However, mule 4 consider more like event-based model where each Mule event consists of a message and associated variables. There is nothing called inbound or outbound properties in mule 4, rather, there is an attribute that contains all the headers and other relevant properties.
For example, the syntax of reading HTTP method from a HTTP request in mule 3 is #[message.inboundProperties[‘http.method’] which becomes #[attributes.method] in mule 4
4. MEL is replaced by DataWeave:
Yes, you read that right! Mule expression language (MEL) is no longer available in mule 4. They introduced DataWeave 1.0 in mule 3 in replace of their DataMapper. DataWeave is very simple yet powerful. It is based on functional programming and lambda calculus. mule 4 started with DataWeave version 2.0 and replaced MEL with it. While writing this article, Mulesoft just published their latest DataWeave version 2.2.0 and enriched it by adding more functions and libraries. They added a very cool feature in this version that dumps the whole context when a DataWeave script fails. To enable the feature use the following flags:
Dumps the context on an exception: -Dcom.mulesoft.dw.dump_files=true
The directory to put the dump file (default in tmp dir): -Dcom.mulesoft.dw.dump_folder=<your folder>
5. Error handling
Mule 3 does not really have any specific framework to identify the error type and nature, rather, it totally relies on developers implementation based on Java exception. Mule 4 has taken a step ahead and come up with some error groups, types and different way to handle them. It’s much cleaner, readable and simpler now.
There are tons of other changes that cannot be covered by one article. This article is intended to provide a very high-level view of the changes. Detail changes will be discussed in different articles.
Although mule 4 looks great and solid, it is still considered in its young stage of development. So, experiencing different types of bugs and issues are common. Few notable issues are Anypoint Studio performs really slow when it loads lots of applications. There are some memory leakages in version 7.3.2 which is fixed recently in Anypoint studio version 7.3.3.
There are many other issues that someone may experience related but not limited to maven configurations, managing mule-application as a jar, adding reusable global error handler as dependencies, meta sense issue in weave, inconsistency between RAML validation between design center and Anypoint studio and so on. However, looks like mule 4 is the basic foundation for Mule ESB which may help developers writing solid and robust micro-services in an agile fashion.
P.S. Separate article will address individual mule 4 issues and their workarounds. Stay tuned!
