<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.mulesoft.org/schema/mule/core"
xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd">
<import file="global-configurations.xml"/>
<import file="admin-config.xml"/>
<import file="audit-flows.xml"/>
</mule>
Modularize Configuration Files
Standard Support for Mule 4.1 ended on November 2, 2020, and this version of Mule reached its End of Life on November 2, 2022, when Extended Support ended. Deployments of new applications to CloudHub that use this version of Mule are no longer allowed. Only in-place updates to applications are permitted. MuleSoft recommends that you upgrade to the latest version of Mule 4 that is in Standard Support so that your applications run with the latest fixes and security enhancements. |
Though it might seem convenient to keep your Mule configurations in one file, a very large XML file quickly becomes unmanageable. This is why MuleSoft recommends that you split monolithic configurations into several files, and leverage Mule’s capacity to load multiple configuration files at application start-up time. Splitting configurations into multiple files encourages reuse across teams.
Mule offers two options for loading multiple 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’s common to use both approaches simultaneously.
Because configuration files are loaded in the same context, you must use unique names for the configuration elements. Mule will not load an application if its configuration files have name conflicts.
Here are some suggested ways to determine where to split configuration elements into separate files and which elements to keep together:
-
Business domains usually form a natural border that you can use to separate configuration elements.
-
Keep together elements that have been changed for similar reasons. This reduces the risk of impacting unrelated aspects of your application.
-
Technical elements, such as administrative components, security, and external system configurations determine good separation lines.
-
Separate a side-by-side connector configuration to facilitate functional testing. (This suggestion does not apply to environment-specific connector configurations, which use properties files.)
-
Consider reuse across teams and projects when you separate configuration elements.
By default, Mule treats all XML configuration files as configurations when an application is packaged and loaded in the side-by-side fashion. |
Imported configuration files
Mule has a special import
configuration component for importing configuration files into
each other. This component takes a file
parameter, which contains
the reference to the desired configuration file.
The following example shows a main configuration file that imports three other
configuration elements: global-configurations.xml
, admin-config.xml
, and audit-flows.xml
The import mechanism requires that the XML files are in the classpath. |