Neflexity

We’ve been using Mulesoft’s Mule ESB product since version 2 and consider it by far the best integration platform on the market. Mulesoft’s offering got better and more refined with time. This year we are going to see Mule version rebuild from ground up, making it a better, more scalable and more flexible solution, but will it be more usable? Like driving a 1000HP racecar on the street is not the most comfortable thing to do, not to mention the lack of utility. Our initial attempts to try new Mulesoft Anypoint Studio v7 at the beginning of 2018 failed miserably with numerous issues from installation to simply project creation. Ever since initial release, we’ve been very anxious to try new features of Mule v4.1.1 runtime and Anypoint Studio v7.1.2, which was just released at the end of March 2018.

You want it; you got it! (Latest Update)

Let’s just say I was pleasantly surprised when Mulesoft team, in charge of Mule 4, got in touch with me regarding issues outlined below and took their time to go over each item and explain why things are the way they are. I was even more surprised the team was open to suggestions regarding future enhancements (talk about community-driven approach 🙂 ).
So, let’s go over original issue list below (scroll down a bit) and provide an explanation.

1. We wanted ‘Frictionless Upgrades’ and we got them. In Mule 4, you can get new enhancements with little to no work on your part. Mule 4 comes with classloader isolation between your application, the runtime and connectors, so that any library changes that happen internally will not disrupt your applications. This features allows you to get connector enhancements and fixes without having to upgrade your runtime or upgrade your runtime without breaking compatibility with connectors and modules. This essential feature came at a cost of some resources excluded from dependencies, but the fixes are on the way!
2. Backslashes are not related to Windows users, surprise, rather a change that was necessary to extend Mule 4 capabilities and migration tool will handle this conversion for you!
3. Mule 4 reserves “vars” strictly for user variables, so forcing variable creation can possibly introduce a naming conflict, so we will have to get used to new syntax, but Studio enhancements are coming to make life a bit easier for developers.
4. Database connector does make things harder for less technical Mule developers, but upcoming Studio enhancements will make generation of required JSON payload easier.
5. The more I’m using Mule 4 the more I realize that storing all sensitive values in a separate properties file is just a better approach and easier to manage. Special “secure::” prefix to reference a property is necessary for Mule 4 in order to build additional logic on top of sensitive data. On another good note, I was able to find a temporary solution for visually encrypting and decrypting properties, that’s right, using same enterprise security plugin for UI that we had to install in Studio 6.  So, use the link below to install property editor as shown on the image below and you can use same property editor we had in Mule 3.9.0.
   

   Mule Enterprise security update 1.7.3

   https://docs.mulesoft.com/release-notes/anypoint-enterprise-security-release-notes

6. Import enhancements are coming and will support multiple files eventually, although I’m ok with specifying multiple imports as was the case with Spring import.
7. Best way to go with doc:id is to completely remove it and let Studio re-generate it. Having duplicate ids is not the best approach as per Mulesoft.

Below you will find a list of Mule 4 weirdness that we were able to pinpoint during implementation of a small POC.

1. Our biggest grief is replacement of Spring with homegrown solution, which still has classloading issues. For example, during our tests, Mule 4.1.1 had issues referencing property files within included JAR dependencies. This is something that Spring had working well for past 10+ years.
2. I understand that majority of offshore firms use Windows, but still, why would Mulesoft change flow names to have back slash???? This was absolutely unnecessary and requires additional work during application conversion.
3. URI parameters are not converted to variables anymore, which was very handy in RAML-based projects. Now, you have to do this instead:
   

   <set-variable value=”#[attributes.uriParams.id]” doc:name=”Set Variable id” variableName=”id”/>

4. Database connector enforces the use of input params and the syntax is a JSON payload, which requires more typing and more prone to errors! This worked much better with MEL expressions in Mule 3.x
5. Secure properties require you to encrypt property values from command line and if you want to use it, you have to use a different syntax, ex. ${secure::myprop.name}. I hope that secure property module will come with a separate Eclipse editor like we had in Mule 3.x
   

   java -jar secure-properties-tool.jar string encrypt Blowfish CBC YOUR_KEY YOUR_VALUE

6. Import and config properties DO NOT support comma separated lists, need to use multiple.
   

   <import file=”commons-file1.xml” doc:name=”Import” doc:id=”d32708cb-ce45-4c7b-8079-d76dd6b1c808″ /> <import file=”commons-file2.xml” doc:name=”Import” doc:id=”1cbc4d98-eeb6-44a8-9ff7-22f4c07a4eba” /> <import file=”commons-file3.xml” doc:name=”Import” doc:id=”1cbc4d98-eeb6-44a8-9ff7-22f4c07a4ebb” />

7. Also, when I copy-paste code, am I supposed to change these doc:id values to make them unique or what?