I like the idea of clean easily read XML configuration in my Mule projects. Therefore I externalize DataWeave transformations , SQL quires and other content. In this article I will compare assets that Mule gives as to achieve externalization of such things in Mule 3 and Mule 4.
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.
In this brief article I will describe the problem and solution that I have lately faced. As it is a good practice not to hard-code connection data I have extracted them to external file called connection.properties. I did not expect to receive an error something like $[smtp.host]. I did not know what it can means. Below I have described what it is.
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 by DataWeave engine. So let’s see what the problem looks like. Problem This problem may…
Anyone who has designed RESTfull API appreciate API Kit Router available in Mule. It not only generates flows based on API definition but also route and validate messages. Our flows looks more concise and easy to read. This feature is available for both Community and Enterprise editions. For SOAP Web Services SOAP Router is available. However this time this utility works only for Enterprise Edition. Some time ago I developed a couple of services on Mule Community Edition. All services have WSDL contracts and I must say that when I now think about the implementation I would appreciate such router. So I have decided to write something similar that would work for Mule CE.
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.
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.
What is the most important thing that a mule developer needs? I think that well configured IDE is the answer. While you can have an appropriate set of skills, without a good toolkit you wouldn’t be as efficient as you could. Therefore in this article I explain how I configure my development environment. I hope that you would enjoy it :).
In my previous post I have described usage of CXF proxy client to consume soap web service. We will create similar service but this time we will use Web Service Consumer.