Reduce to Dashboard

When developers use DataWeave, they often come to rely on the reduce() function to fill in any gaps left by the standard Core library. Although filter() and joinBy() and splitBy() and even groupBy() could be implemented by simply using reduce(), we favor the Core library functions as the best implementation of those patterns.

On the other hand, polishing your reduce() game will get you through tight spots sometimes when the requirement is idiosyncratic, or when the standard function just won't do.

So we'll take a data set that represents a crude inventory, and use reduce() to extract a dashboard snapshot showing projected revenue, and potential growth through untapped inventory.

(BTW, if more about DataWeave is not your cup of tea, never fear. We are talking about the onset of automation in the workplace next. So drop by again.)

Just the Good Bits

Sometimes you find a use case that has a simple and elegant solution in a particular programming language. It might come from a question in conversation, or a requirement in a project on the table. The nature of elegance in code defies firm definition, but as a famous Jurist once said, "I can't define it, but I do know what I like."

One characteristic I usually find in what most observers might call "elegant code" is brevity. Fewer lines of code mean fewer places for a software fault to lurk. DataWeave certainly lends itself to brevity, even nearly to the point of compulsion.

Recently, a student of mine raised a question after doing one of the standard exercises in the MuleSoft Developer series using DataWeave. His question surfaced a typical use case for an API. 

We had just finished a Walkthrough that has us observe how to filter the elements of an Object given a list of desired fields.

His idea was to allow a query parameter that listed the fields being requested. If an API interface enumerates the fields that may be requested, the input can be easily validated.

Once we walked through the idea, we ended with a single line of code that completely handled the task. Follow our logic, and see if you find the outcome to be elegant, or simply brief.

Everyone's New Best Friend

 Everywhere I go, people are talking about OpenAI ChatGPT. They don't evangelize, they just mention it with a wink and a smile. Of COURSE you know all about this charming chat bot. And that's why we're smiling.

I had to get a look as soon as I heard about it from this NY Times article. It didn't take long before some of the responses passed my own personal Turing Test. 

I soon found myself arguing with the bot, struggling to get it to reconsider its answer. I was arguing with an algorithm! 

And given the nascent and experimental nature of my new friend, I would swear that I saw it evolve, day to day. (Stick with me to the end, and I'll entertain you with my own idiot glee by arguing with someone who is not there. Or is it arguing with someone who WAS there, but not actually someone?)

Bring Me the Severed Head of my Data

[This article is primarily intended for DataWeave developers. It deals with code and development strategies.] 

A while back, I wrote this article suggesting an approach to generating sample data with a simple DataWeave function. I left the conversation open ended to offer time for readers to suggest their own solution. I provided a sample (the severed head of my data) and a shell that suggested an approach to generation of sample data at any scale.

In this article, I offer one possible solution. If you have not read the OP (as it were) then give it a read and then see if you can hack out a solution that you like. If you've already given it a try, or if you simply want to see a solution dissected, then by all means, turn the page.

The premise is that you sometimes need to synthesize data for a project, and although there are tools that can readily help you do this, sometimes the characteristics of the problem domain call for a customized solution. Here are some reasons you might turn to DataWeave to help you.

Want to transform data? Then DataWeave

 If you work in corporate Information Technology, you may have been (or will be) asked to transform data from one form to another. There are many good ways to address the challenge, but my current favorite is the DataWeave language from Mulesoft.

The reason has nothing to do with the fact that it's my job to introduce developers to the language and then train them to use it well. It is much more because I've met many programming languages in my time, and this one is among the most compelling and satisfying.

You might not believe it if you have read many of the articles here, but I revere brevity. If you speak and finish exactly on the time marker, I applaud for the technical accomplishment much more so than for the speech. If you write me an email with 5 sentences instead of 5 paragraphs, I name my children after you.

When it comes to code, I realize at this point in my career, the fewer lines you write, the stronger your program. I blush with embarrassment when I think back to those days when I walked around and bragged that our project had grown to 80,000 lines of code. (Yes, I also counted the number of lines in each of the third-party libraries we bought for the project.)

Now that I know the folly of my ways, I can respect the fact that the best DataWeave expressions are the shortest.

DataWeave: Merge Objects From Different Sources

About the Merge

A common use case for DataWeave developers is that of merging elements from two different object collections into a set of composite output records. There are several ways to accomplish this, and we will look at a couple of them in this article.

As we explore this, we’ll also consider these ideas:

• The value of meaningful symbol names

• Using variables and functions to encapsulate awkward logic

• Using the groupBy() function to transform an array into a handy lookup table

This article also illustrates an approach that uses iterative construction to get our solution. It also demonstrates the value of moving complex operations into variables or functions to make our body expression more readable.

[Note: The considerations here are designed to facilitate understanding of the language. Best practice with DataWeave is to refactor important phrases to make them more generalized, and thus reusable. On the other hand, during initial development (and in team development) it pays to signal intention in the code until it is ready to be refactored for reuse.]

Spin Up Sample Data With DataWeave

 [This article is primarily intended for DataWeave developers. It may be considered a Forward to an article for the MuleSoft Developers blog that demonstrates how this problem can solved. Readers are invited to post comments to suggest the approach they believe in.]

Hopefully you don't commonly face this problem on your development team, but I see it often enough in the field that I know some folks could use a handy answer. Something that often hamstrings an API development effort is the absence of useful sample data for the project. If you use specification-driven development the way MuleSoft suggests, then there very well may be a suitable sample to get your project into coding.

Occasionally however, the samples we find in the spec are not enough either, and it falls to a developer who must generate a sample of suitable size, or variation. Using DataWeave, this is something you can do in a few minutes. I'm not going to show how in this article, I'm going to show you a framework and have you show ME how. Then I will publish an article in the MuleSoft Developers blog, showing my solution, and perhaps yours, if you suggest something magical.