This year, we published over 215 blog posts spanning a wide variety of topics––from why messaging queues suck to why ESB-led integration is no longer an adequate approach for organizations.
Check out the top 7 most popular blog posts for this year!
When building DataWeave transformations for your Mule application, you will run into situations in which you will need to invoke external logic that may be encapsulated in a Java POJO, Groovy, Python, Ruby script, or really any lookup that uses a CSV file or database table as part of the transformation.
When integration involves different applications, systems, or databases, we face a common challenge: how do we bridge between data formats and how can we provide interoperability for fields that store dates and date/time values?
Logic handling using DataWeave is essential for simple mediums and highly complex transformations, in which the mapping requirements necessitate generating outputs based on values provided in the input payload.
So far in this 3-part series, we have looked at variables (Part 1) and functions (Part 2) in order to leverage them to our advantage. In this third and final part of the real-world DataWeave series, we will look at another common problem area, that of performing nested loops in data structures.
In the first part of this series we tackled the issue of defining and also using variables within DataWeave as opposed to using the legacy set “Variable” module. Today, I need to raise the topic of functions in DataWeave as a key thought when working with MuleSoft has to be “can I reuse this?”
Over the last few years at MuleSoft, I have had the opportunity to work with many different customers covering a wide range of use cases, inevitably requiring data transformations of one sort or another. I have observed some recurring patterns and “gotchas” when DataWeave is used in the real-world and I will address these in this 3-part series.
This post was written by one of the stars in our developer community, Manik Magar
In my last post, I discussed DataWeave 2.0 header and body (iterative functions) changes in Mule 4 Beta. In this post, I will dive deeper into the topic by discussing operator changes (within the body) as well as other changes.
As a language,
This post was written by one of the stars in our developer community, Manik Magar
Mule 4 beta is already out. One of the major change in Mule 4 is making DataWeave a default expression language over Mule 3’s default Mule Expression Language (MEL). The XML namespace of DataWeave is moved from dw to ee (core), and the DataWeave version has changed from 1.0 to 2.0 in Mule 4.
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.
I previously posted the below blog on how to reuse DataWeave code in a Mule flow using the readUrl() function.
