We often see the need to reuse a component configuration between 2 applications deployed to Mule. For example, let’s say you have two Mule applications deployed in your Mule server. The first one, called AppA, gets information from Salesforce and stores it in a database. The second AppB modifies your Salesforce campaign information. Both applications share the same Salesforce credentials, so what happens if those credentials change? (for example, because you are switching from the SFDC sandbox to the live instance) You need to modify both applications because you have your Salesforce cloud connector configuration duplicated.
Splitting Configuration Files
It is actually quite simple to extend a configuration from a parent mule-config file. You just need to follow these steps:
1) Create the parent mule config file (for example, salesforce-parent-config.xml), which in our case, would be something like this:
and put it into the MULE_HOME/apps directory.
2) Next, create your child application (for example, AppB) using the beans defined in your parent config as if they were part of the child configuration:
Be sure that in your MULE_HOME/apps/AppB directory you have a file called mule-deploy.properties with the following configuration:
Note, see the Mule Deployment Descriptor documentation for more information about this.
This will tell Mule that it first has to read the ./apps/salesforce-parent-config.xml file and then the mule-config.xml file of your AppB, so that the configuration defined in the parent file is usable from AppB. The good thing is that if salesforce-parent-config.xml file changes, then all the child applications (AppA, AppB) will be automatically redeployed in Mule, so you don’t need to change or stop your applications.
Can Apps Share Libraries Too?
Of course! You just need to drop the shared jar files into the MULE_HOME/lib/user directory and those jars will be shared by all the applications deployed in Mule. Mule also supports the notion of application domains that allows applications to be grouped and jars shared between apps in the same domain. See the documentation about class loading in Mule for more information.
