.png){kind=small}
In computer programming, there are different ways to reach the same solution. However, not all ways are equally efficient or the best for a specific problem. As developers, our job is not just to make things work; we also need to write code in a way that makes it easy for other developers to add more features. That's what we're concentrating on today in this blog.
In this blog, you'll discover some commonly used best practices followed by MuleSoft developers. These practices are designed to save you time during development and ensure the security of your Mule applications by avoiding potential vulnerabilities.
# Always create a separate Global configuration file and keep all Global elements in that file.
Global Elements (or Global Configuration Elements) are those configurations that you can see under the Global Elements view in Anypoint Studio when you’re developing a Mule application. For example, the configuration for an HTTP Listener is shown below.
You can also spot them from the XML view because they are located outside of a <flow> tag and are normally located at the top of the file.
Global elements in a Mule application have visibility across the entire project, extending beyond their individual Mule configuration files. The challenge arises when a project consists of multiple files, each containing global elements that can be referenced from any Mule configuration file. This decentralized structure makes it difficult to easily locate and manage these elements within the overall project.
The best way to avoid this issue is to have just one dedicated Mule configuration file that contains all the global elements. This way, you won’t have to jump from file to file to try to find a specific element. You can simply open this one file that contains all of them.
To simplify, people often name this consolidated file as global.xml or config.xml for easy recognition. If your project has global elements scattered across different files, a simple solution is to cut and paste those elements into this new file. This makes it easier to manage and organize global elements within your project.
Now, every time you create a new global element, you just have to do it from the global.xml file and reference it from any other Mule configuration file needed.
#How to create that Global.xml file?
Step 1: Right-click on src/main/mule under your project name in the Package Explorer.
Step 2: Go to New > Mule Configuration file.
Step 3: Create the file by giving it a name (like Global or config) and click finish.
#File created
# Always create a properties file per environment.
If you’re working on a big project, you will inevitably have to work in different environments. For example, local, dev, qa, prod, and so on. At least, you will have a local environment (from your local computer) and a dev environment (from the cloud service). Because of this, there are different configuration properties needed for each environment, such as a different database URL for the qa and prod environment.
To solve this issue without having to change anything in the code, it's best practice to create a separate properties file for each one of your environments. Let’s see an example of the HTTP Listener config we just saw in the previous point. Our current configuration looks like the following.
We don’t want to keep the host and port as hardcoded values because these may change depending on the environment. Let’s create two files under src/main/resources:
# For creating these files, Right-click on the src/main/resources folder and select New > File.
Now let’s add the following on each file.
http.host=0.0.0.0
http.port=8081
After that, you will have to change the hardcoded values from the HTTP Listener config to reference these new properties using the syntax ${property}. Like so:
Finally, add the following configurations to the global.xml file, so we can correctly reference these new properties files depending on the environment.
In your global.xml file, switch to the Global Elements view. Click on Create to add a new global element. Search for Configuration properties. Select the element and click OK.
Because we’re not using static properties files, we need to be able to switch between files depending on the environment. Remember that the ${ } syntax is used to reference properties. Let’s add the following properties file:
${env}.properties
Next, we still need to add the env property that we just referenced in the previous step. So, again click Create and select Global Property. The name should be env and the value local.
Click OK and save all files.
Once all this configuration is in place, you can modify the property values directly from the properties files. For example, you could change the http.port to be 8082 in dev but leave the 8081 for local.
You can continue adding more properties to these files and reference them from other connectors or global elements to avoid hardcoding values directly in the code and change them accordingly per environment.
Comentarios