Category: Mule 4 Anypoint

Any senior developer is going to want to create a library of commonly used features that will be shared among MuleSoft applications. In Mule, we create a common, shared project that has reusable components and flows. Domain projects don’t allow reusable flows, so this is another great option.

Updated April 12, 2024

This can include many things, the most popular being:

• Global Error Handling
• Global Logging
• Common Business Logic Flows

This activity was completed using the following versions:

• Mule 4.2.2
• AnyPoint Studio 7.4.2
• Mule Mavin Plugin 3.3.5

I will show as much of the setup in AnyPoint studio UI as possible. We’ll only edit the files manually when necessary.

First, create a Mule project that you want to have your shared code in. I called my project “mule-common-flows”. If you commonly use a domain application, DO NOT use it for this project. This project will not run on it’s own, it will only be referenced by other projects that, in turn, can be domain based projects.

I added two Mule configuration files. One that will have Error Handlers, and another that will have a re-usable flow.

Once you’re happy with your re-usable components, we need to edit the POM.XML file. We need to add a “classifier” tag in the “org.mule.tools.mavin” plugin section like so:

        <plugin>
            <groupId>org.mule.tools.maven</groupId>
            <artifactId>mule-maven-plugin</artifactId>
            <version>${mule.maven.plugin.version}</version>
            <extensions>true</extensions>
            <configuration>
                <classifier>mule-plugin</classifier>
            </configuration>
        </plugin>

Then go to a command prompt and navigate to the source folder for this project and mvn clean command like so:

C:\Source\mule-common-flows>mvn clean package install

If you receive the message: “The packaging for this project did not assign a file to the build artifact”, then you may be using the mule maven plugin version 3.8.x or later, you’ll need to remove the package option, like so:

C:\Source\mule-common-flows>mvn clean install

You should receive a “BUILD SUCCESS” message. If you don’t, you’ll have to resolve whatever issues you have before continuing. This will build a JAR file and place it in the /target folder in the project.

Leave this project open in your Package Explorer, although you can close all the XML file tabs.

In the project in which you wish to reference the shared items, we have to manually edit the POM.XML file again. Add a section in the dependencies section like below:

    <dependency>
        <groupId>com.mycompany</groupId>
        <artifactId>mule-common-flows</artifactId>
        <version>1.0.0-SNAPSHOT</version>
        <classifier>mule-plugin</classifier>
    </dependency>

The dependency property values need to match the values in the POM.XML of the mule-common-flows project. The “classifier” property is additional.

Next, open one of the Mule Configuration Files in your project that is going to consume the mule-common-flows.

Click on the “Global Elements” tab.

Click on the “Create” button.

Navigate to Global Configurations – Import and click “OK”

DO NOT click on the ellipses to select a file. The file is already referenced in the JAR file of the mule-common-flows project. So you need to just manually enter the name of the configuration file. I’m going to add two, one for my global error handler and the other for the shared flows. Better to copy and paste the names to be sure. I put the names of the files in the Notes section too, so that they show up in the summary screen.

Your Global Configuration Elements should look something like the below. You can see how entering the names of the files in the notes is helpful.

Save all your changes.

Now to test them out. I’m going to setup my project to reference my new and shiny Global Error Handler. Click on “Create” again. Expand “Global Configuration” and click on “Configuration” and click “OK”.

Your Global Error Handler should now be in the drop down. If it’s not, then make sure you’ve saved everything. You can try closing and re-opening the project as we often need to do.

Click “OK” to save those changes.

Now, let’s go to the “Message Flow” tab. Drag a “Flow Reference” to the canvas if one doesn’t already exist.

Click on your “Flow name” drop down and you should now see our flow from the mule-common-flows project like highlighted below:

There you did it! Now go show off to all your colleagues.

References:

https://help.mulesoft.com/s/article/How-to-add-a-call-to-an-external-flow-in-Mule-4

Every development project needs a way to have certain values change when an application is moved from environment to environment. Many teams opt for environment variables on the server. I’m not a fan of these, because they are “hidden”. Only a server admin can see that they exist, and what their values are. MuleSoft, Mule 4 has a method for using Secure Properties in your apps, you may want to consider using these.

The main advantage of Secure Properties is that they are easily maintained in the Runtime Manager. This means that they are easy to administrate by whomever has rights to deploy applications. Hence, the values for each environment can be part of your roll-out documentation. If the property values are sensitive, i.e. passwords, then your documentation can state that the values are to be retrieved by other means, but still show where they should be set.

Alright then, enough with the back story, let’s get started!

First thing we’ll need to do is to setup a YAML file that has the properties we want to use in our app. We can easily add to this list over time as needs arise. For this example, I’m going to call the file secure-config.yaml, but feel free to name it as you see fit.

Let’s get started

1. Right click on your Mule project
2. Select “New” -> “File”
3. Navigate to your project and into the src\main\resources folder
4. Enter the file name you’d like with a .yaml extension
5. Click “Finish”

Open your new file and add your new properties, you can select to create them in a hierarchy, or not. As always, I recommend organizing your thoughts, as you don’t know how many properties you may eventually have. It could get difficult to find the one you want in the future if there are dozens.

Once this is saved, you need to declare the properties you’re using that you wish to set in the Runtime Manager. In order to do this, you’ll need to edit your mule-artifact.json file in the root of your project. We’ll be adding a new line to declare the properties:

Make sure to add a comma before your new line to keep the integrity of the properties in this file. Notice how the property that I had created in the config-secure.yaml file under the “defaultAppSettings” is depicted here with a period. This is the same way you’ll use it in the Runtime Manager and any documentation that you create.

After saving your changes to the mule-artifact.json file, there is one more step. We need to add this new config-secure.yaml file as a known configuration file for your project.

1. With any of your flow files open from your “src/main/mule” folder, click on the “Global Elements” tab.
2. Click on “Create”
3. Now Click on “Global Configurations” -> “Configuration properties”
4. Click “OK”
5. In the “File” box, select your new config-secure.yaml file. You can use the ellipses to make sure you have the path correct.
6. Click “OK”
7. Save all your changes

NOTE: Make sure and save all your changes in Anypoint Studio.

Now you can use these properties as you would any other properties in a .yaml file.

For this example, I have a simple application that pulls my two config settings and saves them to variables. I then display the variables as JSON.

Deploying an application is beyond the scope of this post, so I’ll assume you know how to do that.

After Deploying Anypoint Manager

After deploying, I run my application and view the following response message in my browser:

Now, back in Anypoint Manager – Runtime Manager, I hover over the name of my application and click on the little leaping arrow:

Select “Manage Application” on the right side pane.

On this screen, look for the properties tab and click it.

Here is where we can change the values of the properties we created in the config.secure.yaml file. By also adding them to the mule-artifact.json file, we have exposed them to this tab. So I’ll change the two values for my two sample properties, like so:

There are three things I want to mention about this screen.

1. Make sure you click the save button after adding each property. If you add several and click save, I’ve had it wipe out all but the one I clicked.
2. Note the key is exactly the same as the way that I access them from within my Mule application. Make sure and double check the names of your properties.
3. You MUST click “Redeploy Application” for any of these change to not only take effect, but to be saved at all.

Click on “Redeploy Application”. Once it is started. I’ll refresh the application in my browser and see what we have:

So now I include the settings for these properties in my deployment document and every time the application is run on a server, it picks up the values that are appropriate for that environment.

Happy Muling, and remember, don’t make an ass of yourself.