MuleSoft’s DataWeave, which is now the main expression language in Mule 4 beta, is a powerful technology that can efficiently transform complex structured data between popular data formats, including JSON, XML, CSV, and Java objects. I’m a courseware developer and trainer at MuleSoft, and I’ve been spending a lot of time learning about DataWeave recently.

Update, April 2018

I previously posted the below blog on how to reuse DataWeave code in a Mule flow using the readUrl() function. In the blog, I stated that this was a temporary workaround (or hack) until DataWeave 2 arrived.

With DataWeave 2.0, that support has now been added to allow you to import and export complete DataWeave Modules. This is only supported in the new Mule 4 runtimes, which is the only Mule runtime available in Anypoint Platform Design Center’s flow designer. Here is the product documentation for this new feature.

This is now the preferred way to refactor and reuse your DataWeave code. The main issue with using readUrl() is that it reads the DataWeave code from the file system every time the flow reaches the readUrl() call. With DataWeave Modules, the DataWeave functions are loaded into application memory.

You can still use readUrl() for it’s original purpose, to read files into your DataWeave code, either from the file system, or from a remote URL.

In the latest DataWeave 1.x version – included in the Mule runtime v3.8 –there is limited support for reusing DataWeave functions and variables between Transform Message components (the component that applies DataWeave code).

In this post, you’ll learn a workaround that enables you to separate out reusable DataWeave code, and then reuse that code between multiple Transform Message components and flows––including flows in separate applications and MUnit flows.

Create a Mule project with reusable DataWeave library files

The example Mule project used in this post is available in this GitHub repository. You can import this project into the latest Anypoint Studio to follow along with this post. Alternatively, you can create a new Mule project in Anypoint Studio and copy the examples from this blog post.

Below is a Mule project in Anypoint Studio. It has a folder named dw added to src/main/resources, with a file named myLib.wev. When we export this Mule project as a deployable archive file, any file in src/main/resources will be automatically added to the project’s classes folder; so it will be in the classpath when the Mule application is deployed to Mule Runtime. In this sample project, the HTTP listener is listening for requests on port 8081.

//Provide external names for variables and functions defined in the header

{

exchangeRate:exchangeRateFromUSDToBritishPounds,

convertPrice:convertPriceFromUSDToBritishPounds,

//Use an anonymous lambda to define the function

formatString:(aString,formatter)->formatter(aString)

}

Read in and use an external DataWeave file

Now ,let us read in this external DataWeave file and use it in a Transform Message component. The first step is to use the new readUrl function to read in the DataWeave function from the classpath. Define a variable myLib as a reference to myLib.wev the DataWeave file.

1

2

3

4

5

%dw1.0

%outputapplication/json

%varmyLib=readUrl("classpath://dw/myLib.wev")

In this example we are embedding the DataWeave library file inside the project, so we give the URL relative to the classpath dw/myLib.wev. If you are deploying into a customer-hosted on-prem Mule Runtime, you could also store your DataWeave libraries in a common external location that you add to Mule Runtime’s classpath.

Note that this is a similar technique to the way you can store Mule application properties files or other external libraries (such as JAR files) in an external location. You can learn more about this technique in our Anypoint Platform Operations: Customer-Hosted Runtimes, product documentation, or Tanuki Java Service Wrapper documentation. Depending on the scope of your project, any external assets, including reusable DataWeave files, need to co-exist, be versioned, and evolve according to your project lifecycle’s organization, policies, management systems, repositories, and other tools (such as GIT, Maven, Nexus, and Jenkins). You can learn more about how MuleSoft customers commonly manage and automate MuleSoft project lifecycles (including implementing continuous integration pipelines) in our MuleSoft Development: Advanced training class.

In Anypoint Studio, the file is stored in src/main/resources, but in the deployable archive, all the files from the src/main/resources folder are moved into the classes folder.

Here is a complete Transform Message component in the convertPrice flow:

You can preview example data transformations using the Preview pane in the Transform Message component editor. In the Transform Message component, in the left-side Input pane, right click on Inbound Properties > http.query.params, then select Edit Sample Data.

Set an example price:

1

2

3

4

5

6

7

8

%dw1.0

%outputapplication/java

---

{

price:600

}

In the right-side Output pane, select the Preview button, which opens the Preview pane. In the Preview pane, you should see the result of the body expression.

Change the price from 600 to 500 and verify that the output in the Preview pane changes as well. This shows you that you can preview live changes to DataWeave code, even when you are reading in external DataWeave files.

Deploy and test the application

Deploy the reuseDataWeaveCode project to Mule Runtime. For example, here I am deploying the project to an Anypoint Platform account from Anypoint Studio.

In this example, I deployed the application to a public Anypoint Platform URL.

After the application deploys, open a web client (you can use a web browser), and make a GET request to the HTTP listener. If you deployed to Mule Runtime on your local machine, the URL is . For my CloudHub deployment, I’ll make requests from a web client to http://reuse-dataweave-code.cloudhub.io/?price=700 . Simply click this URL now to try it out.

My web browser has a JSON parser extension and shows this response:

Conclusion

As you build up more complex DataWeave transformation for your projects, you’ll want to reuse some of your transformation logic. Today, you can do this using the readUrl() function. Please let us know what you think about this feature, and if there are any additional modularities you’d like to see in future releases.

2 Responses to “How to Reuse DataWeave Code”

The new Mule 4.0 RC candidate and Studio 7 RC candidate include new DataWeave 2 reusable modules. This is a much better and more performant way to refactor and reuse DataWeave code compared to using readUrl(). As soon as you transition to DataWeave 2.x, be sure to use reusable Modules instead of readUrl()!

We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used and to tailor advertising. You can read more and make your cookie choices here. By continuing to use this site you are giving us your consent to do this.

MuleSoft provides the most widely used integration platform for connecting any application, data source or API, whether in the cloud or on-premises. With Anypoint Platform®, MuleSoft delivers a complete integration experience built on proven open source technology, eliminating the pain and cost of point-to-point integration. Anypoint Platform includes CloudHub™ iPaaS, Mule ESB™, and a unified solution for API management™, design and publishing.