Directory Image
This website uses cookies to improve user experience. By using our website you consent to all cookies in accordance with our Privacy Policy.

Dataweave in Mule expression language

Author: Rajesh Cynix
by Rajesh Cynix
Posted: Mar 01, 2021

The implementation of Data Weave as our main speech-language is one of the big improvements in Mule 4. Although this will sound like a dramatic move, I will discuss some of the reasoning behind our decision, and why it is a big leap forward. I will also share a few explanations and answer a question that is sure to be on the minds of many readers.

Why We Pick Dataweave for Mule?

Let us begin with a case. I wanted to build a Slack app a few weeks ago to review the status of our experiments on Jenkins. This meant that to build a customized experience for our squad, I had to combine Slack and Jenkins APIs- just what MuleSoft is all about. I decided to begin developing the app after reading some docs on each API.

First, to receive Slack commands, I used an HTTP listener and a selection router that determines which action to take depending on the input; in this case, I either get the status.

Then, to retrieve the test data from Jenkins, I generated my key logic, returning XML data that I converted to JSON.

Quite fast

MEL was required for all my routing logic and Data Weave was required for all my transformation logic. But hey, why? If Data Weave is strong enough to manage it all, why was I compelled to use and study two languages? Ok, just timing is the key to that. The mule was very Java-oriented when MEL was implemented. There were several evaluators to manage various inputs, such as Groovy and JSON, up to that point. As a consequence, when working with these expressions, MEL was developed to construct a seamless experience. Transformations, on the other hand, were considered separate; only transformers and DataMapper were used at the time, for the most part.

Data Weave became a success with a well-functioning transformation engine and rich query functionality. So, there we were, inside our network of two languages, and one so dominant that the other had a feature to name it: dw (). Using Data Weave does mean using all of its power.

You must turn everything into Java artifacts in Mule 3 to test some expressions (e.g. when routing payloads or logging data). The specifications of each transformer you will have to understand. But, with Data Weave as the language for expression, you might easily explicitly query the data and forget all those transformations.

With Data Weave, rather than its style, our expressions could be based on the structure of our knowledge. Since a Java array is the same as a Data Weave JSON array, we don't need separate expressions to manage it.

Entry to binary data can be achieved wherever you need it and you can get larger than memory, random, due to some excellent streaming upgrades.

That is why, with a single, new, consolidated language that has success at its heart, Mule 4 unifies expressions and transitions, rendering all of the above reality.

Why Mule 4 Revolutionizes Data Weave

Data Weave now offers a service for testing expressions used by the Mule Runtime engine. In turn, the runtime gives Data Weave all data, including payload, variables, planned performance, and metadata, about the current execution. For eg, this helps Data Weave to know whether a string or a map is needed, how each variable should be treated, whether a type is coerced, etc. Then, as in the example below, one can write expressions:

Variables #[payload ++ variables.myStatus]

The keywords for payload, variables, and attributes will be translated as such in this case. Mule 4 Now, many can question how this one-liner Data Weave term works, especially because the output format requires users to announce Data Weave. Where appropriate, the output form is assumed, so you can apply it to the one-liner as well. We use a JSON payload in the example below to set the headers of an HTTP request, take the current map of headers and add one to it with the expression:

Payload ++ { host:'httpbin.org '}] #[output application/java —- payload ++ { host:'httpbin.org'

The backend will respond with the received headers containing the values sent as the body to our HTTP listener and the host one that we have inserted.

Full Incorporation for Mule

We have only spoken about Data Weave phrases as a one-liner for routers and basic attributes so far. Flows are another simplification that we made. By encouraging users to identify "inline" content, we have reduced the number of necessary transformation elements. For example, inside the 'write' portion of the File connector, you can create the content of a file, there is no need to use a 'transform' component to get the payload you need beforehand. In the above case, you do not need any additional steps to iterate the obtained JSON payload, and the new file path is defined by the following expression:

  • payload.name ++ '.' ++ dataType.mime-type name ++.' ++ dataType.mimeType.subType]

In the writing operation, we also add a desired "date" attribute, exactly where it is expected, setting the content to:

  • payload ++ { date: now() }] { date: now() }]

A fine example of the output from being assumed is the last expression. Since we know the payload is JSON, the output does not need to be specified and the files generated will also be in that format. This functions with all new connectors since our new Mule SDK supports it. The HTTP body of a request is sent with a script in the example below, where I may take advantage of all the features of Data Weave, as in any transformation part script.

  • p>
Percentage dw 2.0

Application/json performance

  • p>
Payload ++ {place:' LATAM', office:' BA'}}

]

Additionally, the listener response body can be modified with the expression.

  • Payload Payload.data]

This is because a JSON would be returned by the backend server, where the value reflects the payload sent to it. So, to add any more attributes, the data collected by the listener would be updated and then forwarded back.

For eg, the data that the HTTP listener receives is application/x-www-form-urlencoded. Data Weave performs the out-of-the-box-no parsing needed now. The outcome would have been the same even though I had sent a JSON payload. This is because Data Weave helps us, rather than its format, to concentrate on the structure of the data.

Compatibility for Mule

But enough about Data Weave, let's talk to the elephant in the post, compatibility with Mule 3 and MEL. Oh, there's always MEL, it's all deprecated. Since the main and default speech-language is Data Weave, each expression will have the prefix "Mel:" to indicate that it should be evaluated with MEL. The HTTP listener in the example below.

Users adjust more readily, but I would make the Data Weave leap as quickly as possible if I were you, to begin taking advantage of all its wonderful features!

A bit more

The team carried out intensive efforts on the language version 2.0.0. The team assisted not only in the integration of the runtime but also sought to develop the language itself. In a future column, I'll leave it to them to tell you all about that, but you can know more through MuleSoft online training.

  • Imports and modules
  • You can now box and import scripts into others so that the code can be reused and shared.
About the Author

I am a Digital Marketing Analyst working in cynix it

Rate this Article
Leave a Comment
Author Thumbnail
I Agree:
Comment 
Pictures
Author: Rajesh Cynix

Rajesh Cynix

Member since: Feb 10, 2021
Published articles: 57

Related Articles