Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Moving Files to Unix With Mule

DZone's Guide to

Moving Files to Unix With Mule

It’s very easy to create a Mule application that can transfer files to a remote different system easily and quickly without any hassle.

Free Resource

Learn how API management supports better integration in Achieving Enterprise Agility with Microservices and API Management, brought to you in partnership with 3scale

We often encounter a requirement to transfer files from one environment to another such as from Windows to Unix or from Unix to Windows.

This is especially so in a case where we have our Mule runtime running on our Unix system and we need to transfer few files from our local Windows system to the remote Unix system where Mule is running.

We can transfer files from our local Windows system to the remote Unix system (the system should be accessible) where the Mule Standalone runtime is running through a Mule application in various ways. However, the way I find simple is by creating a Mule application that will transfer the entire required file as an attachment and place it into the target folder of the Unix system.

Using the payload attachment especially as multipart/form-data is the easy way of sending the file between two different systems.

The multipart/form-data is the default encoding a web form and it constructs a set of key/value pairs representing form fields and their values and allows entire files to be included in the data.

So, let’s start the demonstration of transferring files from our local Windows to the remote Unix system through our Mule application.

Our Mule flow is as follows:

<http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="8087" doc:name="HTTP Listener Configuration"/>

     <flow name="attachmentFlow">

        <http:listener config-ref="HTTP_Listener_Configuration" path="/attach" doc:name="HTTP"/>

        <logger message="Attachment Keys:- #[message.inboundAttachments.keySet()+'\n'] Mime Type:- #[message.dataType.mimeType] " level="INFO" doc:name="Logger"/>

        <set-variable variableName="targetPath" value="${TargetPath}" doc:name="Variable"/>

        <choice doc:name="Choice">

            <when expression="#[message.inboundProperties.'TargetPath'=||message.inboundProperties.'TargetPath'=]">

                <logger level="INFO" message="File path is null" doc:name="Logger"/>

                <set-variable variableName="targetPath" value="${TargetPath}" doc:name="Variable"/>

            </when>

            <otherwise>

                <logger level="INFO" message="File path #[message.inboundProperties.'TargetPath']" doc:name="Logger"/>

                <set-variable variableName="targetPath" value="#[message.inboundProperties.'TargetPath']" doc:name="Variable"/>

            </otherwise>

        </choice>

            <!-- Saving attachments in target path  -->  

        <foreach doc:name="For Each" collection="#[message.inboundAttachments]">

            <logger message="Attachment File name:- #[payload.dataSource.part.fileName] Attachment Key name:- #[payload.dataSource.part.partName+'\n'] Attach File Content type:- #[payload.dataSource.part.contentType] " level="INFO" doc:name="Logger"/>

            <file:outbound-endpoint path="#[flowVars.targetPath]" outputPattern="#[payload.dataSource.part.fileName]" responseTimeout="10000" doc:name="File"/>

        </foreach>

         <set-payload value="File delivered !" doc:name="Set Payload"/>

    </flow>

Here is the above flow. We can see we will be sending the files as an attachment that will be saved at the target Unix system with help from the File outbound component that will be responsible for saving each inbound attachments as a file in the target folder.

We will be specifying the target folder name of the Unix system as a header in our request.

If in any case we miss mentioning the target folder name of the Unix system as a header in our request, the files will be stored in a default folder in the target Unix location. The default location will be picked from the environment variable specified in the mule-app.properties file:

TargetPath=/home/anirban/defaultFolder

Deploying the Application in the Target System

All set to go!

We will deploy the Mule application in the Mule Standalone runtime server running in the Unix System:

Image title

Our application is deployed successfully in the Mule standalone running in the remote Unix system.

Testing Our Application

So, now we will be testing the application from our local Windows system and transfering the local files using the application. We will be using Postman client to hit the service we created as follows:

Image title

Here we can see we are setting 2 attachments to send. One is image JPG file and other is a PDF file ready for sending. If you notice the URL, we have used the remote IP address of the Unix system that is accessible to us.

One more thing we need to mention before hitting the service. We need to specify the target file path we want to stores our file in the target system in a header as follows:

Image title

If we don’t mention this header it will store the files in a default location mentioned in environment variables.

Once we hit the service, we will get a response as “File delivered!” in the Postman client:

Image title

Now it’s time to go into the Unix system and check the files in the mentioned location in the header:

Image title

And yes! The files are deposited in the target location of our Unix environment and the target path is created!

Testing With Default Location

Now, one more round of our testing. We will not mention our target location in the header section and will keep it blank:

Image title

Here, we can see we haven’t mentioned anything in the header and kept it blank. We will check if the application now sends the file in a default target location that we mentioned in our environment variable.

We will hit the service again and will get a response as “File delivered!” in the Postman client:

Image title

Now, going to the default location /home/anirban/defaultFolder, we will check the existence of the files:

Image title

And voila! The files are there!

Conclusion

As we can see from the article, it’s very easy to create a Mule application that can transfer our files to a remote different system easily and quickly without any hassle. It can carry any kind of files and can store to a particular location of our choice in the remote system.

Unleash the power of your APIs with future-proof API management - Create your account and start your free trial today, brought to you in partnership with 3scale.

Topics:
mule ,unix ,integration

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}