Modularizing Your Configuration Files for Team Development
| Mule Runtime Engine versions 3.5, 3.6, and 3.7 reached End of Life on or before January 25, 2020. For more information, contact your Customer Success Manager to determine how you can migrate to the latest Mule version. |
Though it may seem convenient to keep all your Mule configuration in one place, the reality is that a gigantic XML file quickly becomes unmanageable. This is why it is recommended to split monolithic configurations into several files and leverage Mule’s capacity to load multiple configuration files at application start-up time. Moreover, splitting configurations into multiple fragments encourages re-use across teams.
Mule offers two options for loading several configuration files:
-
side-by-side: provide a list of independent configuration files to load,
-
imported: have one configuration file import several others, which in-turn can import other files.
In practice, it is common to use both approaches simultaneously.
Don’t forget that all the configuration files end up loaded in the same context; therefore you should be careful and use unique names for all your configuration elements. Mule will refuse to load an application whose configuration files contain name conflicts.
How can you determine what constitutes good separation lines between configuration fragments? Here are a few rules of thumb:
-
Business domains usually form a natural border that can be used to separate configuration elements
-
Keeping together elements that have similar reasons for change reduces the risk of impacting unrelated aspects of your application
-
Technical aspects, like administrative components, security or Spring beans configuration, define good lines of demarcation
-
Extracting a side-by-side transport configuration (connectors and endpoints) facilitates functional testing (discussed in section 3). Note that it is not intended to take care of environment specific transport configuration, which is dealt with properties files (discussed later on)
-
Last but not least, re-use across teams and projects (also discussed later on)
Imported configuration files
Mule relies on Spring XML configuration for importing configuration files into each other.
Here is the main configuration file illustrated above, which takes care of importing the three other configuration elements:
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:spring="http://www.springframework.org/schema/beans"
xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/core
http://www.mulesoft.org/schema/mule/core/3.6/mule.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-current.xsd">
<spring:beans>
<spring:import resource="domain-A-config.xml" />
<spring:import resource="domain-B-config.xml" />
<spring:import resource="admin-config.xml" />
</spring:beans>
</mule>| The import mechanism needs the XML files to be in the classpath; typically this is done with a jar-file which contains the XML files - included via a Maven-dependency. It’s a best practice to version-control shared flow-file JARs, and run proper SDLC controls. |
|
Known Issue: Note that although properly defined flows that were imported do function at runtime, flow-refs to any imported flows currently show as missing-flows in Anypoint Studio, ignore this error:
|