It is a good practice to monitor your service and check whether it is available and/or is performing as expected. In order to do this, we need to specify what service’s health term means. In this article, I will present two different definitions. However keep in mind that you can have your own, project’s specific definition….
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.
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.
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.
For high-workload application it is important to manage resources efficiently. One of the tricks that can save resource usage is caching. In RESTful services this technic is used in GET methods. However it may by used in other cases when operation of getting particular resource can be reused. In this blog post I will extend previously design rest service by adding caching to two operations. Mule uses Cache Scope component. Apart from describing it I will show you possible obstacles and how to handle them.
HTTP GET method’s simple design has been published in previous article. We designed account service using RAML and Open API specifications. It is time, now, to implement that service so our potential users could consume it. To implement the service I use new Mule’s Design Center available on Anypoint Platform. To follow my steps you would not need to download any software on your PC at all. All will be done within web browser. On the other hand Anypoint Studio is the main IDE to design Mule’s services so I will not omit this tool. Within it I show the possibilities of APIkit message processor.
Recently I have decided to join Most Valuable Blogger (MVB) Program on DZone. Some articles, selected by DZone, will be republished and available on their site. So if you follow them you won’t miss any of my articles.
This article is an intro into a blog series about HTTP methods usage in RESTful services. As a GET is the most common I will start with it. This method is used for retrieving collection of resources or a single resource. In other words this could be used for searching purposes. However the more advanced search criteria I will describe in next article.
To design a service I will use two most commonly used specifications such as RAML and OpenAPI.
I have deiced to share basic idea about REST service design. During this blog series I will focus on commonly used HTTP verbs and their usage. However more sophisticated will be mentioned as well. In each article I will present concept with practical examples. To design a service I will use RAML and Open API specifications. Where this would be possible I will also prepare appropriate mule service’s implementation.