FlexDeploy has a new Mule Plugin that simplifies the build and deploy process. Rama wrote a great blog (https://flexagon.harbordev.co/2017/04/flexdeploy-brings-devops-to-mule-integrations/) overviewing all the capabilities FlexDeploy and the Mule Plugin can provide.

I am going to focus on how FlexDeploy simplifies managing your Mule properties.

Typical Approach to Managing Mule properties

To enable your deployment across environments it is recommended by Mule that you do the following (from the Mule User Guide 3.8):

You can configure your Mule application to facilitate deployment to one of many different environments, both on-premises and in the cloud. To do so, you must complete the following macro steps:
1. In your application, create a properties file for each environment.
2. Configure a property placeholder in your application to look for the deployment environment upon launch.
3. Configure an environment variable to point to a specific environment during application deployment.

This approach can be challenging, because the security team may not want you to check property files into you SCM with production  user ids and passwords for connecting to the various systems.  The production property file will also be deployed to your development environment.

There are alternative approaches, but each come with their own issues.

FlexDeploy Managing Properties

FlexDeploy allows you to manage your Mule properties using FlexDeploy’s Property Management UI.  The Mule plugin will use the values you configure for each environment and generate a mule property file specific to the environment you are deploying to for your application to use. Let’s see how this works!

Create the properties on your Workflow

To create properties that can be configured in FlexDeploy, we add them to the FlexDeploy deploy workflow. Below we have created 2 properties (MULE_DB_USERNAME, MULE_DB_PASSWORD). FlexDeploy knows  a Mule property will be placed in the mule property file because we prefix the property with MULE_. Notice that the DB_PASSWORD property is set to ecrypted = yes. This ensures the password is not visible on the property screens within FlexDeploy.

Note the Display Names, these will be used when we set the properties on the property management screens in the next session.

Indicate the Name of your property File

On the project property file page, we configure the mule property file name for the file that will be generated.  If you would like to be able to edit the properties in Anypoint Platform, be sure to name the property file /mule-app.properties.

Set your Environment Specific Properties

You can set the value for these properties for each environment.  Below we select the DEV01 Environment for the MULE instance to edit the properties for that environment but clicking the highlighted link.

On the Environment Instance page, we can set the values of these 2 properties for the DB UserName and DB Password.  These values will apply to the DEV01 environment.  Note that the DB Password does not display, instead you see ******.  You can manipulate these properties for each environment.

Deploy Your application

Now you can deploy your application and we will see what the properties look like on the server.

Handling Secure Properties

In AnyPoint Platform, you can update your properties.  When you first open the property page, it is empty.  You can enter the properties if you want to change them, for instance maybe the password changes regularly.  Notice that the DB_PASSWORD property display as ****.  This is the result of using an encrypted property in FlexDeploy, which set the secure.properties=DB_PASSWORD.

Summary

So if you are looking for a Build/Deploy tool that can help manage your Mule properties, take a look at FlexDeploy.  There is even a free Community Edition to make the decision easier.

Greg Draheim

I am a Principal Architect with Flexagon focused on providing DevOps and CD solutions for microservices. Over the past 25 years, I have architected and implemented complex integration systems and recognize the value of automating both testing and deployment. I have also leveraged my integration expertise to assist in the design and implementation of FlexDeploy's integration plugins.

More posts by Greg Draheim
    

2 Comments

  • Junaid says:

    Hi Greg,
    Thank you for update from now onward I start to use MuleSoft in my training practice. Thank you for explaining each step-in screen shots. I use blogs for my easy reference which were quite useful to get started with.
    I am an Oracle SOA developer, I am new to MuleSoft, can you plz advise me how to learn and any documentation.
    Can you please explain difference between MuleSoft with oracle fusion middleware?
    According to MuleSoft tutorials I am working on file adapter, my use case is read file from one location and write into another location can you please explain how can I approach this use case in MuleSoft?
    I recommend Videos Courses from MuleSoft Training on Mac and Windows.
    I want to learn MuleSoft ESB, I am not a java resource, weather I am eligible to learn lot required to learn Java also.
    As a developer facing this kind of variability, your goal is to produce a single Mule application for all your environments and to externalize all the environment-specific configuration parameters. This is the key to reproducible deployments.
    Please guide me and how the future market of the Mule looks like?
    Anyways great write up, your efforts are much appreciated.

    Muchas Gracias,
    Junaid

  • shanjames says:

    This is Very useful information. Thank you for publishing this. I can understand this easily.

Leave a Reply

Your email address will not be published. Required fields are marked *