As an integration developer, I am a big fan of standardization and reusability, especially when working with more people on the same projects. Therefor, I find it unfortunate that Mulesoft does not offer the possibility to create a domain project for cloud-based projects. I’d like to use certain properties, flows, files or transformations in more than one project and recreating them in every single project can lead to problems when you need to update it (there is no bigger pain than to have to go through all of your projects when one single constant needs to be adapted). Creating a common utilities project is an elegant solution for this problem. I tried to create one a couple of years ago, when I was still a Mulesoft newbie and failed. I recently tried again and found it was much easier than I expected. Here’s how I did it.
Getting started
Obviously, the first thing you need to do is to setup your project. In your anypoint studio, create a new project with maven (I’ve used maven, but I suppose it will also work with other tooling), as you would do for any other regular project. When it’s created, open the generated pom.xml file. On the main level, there is a tag called packaging, which is by default set to ‘mule’. Change this to ‘jar’:
<packaging>jar</packaging>
As far as the setup goes, this is the most important part. When the project is built, it will now create a jar file instead of a deployable zip file. This jar can be used as a dependency in other projects.
You can now start creating all kinds of flows, but let’s start easy: create a simple sub-flow with just a simple logger in it, saying something like ‘hello from the common utils!’
Before we continue, a quick word on the naming of flows in your common-utils project. When you include them as a dependency in your other projects, these flows are treated as if they are part of your project. Since you can’t have multiple flows or subflows with the same name, you’ll have to make sure the flow names in your common-utils project are unique. I suggest using a prefix. As you can see in the screenshot, we chose to use CU_. Whenever you see prefixes like that or similar to it in the rest of this article, know it probably means this was done to ensure unique names.
Using the common utils
Now it’s time to create the jar. Build the project as you would do for any project. In my case that means running mvn clean install -U in my project folder. It will build the project and add the jar to my .m2 repository. That’s great, because I don’t have to release the project yet, just to test if this setup works. Next, add the jar as a dependency to the project you want to use it in. In my case, I’ll have to add this dependency to the pom.xml file of said project:
<dependency>
<groupId>org.hybrit.blogs</groupId>
<artifactId>pbg-common-utils</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
After saving and building, check the referenced libraries of your project and see that the jar has been added.
You’re almost good to go now. In order for your project to be able to use the flows of the common utils, you need to import it. Go to the Global elements and create a spring import (I usually do this in the Configuration XML). Add the following import:
<spring:beans>
<spring:import resource=”classpath:blog.xml”/>
</spring:beans>
blog.xml is the file where I created the CU_HelloWorld subflow in earlier
To test if you can really access the common utils flow, create a flow in your current project. Add some way to trigger it, like a flow reference. If you did it right, you can choose the flows you created in your common utils project as if they were part of the current project.
Let’s debug the project to see if it works.
Releasing
Now that you’ve verified that you can create a common utils-project and are able to use it, create all the flows that you want (more on that some other time). When you’re done, release the project as you would with any other normal project, using your favorite tools and repo’s. We use Jenkins to release it to Nexus. Afterwards, update the project you use the common utils in to use version 1.0.0 instead of 1.0.0-SNAPSHOT.
Finally, let’s quickly discuss the usage of a parent project. A lot of us use a parent pom to store information you use for all of your projects, such as dependencies, properties and builds. It saves you the trouble of having to add them for each of your projects individually and when you need to update something, you only need to update it in one place. But wait, isn’t the common utils project such a dependency you want to use over different projects? Can’t you just add it as a dependency to the parent pom? The answer is yes you can and you might want to do so. It has one very serious consequence though: you can’t use your parent in your common utils anymore. This makes sense of course, since you can’t have a parent and a dependency referencing each other. You can either reference the parent pom from your common utils project, or have your common utils project as a dependency in your parent pom. You have to choose for yourself which makes more sense for your particular situation. In my case, we wanted to be able to use the parent in the common utils project, so we have to include the dependency in all of our projects individually.
So, that’s it for setting up, using and releasing your common utilities project. Try it yourself and have some fun playing around with it. For example, have you considered adding common error handling to it? On another occasion, I’ll explain about that, together with using properties files and common dataweave functions.
Summary
This is how to set up and use your common utils project:
- Create a new project
- Set packaging to jar
- Create a flow with a unique name
- Build the cu project
- Include the cu project as a dependency in another project
- Add a spring import to the global elements
- Reference the flow
- Test and release