Reading Time: 9 minutes

We recently released new connectors for FTP and SFTP connectivity in Mule 4, now available in Anypoint Exchange. Even though FTP and SFTP are two very different protocols, we crafted these connectors to be practically identical, providing an easy and consistent experience. As a result, the same use cases are addressed in a similar way in both protocols.

And it gets better! Remember the new file connector we discussed a while ago? FTP and SFTP connectors were designed to be completely consistent with it from a language point of view. All three connectors look exactly the same!

latest report
Learn why we are the Leaders in API management and iPaaS
Read reports

Some of the main features of these connectors are:

  • Unlike the old FTP and SFTP transports (which only provided a polling inbound endpoint), these connectors can read files or fully list directories contents on demand
  • Common operations such as copying, moving, renaming, deleting, creating directories are now first-class operations in these connectors
  • Support for locking files
  • Advanced file matching functionality
  • A design that is fully consistent with the File connector. The same set of operations are available on all three connectors and they behave almost the same

Connecting to an FTP server

As usual with Mule, connections are established through config elements:

<ftp:config name="ftp">
  <ftp:connection username="anonymous" password="password" host="localhost" port="${ftpPort}" workingDir="${workingDir}"/>
</ftp:config>

<sftp:config name="sftp">
  <sftp:connection username="anonymous" password="password" host="localhost" port="${ftpPort}" workingDir="${workingDir}"/>
</sftp:config>

For SFTP, it is also possible to connect through a proxy like this:

<sftp:config name="sftp">
  <sftp:connection username="muletest1" password="muletest1" host="127.0.0.100" port="${SFTP_PORT}" workingDir="${workingDir}">
    <sftp:sftp-proxy-config host="localhost" port="${proxyPort}" protocol="HTTP"/>
   </sftp:connection>
</sftp:config>

For SFTP, there are other connection parameters and functionalities including but not limited to:

  • The ability to authenticate with an identity file
  • Specifying a known host file
  • Preferred authentication methods

Common configuration parameters

The most important config parameter is the <working dir>. The <working dir> is the path to a directory that is considered as the root of every relative path used with this connector. If the directory is not provided, it will default to the remote server’s default. Notice that this is exactly the same functionality as the new File Connector, except, of course, that the default value is different.

Dynamic connections

Many integrations require connecting to different servers depending on a certain condition. Examples of this include:

  • Connecting to different invoice storage servers depending on the branch that emitted the invoice
  • Connecting to different servers depending on a given integration subject, like in a multi-tenant use case

To accommodate for these use cases, the config element support expressions, so that the connection parameters can evaluate these conditions and connect to the correct server.

Example of dynamic connection

Consider the following example application:

<sftp:config name="sftp">
  <sftp:connection host="#[payload.host]" username="#[payload.user]" password="#[payload.password]" />
</sftp:config>

<flow name="sftpMultitenant" >
  <http:listener config-ref="HTTP_Listener_config" path="/multitenant"/>
  <set-variable variableName="content" value="#[payload]" />
  <file:read path="recipients.csv" outputMimeType="application/csv" />

  <foreach>
    <sftp:write path="demo.txt" config-ref="sftp">
      <sftp:content >#[content]</sftp:content>
    </sftp:write>
  </foreach>

  <set-payload value="Multicast OK"/>

</flow>

  • This sample is a dynamic multicast application. It starts by defining an SFTP config in which the host, username, and password are expressions
  • Then it has a flow on which content is posted through HTTP
  • Then it uses the File connector to load a recipient’s file, which is a CSV file containing a random set of SFTP destinations with columns such as host, user, and port
  • Then we use a <foreach> to go over each of the lines in the CSV file
  • On each <foreach> iteration, each expression in the SFTP config will resolve to a different value, establishing different connections to each of the servers

Notice that:

  • This example uses the new File connector to read a file in the middle of the flow
  • The information posted through the http:listener component is written to each SFTP site multiple times. Because the component makes use of the repeatable streams feature, you don’t have to worry about consuming the stream multiple times. You don’t even have to know streaming is taking place at all!

BONUS TRACK: Notice that <foreach> is automatically going through each line of the CSV file. In Mule 3, you would need to first transform the CSV file into a Java structure, but because Mule 4 is now Java agnostic, this works out-of-the-box!

Other connector features

I could go on about how the connector can handle the following:

  • File representation and attributes
  • MimeType metadata
  • Operations
  • Listing
  • Matching
  • Error handling
  • Polling

Some of the above topics are discussed in the File Connector post. Please refer to the blog post for more information, as the functionalities of both connectors are similar. There are only two relevant differences:

  • Attributes: The Attributes object set in the message by the read and list operations have a very small difference with regards to that of the file, mainly around timestamps. This is simply because FTP and SFTP handle those differently.
  • Locking: The File connector allows users to optionally perform file locking at the operating system level, which means that the lock is not only good for your Mule application, but it also affects other processes. File-system-level locks are not possible in FTP, so the lock is a Mule lock. That means that the lock will only protect the file against other flows in the same Mule application, but it will not protect the file against external processes. Do keep in mind that if the Mule application is running on a cluster, the lock will be distributed.

For a full description of these connectors, please visit the documentation site:

Try it Now!

Check out the FTP/SFTP connector with flow designer. You can design and publish your integration directly on the cloud, and yes, the file connector is also available there.