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

  5. Sharing Custom Configuration Fragments

Sharing Custom Configuration Fragments

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.

Using 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 will actually be used.

Pre-configured transformers

between flows within the same application

or

between applications

Some transformers, like the XSLT transformer, can require significant configuration, 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 to include it in your application. Finally, import the config file as follows.

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

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