Three months ago, I’ve introduced the newly created Erlang Transport for Mule 3 in this blog. To illustrate a usage scenario for this transport, which allows fast and seamless bi-directional communications between the JVM and the Erlang worlds, I presented an example where Mule was exposing a JSON over HTTP service for provisioning users in RabbitMQ.
At that time, the new configuration mechanism named Flow was not fully baked so I implemented the example “Mule 2 style“, which means that I used Services tied together with VM queues.
Learn why we are the Leaders in API management and iPaaS
Now that Mule 3.0.0 is out, my challenge for today’s post was to redo the configuration “Mule 3 style“, i.e. using by Flows.
Actually, if you look at the configuration below, a single Flow element is all what is needed to replace the three Services of the previous configuration:
The main takeaway for you is the following: by using a Flow, you can implement simple orchestrations easily and in a very readable manner. By reading the above example, you should have been able to understand that the implemented orchestration performs the following steps:
Create a new user on RabbitMQ
In case of success, grant permissions to this new user
In case of failure, return the Erlang error message as a string
Around these steps are technical actions, like using transformers to transform messages from one format to another. But notice how these actions actually flow with the overall orchestration: as you read from top to bottom, the steps that Mule will be performing unfold naturally.
The most observant readers will have also noticed that I am now using the newly introduced JSON module, alleviating the need to bring an extra library into Mule and to code to it (as it was done in the previous version of this example).
As mentioned before, Mule 3 is about giving power to its users. We believe the Flow element is a major milestone in this endeavor.