Most examples found in the official documentation and various blogs shows how to use the Web Service Consumer in Mule ESB Enterprise Edition. So they are using DataWeave or, for Mule ESB 3.6 or earlier, DataMapper to prepare the XML payload to be send. This is sometimes misinterpreted by users so that they think that the Web Service Consumer by it self is a Enterprise Edition only feature, when in fact it is available, and very useful, even in Mule ESB Community edition.
In this blog I will explain two ways to prepare the payload to be used by the Web Service Consumer when you can not or do not want to use DataMapper or DataWeave. I expect that the reader is familiare with the basics of creating a Mule ESB application and using the HTTP Listner connector aswell as the Web Service Consumer.
Using a ESB to proxy incoming HTTP (and HTTPS) calls to an internal service, adding cross cutting concerns such as logging and authentication, is not uncommon. This blog will describe how to build such a proxy flow using Mule ESB 3.6.1 Community Edition.
What does the official documentation say ?
The official MuleSoft documentation includes a description on how to Proxying Your API how ever this guide is based on the assumption that you are using the Anypoint API Gateway which is part of MuleSofts AnypointPlatform offering.
Thus this guide is not applicable when working with the community edition of Mule ESB. Luckily we can still use much of this guide to build our own proxy flow.
One of the features of Mules ESB, that I find very useful, is the Mule Expression Language (MEL). It can be used not only for flow control and filters, in fact most of the components and transformers that come out-of-the-box with Mule ESB support that properties are specified using MEL.
The simplest example is when you want to use the default logger component to log some part of the message such as the payload and/or variables/properties.
A common integration scenario is that a company/organisation has a old internal web-service that they want to expose as a public interface.
Often these internal services have a less than ideal interface which is often auto-generated from some business logic so you do not want to simply expose the existing contract. Instead we want to have a interface more suited for use by external entities. However it is not always practical or possible to rewrite the internal service.
The solution is to build a SOAP proxy with transformation.
I found the guides available on mulesoft.org a bit cluttered when it came to how to build the Mule ESB from source.
First of it's the matter of finding the source. Following the guide lines in the official guide you see that it's the SVN repository on codehaus that is the main repo. There is a repository on github however this seems to just be a mirror that does not follow the main repository very well. The trunk is pretty much empty and it seems the branches/mule-3.3.x is where all the action is.
When building integrations with JBoss ESB you naturally need to interact with other systems via notification gateways other than messaging queues. It could be that you need to enrich data from a WS-SOAP service or just put data into a file in a specific directory. These addresses and location often need to be different depending on which environment you are running in.
This is a simple step-by-step tutorial to install and configure exim to route all e-mails send though a local SMTP server to one local user, regardless of the e-mail address or domain. I found this set-up very usefull when testing applications that send e-mail messages and you do not want to generate multiple HotMail accounts for testing or in case I'm wanted to do some testing and development when I'm offline.
Start with installing exim.
user@devmachine:~$ sudo apt-get install exim4