Managing Dynamic Application Properties in MuleSoft for CloudHub Applications

What Are Application Properties?

Application properties refer to a set of key-value pairs that are used to configure an application. These properties can be used to customize the behavior of the application, such as setting the database connection details, enabling or disabling certain features, and defining the location of resources.

Why Change Them?

The need to change application properties at runtime arises when an application needs to be able to adapt to different environments or configurations. For example, an application that is deployed in a test environment may need to use a different database or a different set of credentials than it does in a production environment. Changing the application properties at runtime allows the application to switch between these different configurations without the need to rebuild or redeploy the application.

Another reason to change application properties at runtime is to allow for dynamic updates to the application without the need to rebuild or redeploy it. This can be useful for making changes to an application on the fly, such as enabling or disabling certain features, or changing the behavior of the application in response to user input or other external factors.

Overall, the ability to change application properties at runtime is an important aspect of software engineering, as it allows applications to be flexible and adaptable to different environments and changing requirements.

From the Context of MuleSoft

We have seen what application properties are and the reasons for changing them in runtime. Now let's see this in the context of Mule!

MuleSoft recommends using environment-specific property files to hold the application properties. These property files are part of the deployable artifact and get deployed into the server. After the application is deployed, it is not possible to change the application properties without releasing the latest version. 

This creates a bit of inflexibility in environments where the application properties change often. So, to address this, we can store the application properties in a data store like a database and read from it. This avoids the need of rebuild and redeployments every time a property gets changed. 

In order to increase the performance, the properties can be cached in the Mule application, so it doesn’t have to read from the database for every run. However, this cache needs to be updated every time, a property is updated in the database.

Sequence of Events

1. Application properties updated via Cache API
2. Cache API updated the database record of the properties.
3. Cache API updated the object store of the Mule application. This can be done via Object Store API.
4. If the update of the object store is successful, the record is successfully committed, or else it will be rolled back. Based on the result, either a success/error return code is sent back to the user indicating the status of the update. 

In the above scenario, "MuleSoft application" has the need to change the properties often. So, we build "Caching API" to enable dynamically changing the properties. With a single Caching API, you can enable the dynamic change of properties for all applications in that environment. 

With the above approach, the Mule application always keeps a copy of the application properties in its local cache object store. Whenever a property is updated, Cache API ensures that the application cache is updated with the latest copy.  

Pros

Using this way, the application properties can be changed dynamically without the need of redeploying the application every time a property is changed. 

Points of Attention

While this approach is quite handy, careful consideration needs to be given to keep a track of the application properties versioning. If we keep changing properties directly in the database without keeping their version history, it is hard to track back if we need to go back to an earlier version.

Recommendation: You can keep an archival table (SQL)/collection (NoSQL) to store the history. 

Every time you change a property in the database, a copy of the application properties can be put into the archival table, so the history can be maintained. Using database triggers, this can be made automatic.

Use this approach for application properties that don’t need an application restart to get into effect. Otherwise, an extra step has to be added to the process to restart after every update.

How-Tos

• It is preferred to use a NoSQL database for keeping a copy of application properties. It is due to the fact that each application has its own set of properties so they don't necessarily match with other applications' properties. It's simple to use a NoSQL database as it doesn't need a schema.
• In case you can only use an SQL database, you need to use a BLOB datatype to store application properties as they differ per application. 

{
  "application": "oms-sys-api",
  "properties": [
    {
      "name": "host",
      "value": "localhost"
    },
    {
      "name": "port",
      "value": "9999"
    },
    {
      "name": "username",
      "value": "admin"
    },
    {
      "name": "password",
      "value": "kdlfj$5kdlfj*"
    }
  ]
}

• To update the object store cache in CloudHub, you need to use the Object Store v2 API.