WSO2 Tutorial 6 min

WSO2TORIAL: Moving files with WSO2 ESB VFS transport (Part 3)

Rob Blaauboer
Rob Blaauboer
Integration Consultant & WSO2 Trainer
WSO2Torial witruimte

In the previous blog we looked at of the lesser documented transports in the WSO2 ESB VFS transport. This Axis2 transport allows you to move files from one location to another. But how do we actually use it? In this WSO2 Tutorial we will look at the content of a file and how we can access it.

We continue with the proxy and file service we used in the previous blog. If you haven’t read it, VFS (Virtual Files System) transport is enabled on axis2. The file can be found at [ESB-HOME]/repository/conf/axis2/axis2.xml

The [ESB-HOME] refers to the fully qualified path to the installed version of the ESB.

Remove the <!—and –> to enable the Receiver and Listener. Contrary to other transports there are no other parameters to be defined. The receiver looks like this:

WSO2 ESB VFS - transportreceiver.pngAnd the sender like this.

WSO2 ESB VFS - Transportsender.png

Restart the ESB since transports are only loaded at start, not when they are changed on the fly.


In many cases the content of the file is important as well, not so much the fact that the file is there.

We are going to create a simple setup where we will send a SOAP message in a file and take it to the ESB. In this case we also need to make sure that we define the content type in the right way so that the message formatter will build the incoming message correctly. We even omitted the full log mediator that was there in earlier blogs.

We will create a new proxy from the other proxy we defined in the previous blogs on VFS.

The proxy is almost the same as the previous one, we clone the message and send it to a sequence (SendOnSequence).

WSO2ESB VFS - SendOnSequence.png

<?xml version="1.0" encoding="UTF-8"?>
<proxy name="VFSSOAP" startOnLoad="true" transports="vfs" xmlns="http://ws.apache.org/ns/synapse">
        target sequence="SendOnSequence"/>
  <parameter name="transport.PollInterval">15</parameter>
  <parameter name="transport.vfs.FileSizeLimit">10000</parameter>
  <parameter name="transport.vfs.FileURI">file:///C:/WSO2/ESB/VFS/INPUT/</parameter>
  <parameter name="transport.vfs.ContentType">text/xml</parameter>
  <parameter name="transport.vfs.ActionAfterProcess">MOVE</parameter>
  <parameter name="transport.vfs.MoveAfterFailure">file:///C:/WSO2/ESB/VFS/FAILURE/</parameter>
  <parameter name="transport.vfs.ActionAfterFailure">MOVE</parameter>
  <parameter name="transport.vfs.FileNamePattern">.*.xml</parameter>
  <parameter name="transport.vfs.MoveAfterProcess">file:///C:/WSO2/ESB/VFS/ORIGINAL/</parameter>


It is important to realize that the file content will be available in a Soap message in the ESB, regardless of what is sent to it. The WSO2 ESB uses the AXIOM (Axis2 Object Model) that uses soap as it’s model. So a text file will be as a body included in the Soap Envelope.

In this case we are sending a Soap message which does not need to be formatted by the message formatter. As you will see when we use the message to send it through.

WSO2 ESB VFS - Sending SOAP message in the ESB.png

As you can see it is quite simple, we indicate with a custom log mediator that we are in the SendOnSequence and after that do a full log to show the soap message that has come in. Finally we pass it on the the echo service on the ESB.

<?xml version="1.0" encoding="UTF-8"?>
<sequence name="SendOnSequence" trace="disable" xmlns="http://ws.apache.org/ns/synapse">
  <log level="custom">
     <property name="sequence" value="SendOnSequence"/>
  <log level="full"/>
     <endpoint name="FileEpr">
        <address format="soap11" uri="http://localhost:8280/services/echo"/>

Put this Soap Envelop into an xml file (e.g. test.xml) and save the file to the directory you use for the input files (in my example C:WSO2ESBVFSINPUT).

If you haven’t created this directory structure, the commands are for windows :



Since we want to use out of the box functionality, we will use the ECHO service on the ESB. We will opt for the EchoString soap service. This is the message that would get sent to the Echo service (http://localhost:8280/services/echo)

<soapenv:Envelope xmlns_soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns_echo="http://echo.services.core.carbon.wso2.org">

Put this Soap Envelop into an xml file (e.g. test.xml) and save the file to the directory you use for the input files (in my example C:WSO2ESBVFSINPUT).

If you haven’t created this directory structure, the commands are for windows :



In order to test everything create a C-App and CAR file and deploy them to your ESB.

We will not describe all of the steps to do so since that would make the blogpost quite long.

Check if the proxy is on the ESB

WSO2 ESB VFS - Check if the proxy is on the ESB .png

As well as the sequence

WSO2 ESB VFS - check sequence.png

Start the proxy if you haven’t done so already. A deployed proxy needs to be activated, especially a VFS one that polls a directory.

Watch the console for the output, in this case it shows the soap message before it was sent to the echo endpoint.

WSO2 ESB VFS - soap message before sending to echo endpoint.png

One of the challenges of course is, was the message received and correctly processed. The Echo service is normally used with a client like SoapUI and we can see the response coming back. Since we are sending the message but we do not see the response we need to look elsewhere for our answer.  There are other solutions like using an out sequence but this will work as well.

The service dashboard shows the number of requests and faults. We restarted the ESB to put the tally to zero for all counters.

WSO2 ESB VFS - number of request and faults.png

After we send the file to the proxy the Request count should be 1.

WSo2 ESB VFS - request count 1.png

As you can see this is the case. There are no faults so our message should have been handled correctly.

Recap of this blog

This is of course a very simple setup of a VFS transport, just picking up file content and sending it to a service. Depending on the content of the file and your use-case you can image multiple scenarios to extend this example.

If you have any questions about this blogpost contact us via the comments section of this blog. View also our WSO2 Tutorials, webinars or white papers for more technical information. Need support? We do deliver WSO2 Product SupportWSO2 Development SupportWSO2 Operational Support and WSO2 Training Programs.

Full API lifecycle Management Selection Guide

whitepaper hero
Get it now
We appreciate it
Care to share

Please select one of the social media platforms below to share this pages content with the world