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:
Restart the ESB since transports are only loaded at start, not when they are changed on the fly.
Content
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).
<?xml version="1.0" encoding="UTF-8"?>
<proxy name="VFSSOAP" startOnLoad="true" transports="vfs" xmlns="http://ws.apache.org/ns/synapse">
<target>
<inSequence>
<clone>
target sequence="SendOnSequence"/>
</clone>
</inSequence>
<outSequence/>
<faultSequence/>
</target>
<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>
</proxy>
SendOnSequence
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.
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>
<log level="full"/>
<send>
<endpoint name="FileEpr">
<address format="soap11" uri="http://localhost:8280/services/echo"/>
</endpoint>
</send>
</sequence>
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 :
cd
md WSO2ESBVFSINPUT
cd WSO2ESBVFSINPUT
Setup
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">
<soapenv:Header/>
<soapenv:Body>
<echo:echoString>
<!--Optional:-->
<in>?</in>
</echo:echoString>
</soapenv:Body>
</soapenv:Envelope>
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 :
cd
md WSO2ESBVFSINPUT
cd WSO2ESBVFSINPUT
Testing
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
As well as the sequence
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.
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.
After we send the file to the proxy the Request count should be 1.
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 Support, WSO2 Development Support, WSO2 Operational Support and WSO2 Training Programs.
