In the last article, you can find the idea of how to introduce field filtering for your APIs. My simplified Content Filter allows for providing negative or positive filtering. The first one tells which fields Filter removes from the target
At some point, you may have a service that returns a lot of fields and related objects. What if the service consumer doesn’t want all the fields all the time? In other words, he/she would like to have the response
Recently I have been working on a really simple case. When an HTTP server returned an error and not empty body I needed to embed this body into an error structure. Although this is simple case I got a problem with implementing it in Mule 4. In the previous Mule edition it was a little bit simpler. So let’s see what it is all about.
It is always desirable to reuse as much code as possible. We can do the same regarding to DataWeave transformations and custom functions. In this article I will describe how to reuse code in newest DataWeave using modules. For those of you, working with DataWeave 1.0, I will describe how to reuse code with readUrl function.
During transformation to JSON often I do not want null properties. It is easy to remove them, by just using skipNullOn attribute. However for empty objects it is not that trivial, especially when you have to deal with many such cases within one transformation. In this article I will show you how you can achieve this quick and easy.
In the 3rd tip I have described nuisance with casting to integer value. This time we will look at really large numbers and their formatting. In addition I will mention scientific notation. All these topic are around number format used
There are time when you need to get one particular element from an array, but not based on the index. This item needs to fulfill some requirements like equality and so on. In order to perform that task selector ? was introduced. This is applicable for both DataWeave 1.0 and 2.0.
I have already presented how to call Java code using messages processors with the newest Java Module for Mule 4.x. For earlier mule’s version Entry Point Resolvers were used to invoke custom Java code. However for scenarios when we would like to use custom code in DataWeave, for transformations, another approach is needed. Approach presented in this article will be more concise comparing to using message processors. It was highly extended comparing to possibilities of Mule 3.x version. Mule 3 allowed to invoke static methods. In contract Mule 4 not only permits to call static methods but also instantiate classes and access its instance attributes.
Tip number 2 is about converting decimal number into integer one. This may seem tricky at first. You may say that we do not need to do anything special and DataWeave engine will handle it underneath. However there is a nuance that you should be aware of. In transformation to XML this may not actually works. This tip is primary dedicated to DataWeave 1.0 as in DataWeave 2.0 this does not occur.
Tip number 1 will be about data existence check. There are often situation that nearly the same conditions need to be checked in every line. I have seen many transformations that were really long and complex. Reading them were not only difficult but a lot of repeatable conditional checks were made. Here I will show you an example that will evolve to point where we reuse everything that was possible. As a result we should achieve more concise and readable transformation. As new DataWeave is about to be released, examples will be both in 1.0 and 2.0.