Web Service Consumer Connector with Mule ESB CE

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.

Building a HTTP Proxy flow in Mule 3.6+

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.

Using MEL for your logging, filter, content based routes and transformation needs

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.

Building a WS-SOAP Proxy with Mule ESB

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.

Building Mule ESB CE

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.

Creating reusable JBoss ESB archives

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.

Mr Yegge has some really good thoughts on how to build a large service platforms

I just finished reading Stevey's Google Platforms Rant.

Most of the attention this post has gotten is about the fact that Mr Yegge accidentally posted this publicly and how he goes on about his current company not doing things right. However if you look past the internal company politics rants and sarcasm about former employers this post is a really good article about how to build company wide service platforms.

It's really worth to read top to bottom.

Pages