DataWeave – Tip #3

DataWeave – Tip #3

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.

Mule 4 new Java Module

Mule 4 new Java Module

In one of my previous posts I described Java Component and entry point resolvers as a way to invoke Java Code in Mule 3.x. In this article I will focus on completely new approach in Mule 4. Mule presents brand new Java Module capable of creating new instances, invoking methods on those instances and invoking static methods. Although you can invoke Java using DataWeave 2.0 and Groovy scripting you are losing additional metadata (DataSense). So lets walk through some sample application.

Entry Point Resolver how message is passed

Entry Point Resolver how message is passed

Sometime it is needed to use custom JAVA code to processes current message. Developed custom code is known as Java Component. How mule knows which method should invoke and what parameters should be there passed?  There are some rules that your class may full fill in order to work without any additional configuration. However when you have more sophisticated use case or class is fairly complex you would probably need Entry Point Resolver configured. I will explain on simple examples some of them. This is valid for Mule version 3.x. In next article I will describe in more detail new Java Module available in version 4.x.