DEV Community

Cover image for Property file handling in Mule Application
anilkumarganna
anilkumarganna

Posted on

Property file handling in Mule Application

make life easier at all times. As for Mule, there is a nice and simple set of features to load environment-based resources. Typically, in the environment where the Mule application is being implemented, a property file is used but this includes creating several property files, one for each environment. For example, Dev, QA, SIT, and Prod. You will find a thorough guide to the method here.
Although this solution is easy to implement, it poses a challenge in that the code embeds all the configuration properties. Someone who has access to the code will be able to control all the development processes which is a condition you would really want to get into. The IT department would never send out manufacturing certificates for the Mule applications of most companies.
CI / CD best practices suggest using different properties to create a single deployable artifact that can run in all environments (dev-prod). To incorporate anything like this, an external source system such as a simple file server, SFTP, Server, or API would need to be retrieved.
In this article, you will see how Mule 4 has changed the process for managing property data. Let us cover primarily through this article.
● Newly incorporated improvements and how to deal with those improvements.
● Various proprietary hiding mechanisms in Mule 4
Properties in Mule

● You can replace Mule3's mule-deploy.properties with mule-artifact.json. Mule-artifact.json will be updated automatically when a new Mule flow is created.
● Then you can newly introduce Mule application descriptor the file mule-artificat.json. It will control all program-specific settings, Mule version, and class loader setup.
● The Mule 3 mule-config.properties file was replaced with the.yaml configuration file.
● Inputs of Mule 3's mule-app.properties have been migrated to Run Configuration-> Argument section at any point. These properties can also be configured from the runtime manager console under the Cloud hub Properties section. Image titleAdding properties ConsoleImage title runtime manager.

● Now developers will only have to keep a single file to manage program, deployment and Mule environment specific values that are not required to be part of code.
● More reliable mechanism to protect setup properties
● New feature for secure hiding of assets associated with Mule application
Configure Mule 4.X System Properties
● Build a directory with the name config in the project directory /src / main / resources.
● Build a configuration file within the newly formed configuration folder with the name configuration.yaml.
● The following screen will detail what and how the approach for property placeholders has been changed by Mule4.

Read yaml to customize the Mule Flow.
Select "Global Feature" in Mule flow, click the Create button, and select the build.yaml configuration file in step-2.
Placed holder XML configuration would look like as follows
< Doc: name="Configuration Property "doc: id="84048bfe-e690-4b64-9760-76afeb6c7860" file="config / configuration.yaml"/ >
The global HTTP listener configuration XML configuration for Mule4 in Studio 7 should appear as follows.

< http: listener = "${http.host}" port="${http.port}"/ >
< /http: konfig-listener >
To check the creation of a basic HTTP listener flow with the entries above. Place the logger to the console which prints the values.
The value of http.host will be selected from the YAML file and printed on the console after running the program.
Org.mule.runtime.core.internal.processor. LoggerMessageProcessor: > > Property Reading Values = 0.0.0.
Hiding proprietary software
Mule4 has introduced a new provision by Runtime Manager to hide the value for the property file. CloudHub supports secure hiding of Mule application properties where the name of a property is visible in the console but no user can access or retrieve the value.
Hiding System Assets via Console Configuration Manager
● Log in to the Console for Runtime Administrator
● Click on Manage Password for deployed Mule application and go to the Property tab as shown in the picture description below.
● To hide the property value, as highlighted, check the Hide values button. Enter the value and key, and click Save.
● For example, if Key = loginid and value = myloginid then hide the value specified for Key after clicking on Hide Values.
● Make sure to Redeploy Password after attaching the program from the console.
● When property values are removed from the console as hidden, their values are neither visible in the console nor transferred between the console and the server CloudHub.
Hiding User Property by configuring a user
Safely concealed Mule application properties are functionality currently only available for setting Mule applications that are deployed to CloudHub staff via the Runtime Manager UI. For Mule applications that you deploy by some other deployment technique, using protected placeholder property files that are bundled with your client zip file.
To mask Mule application property from the device configuration
Identify the property you need to cover when you deploy the Mule application to CloudHub. For example from the configuration.yaml file (shown below), I want to hide password and account while deploying my Mule application to the CloudHub.
Defined property names will be identified as a comma separate array within the mule-artifacto.json file. Image title of the Mule application as the value of the secureProperties key.
Deploy onto CloudHub Mule application. Enter Mule application property as shown in the screen below during deployment

Tap on App deploy

Mind now, as we generated two properties viz. Password and accountno hidden under mule-artifact.json, those properties should not be visible once the CloudHub Mule application has been deployed.
Once you have deployed the program, go to Manage server-> properties. No display.
It will be granted to all properties listed under secureProperties series.
Hidden properties
After committing the values and uploading the query, the securely hidden properties are never displayed on the console, nor sent and received between the console and the CloudHub server. When installed, there is no way to retrieve the house. However with a new value it can be overwritten. So, if a value needs to be modified, type a new value into the field, as shown below.
Copying Safely Hidden Mule application Properties between Sandboxes Do not copy securely hidden Mule application property values into the new environment when transferring Mule applications between sandboxes. The property name will be copied for all securely hidden Mule application properties but the value will be left blank.
Build stable, global configuration property
You can use Global Setup to build Safe Properties Configurations.
Provide location of the Properties File, Key (can be used to encrypt and decrypt the text), Algorithm (can be Blowfish), and CBC mode.
MuleSoft Components Control Safe Assets
You can access protected property in connector, DataWeave etc.
Then you can use the ${secure::propertyName} to access the property.

Backed up algorithms
● AES (default), Blowfish, Aes, RC2, RCA, and DESede.
● You can only use the following algorithms if you configure a Java Cryptography Extension (JCE) Provider that adds support to them:
● CAST5, CAST6, Noekeon, Rijndael, SEED, Serpent, Skipjack, TEA, Twofish, XTEA, RC5, and RC6.
Modes support
● CBC (Standard),
● CFB,
● ECB, and
● OFB.
Good practices
For each environment, it's recommended to keep separate properties file (e.g. appName-dev.yaml, appName-test.yaml, appName-prod.yaml).
Instead of a.properties file it is recommended to use a.yaml file.
Declaring a global property for the ecosystem is suggested (e.g., mule.env).
Do not modify the property of mule.env to prod or check but then send as an argument in the maven command of the CI / CD pipeline.
Mvn -DmuleDeploy -Dmule.env = prod deploy
Before you save them in the property register, all sensitive and confidential data such as passwords and keys need to be encrypted.
Hold all relations in global.xml, and other properties.
Now you know how to encrypt the confidential and sensitive data before saving it to Mule Properties Data.

Conclusion
I hope you reach to a conclusion about property handling in MuleSoft. You can learn more through MuleSoft online training.

Top comments (0)