Explained: Structuring Mule Applications

Mulesoft development foundations is a series of blogs that guides you through the Mulesoft development basics from the “how to make mule code structured” to “things need to consider before deploying for production”. The mulesoft training course would help you in learning how to organize the program structure while developing the mule application projects. Structuring Mule Applications

Structuring Mule Applications

This article will guide you through how to structure your project code of Mule in the best possible way. Even though Anypoint Studio creates a project to work with by default, whenever we create a new Mule project, there are always a few additional things we can perform to make things easier. The benefits of your mule coding structure include:

  • Because the structure of all Mule projects is the same. It’s simple to establish a CI/CD pipeline.
  • The applications will be easy to maintain as any engineer would be able to select problems.
  • People will be aware of where to discover the project details, therefore there would be less demand for Knowledge Transfer meetings.
  • The project has all of the necessary information to start up and run.

Structuring the Core —  ”src/main/mule”

Every Mule config XML files are stored in “src/main/mule”. Anypoint Studio’s auto-generated code provides a simple structure, but as applications become more complicated, arranging files into distinct folders will make a great deal of sense.    

Structuring common files – ” src/main/mule/common”

There should be two or many files in this folder. Here’s a list of them:

  • The “global.xml” file is designed to include all of a mule application’s configurations, including HTTP listener/request configs, property configs, and configs of external sys (AMQ or S3, etc.). There should be no flows in this file.
  • The “common.xml” file provides all flows which are similar to all of the different workstreams/APIs in project implementation. 
  • The “Error-handler.xml” file is liable for addressing global/common errors throughout the application.

Structuring files specific to the API – “src/main/mule/<API Name>-<version>”

There’s a possibility that a Mule application will have many APIs. Integrating small APIs is an excellent way to save money. When numerous APIs are combined OR if a large application is built, distinct APIs or functionalities must be structured in various folders.

You may also like How to Use OCR Software to Improve Business Performance

Here’s an example of organizing files in an application that combines HR and employee APIs:

Structuring Mule Applications

Each API file exists in a distinct folder, which has the file “api-name-router.xml” containing the router of Api-Kit & other files containing the API’s various business subjects in files that are dedicated.

Structuring Mule Applications

Structuring the resources — ”src/main/resources”

Structuring the properties – “src/main/resources/properties”

Folder for Properties:

This folder comprises all of your Mule application’s properties that are env-specific. These will be incorporated in an application by referencing the property file depending on env using ${mule.env}. A good example can be seen in this image. Separate files will be used for plain text and encrypted properties.

“${mule.env}-secure-properties.yaml” and “${mule.env}-properties.yaml” must be used to separate this.

There is a requirement for “common-property.yaml” as well that would retain properties that are shared between environments, such as HTTP port numbers, logger configuration, and so on. The configuration of HTTP listeners must be shared across all APIs.

It’s vital to remember that property names in an application with multi-api must follow the very same naming rules for both common and environment-specific properties. All attributes for a given API should begin with the name-version of API, for example:



All certificates must be preserved in the resources/cert directory for every environment. Certificates should be injected through CICD pipelines for improved control over their lifecycle.

Structuring Mule Applications

Structuring Dataweave files – “src/main/resources/dwl”

Folder of DWL:

The resources/dwl directory should include all the scripts of dataweave. More directories should be added to include specific files of dwl for various business APIs/use-cases.  All dwl functions which are common should be kept under “resources/dwl/common” so as to reuse, similarly to mule configuration XML files.

Structuring the Test — ”src/test”

Structuring Munit files – “src/test/munit”

The munit files structure “src/test/munit” must be the same as in the “src/main/mule”. It facilitates tests for business use-cases or individual APIs in the same Munit folders and configuration XML.

Sample payloads and Postman Collection – “src/test/resources”

All payloads samples used in the test must be in src/test/resources:

  • Munit testing
  • In the Transform message, you can create examples and metadata.
  • Any additional file-example

In addition to the payload samples, “src/test/resources” must definitely include a collection of postman per API that contains all of the potential API queries per env. Creating multiple folders in collection for each environment is a good practice. 

You may also like The Best Digital Signing Apps for iOS and Android

These all must be retained as: “test/resources/postman-collections/<api-name>-<version>/<api-name>-<version>.postman_collection.json

It assures that each new developer has a place to begin testing an application and hitting various endpoints in various contexts.

ReadMe File

The “readme.md” file should be included in the project core in addition to anything else. It should explain what the project is about, what APIs it includes, how to start, what runtime options to pass, and so on.


With this session, you now become aware of how to organize the various Mulesoft application files by aligning them with the proper file structure. To learn more on how to work with Mulesoft projects, you need to get this Mulesoft Online Training course that aids in upskilling your talent.