Mule 3 to 4 Migration #2

Mule 3 to 4 Migration

August 19, 2020
2 min Read

Mule 4 has several great features and there are various reasons to move to Mule 4 from the existing Mule 3 project. Let us understand the process –

What is new or different in Mule 4

Error handling is much easier in Mule 4. These are not more java based and segregated per connectors. Moreover, the introduction of the ‘try’ block helps in having inflow error handlers rather than using a centralized one always.
Connectors are now split per operation which does help in both designing and managing the operations.
A self-tuning Mule 4 engine does take care of thread pooling, processing strategies for better performance.
Mule 4 applications are default maven based which was optional in Mule 3
Dataweave 2.0 has simplified implementation than 1.0 and replaced MEL completely
Mule 4 connectors do not have to wait for runtime up-gradation. Connectors up-gradation happens separately to runtime up-gradation
Mule 4 helps with seamless access to data. For example, It is not required to convert the data to java to route through the ‘for-each’ loop. It can pick a JSON array and process it. This was not the case during mule 3.
Message enrichment has been simplified. Now, this is not a separate scope unlike mule 3. Mule 4 uses target variables across connectors, flows, etc. to store the data.
The Mule message now looks more simplified and it contains strongly typed objects namely attributes. It does contain metadata and varies as per the connectors being used.

To know more in details click here

When to migrate to Mule 4 –

There can be several reasons to upgrade to Mule 4

The mule 3 licenses in expiring
We want to use the above-mentioned benefits on mule 4
The organization wants to be up to date with the additional capabilities Mule 4 is providing and be open to upgrade in the future.
The team has completed all the necessary training to understand the Mule 4 module and has prior knowledge of mule 3 as well.

Steps for migration-

Before we start about the process of migrating Application from mule 3 to mule 4 we need to follow below steps –

Upgrade all mule project to 3.9 and use the benefit of extended support till March 20, 2024
Train resources to Mule 4. Clearing the Mule 4 certification or performing a small POC will give a level of confidence.
Develop new applications in Mule 4.
Create a document to create the steps of the checklist for the migration of existing processes.
Start migrating the projects which are not critical (as the current license has a life of 4 years). This will help in understanding the process and redefining the steps if required. Also by minimizing the effect of issues post-migration and keeping the business running better.
Follow steps 4 and 5 and migrate all the applications.
There are two ways we can start migrating the application

Complete manual process:

Add all secure properties in the newly created mule 4 application
Migrate all the global configuration
Add necessary modules to Mule palette so that the dependencies get added to pom.xml. In case the connector is missing in Studio, get it from Exchange.
As the Mule message structure has changed, update the reference of the same as per the new structure.
Migrate all dataweave 1.0 and MEL expressions to dataweave 2.0.
All exception handling needs to be updated as per Mule 4 way.
Perform Unit testing for newly created applications.
Also, follow the cheat list to have a better understanding. However, this list is just for reference. The checklist is unique as per the implementation.

Using mule-migration-assistant-runner:

This is a semi-manual way of converting the mule 3 application to mule 4

download mule migration assistant from here
Unzip the zip file and keep it to a location. Post unzip there will be one jar file and folder named \lib
Navigate to the folder containing the jar file and using command prompt, run below command

java -jar mule-migration-assistant-runner-0.5.1.jar -muleVersion <mule version> -projectBasePath <mule 3 project path> -destinationProjectBasePath < mule 4 project path>
After executing the above step open navigate to the folder where the mule 4 file is created. Note that the project can not be opened using pom.xml. So import the project as an anypoint executable file systems
Once the project is created open the summary file to check the “Errors”, “Warnings” and “Info”
- Errors – Should be fixed before running the application
- Warnings – This will allow the application to run. However, it is advisable to replace these components before deployment.
- Info – This gives information about the mule 3 features which are changed or removed from the project after migration.
  
  These details are part of the newly created .xml file. Fix and remove the comments before deployment.

Sample project using mule-migration-assistant-runner:

Let us create a simple project in Mule 3 which does receive a name as a query parameter and returns the greetings message in response. Below is the screenshot from Mule 3 environment

Next, we need to use navigate to the folder which contains the assistant runner

Open cmd and run below command to execute the file conversion

Once the file is converted successfully. Import the project to the studio using File->Import->Anypoint Studio->Anypoint studio project from the file system and select the project root the folder containing the project.

Once imported ope the summery.html under /report/resources. You will see a file like below

In the above report, we see there are four warnings. However mulesoft will allow the API to run as the mule compatibility module will help in running the project. We can see the mule compatibility module helps in remapping the configuration from mule 3 to mule 4 for configuration like HTTP headers. However, these should be fixed before deployment.

Once all the issues are resolved we will perform testing and our newly created mule 4 application is ready for deployment.

Observation:

Though mule-migration-assistant-runner(MMA) helps in creating the Mule 4 project from Mule 3, we would still prefer to follow the manual process with the use of a predefined manual checklist. The reason is using MMA we get only the structure, but there are still various manual processes to be done like converting dataweave 1 to dataweave 2, creating error handler as per mule 4 standard, etc. Also, need to fix all the warnings and Errors which we get in the summary.html.
MMA needs further improvement and we hope mulesoft to come with a better solution to have minimal manual effort involved. Till then having a manual process with a predefined checklist for migration is a better approach.

More about the author here: Soumitra Giri