Mule 3 to Mule 4

download.png

Are You Ready for Mule 4?

Mule 4. It’s here.

And here at Admios, we couldn’t help but dive in and explore the migration process. So, we took on the project and decided to upgrade our MuleSoft Certified Connector for IBM® Watson Visual Recognition, which is available for free on the Anypoint Exchange, to Mule 4. We were able learn more about Mule 4, the migration process, and generate an estimated time frame for future migration projects.


route (1).png

The Beginning

First off? Research.

How does one migrate a connector from Mule 3 to Mule 4 you ask? Well, we asked the same thing and looked into the available documentation.

MuleSoft’s website provides a guide for the migration from Mule 3 to Mule 4. However, this guide is  for Mule flow apps/APIs, and we needed a guide to migrate a connector created with the MuleSoft DevKit tool. Fortunately, we found some articles from Mariano Gonzalez‘s post where he explained everything clearly. Thanks, Mariano!

We also found and were playing with the DevKit Migration Tool (DMT), which is useful for migrating custom connector projects to the new Mule 4 SDK: https://docs.mulesoft.com/mule-sdk/v/1.1/dmt.

The issue was that this connector, like many of our connectors, has DataSense as a main feature. DataSense is totally reworked in Mule 4 / SDK. So, the migration tool failed big there. Also, there were other features that were updated and required manual fixes in the code generated by the migration tool.


network (1).png

Next Step: The Connector

The next step was to decide if a new project approach really made sense. With the help of Manik Magar’s tutorial and Mule's official page (which really helps you understand the basics), creating a new project was very straightforward.

After that, we had to port each Mule process to a new Mule operation. Here is the API for Mule:

https://watson-api-explorer.ng.bluemix.net/apis/visual-recognition-v3
 


hierarchy.png

It’s Not the Connector, It’s the Dependencies

The real problem? It’s not me, it’s you, you say?

Well, in this case it’s true. What we encountered here was that the real issue was the third party libraries. Why? Because we ran into new issues when we updated the IBM Visual Recognition from 3.8 to 5.5.

We had a lot of errors, so we refactored the whole project to make it work. Finally, we had to fix some problems with the imports in Anypoint, basically we had to import the the IBM® core dependency in order to make it work with the new version of  IBM® Watson Visual Recognition.
 


business-plan.png

Creating the Flow

In order to test the connector properly, we needed an API key. So, we created a new account in IBM cloud in "http://bluemix.ne" and created a free instance. This allowed us to test our Mule flows: retrieving a list of classifiers, detecting faces, and classifying images.

Unfortunately, we weren’t able to create a classifier. It appeared we had some issues creating a classifier because, for some reason, our IBM® instance already had 2 of 2 classifiers created and we didn’t see them with the custom list of classifiers. So, we decided to create a new classifier through the IBM® web page.


thinking (2).png

Conclusion

Overall, we were able to connect with the Wason services and use them with the new connector. The Mulesoft Certified Connector for IBM® Watson Visual Recognition migration allowed us to become familiar with the basics, get our hands dirty with the MuleSoft tools and our own creative solutions, and gave us additional know-how before we dive into our next connector migration. We can estimate the time needed for other connectors migrations depending on their level of complexity and customization needs (5-10 days plus certification time, if you were counting).  

This project also highlighted the need for everyone to understand the deeper consequences in regards to Mule message handling, DataSense and DataWeave, and how they have changed in Mule 4.