WSO-2-EASY: Download and store a binary file

Working daily with WSO2 products we sometimes encounter things that even we did not know yet, but in fact are so handy we want to share it with the whole world. We have created a new group of articles called WSO-2-EASY that will show some of best tips and tricks that will help you to either save time or create tidier code.

In some cases you want to retrieve a binary file from a location on the internet and store it locally for further processing.

We define a simple proxy in the ESB that takes a file (specified by an URL like http://example.com/wso2esb-4.8.1.zip) and retrieves it from a server to subsequently store it locally.

In the In Sequence of the proxy we set a PROPERTY mediator that will send an HTTP 202 message to the client and subsequently use a SEND mediator with a GET on an HTTP Endpoint to retrieve the file.

The Out Sequence simple takes the downloaded file and stores it locally on the file system. The exact place is indicated in the endpoint address.

The XML code for this proxy is as follows.

Prequisites

In order for this proxy to work you need to do two additional things:

1. Enable the VFS transport in the ESB
2. Define the right messageBuilder

VFS transports

In order to enable the VFS transport you need to edit the AXIS2.xml file that you find in the <ESB_HOME>/repository/conf/axis2/directory.  There you will find two entries:

<!–transportSender name=”vfs” class=”org.apache.synapse.transport.vfs.VFSTransportSender”/–>

and uncomment (remove the !–and — of) the VFS sender as follows:

…

<transportSender name=”vfs” class=”org.apache.synapse.transport.vfs.VFSTransportSender”/>

This will enable the ESB to use this type of transport. In this case you only need to enable the sender, so you could leave the transportReceiver disabled.

A transport is responsible for handling in a specific format. If you want to know more about transports, see the WSO2 ESB documentation.

Message builder

When writing the file to your local disk you need the right builder to write it in the desired format, in this case for a zip file is the contentType=”application/zip” Other types of files have other content. This is determined by the Content-Type header sent by the server, so there should be adequate mapping between Content-Type header and the message builder.

You need to add the following messageBuilder to the AXIS2.xml file. There is a section called messageBuilders to which you can simply add this contentType.

<messageBuilder contentType=”application/zip” class=”org.wso2.carbon.relay.BinaryRelayBuilder”/>

If you want to know more about message builders, check the ESB documentation.

Extending this example

Currently both the URL and the local storage are hardcoded in the proxy sequence.

You can extend this example by defining two parameters that you would supply when calling this service, therefore making the proxy more useful. Furthermore, this sample also assumes both the In sequence and Out sequence throw no errors (e.g. the server is online and the disk has enough space).

In a real life example these situations need to be handled in the Fault sequence (server not available) and in the Out sequence (not enough disk space).

You can easily extend the sequence to accommodate these extensions.