Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.8)
  3. Reference
  4. Team Development with Mule

  5. Sharing Custom Configuration Fragments

Sharing Custom Configuration Fragments

Mule runtime engine version 3.8 reached its End of Life on November 16, 2021. For more information, contact your Customer Success Manager to determine how to migrate to the latest Mule version.

Thanks to its element naming and referencing strategy, the Mule configuration mechanism supports re-using fragments of applications within teams. This is very convenient for sharing complex, repetitive, or critical bits of configuration.

The following types of configuration fragments can be shared:

Item Can be shared…​ Remarks

Connector configurations

Between applications

A connector that needs a complex configuration, for example with specific transport level details, is a great candidate for re-use.

Endpoint definitions

Between applications

Defining global endpoints facilitates testing but also promotes re-use as they become sharable.

Flows

Between applications

It can make sense for a service to exist in several Mule applications. In that case, sharing a flow is the best way to go. If this flow is configured to rely on global endpoints, the application using this flow retains full control on what protocol is actually used.

Pre-configured transformers

Between flows within the same application

or

Between applications

Some transformers such as the XSLT transformer require significant configuration, thus making sharing them more desirable.

Subflows

Between flows within the same application

or

Between applications

Subflows are chains of message processors that are worth re-using (example below)

Let’s take a look at an XML configuration file containing a subflow that defines a standard chain of transformers we want to share with all our applications.

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="
          http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd">

  <sub-flow name="DefaultTransformers">
    <append-string-transformer message=">>" />
    <base64-encoder-transformer />
  </sub-flow>
</mule>

Then, when we want to run a message through that chain of transformers, we call that subflow using a flow-ref element. This flow-ref can be in a different application or in a different flow file within the same application.

<flow name="FlowUsingSubflow">
  ...
  <log-component />
  <flow-ref name="DefaultTransformers" />
  ...
</flow>

If this flow-ref is in the same application, no further configuration is needed to call the subflow. However, if this flow-ref is in a different application than the subflow that it calls, you need to first package the shared config file containing the subflow in a JAR file. Then, use Maven’s dependency mechanism described in Sharing Custom Code to include it in your application. Finally, import the config file as follows.

<spring:beans>
  <spring:import resource="classpath:myCommonFlow.xml"/>
</spring:beans>

With this configuration in place, you can call the "DefaultTransformers" subflow from your application.

Specify the Classpath when doing a Spring import.