Enhancements to the FTP Adapter


This topic describes the new and enhanced features to the FTP adapter available in BizTalk Server 2013 R2. The FTP adapter is enhanced to provide the following feature additions:

The FTP adapter in BizTalk Server 2013 R2 provides support for file transfers from an FTPS server over Secure Sockets Layer (SSL)/Transport Level Security (TLS). SSL/TLS ensures data confidentiality through encryption. You must enable the secure mode by configuring SSL-specific properties provided by the adapter. Because the adapter allows for both reading and writing data from a secure FTP server, the SSL-specific properties are available when configuring send handlers/ports and also with receive handlers/locations.

The following options are available for configuring the SSL-specific properties:

  • Use SSL property – Set this property so that FTP adapter must use SSL for each transfer session.

  • Enable Data Protection property – Set this property to turn on data encryption. The security policies of the FTPS server must allow for secure SSL connections with the adapter in order for this setting to work.

  • FTPS Connection Mode property – Set this property to determine when security is activated:

    • In Implicit mode, security is automatically turned on as soon as the adapter connects to the server.

    • In Explicit mode, the adapter sends a command to initiate a secure control channel.


The FTP adapter does not support revocation checks on the server certificates.

In the previous releases of BizTalk Server, the FTP adapter deleted the file after downloading so that the file didn’t download again in the next polling cycle. Due to this design, the adapter was limited to download files only from FTP locations that provided write access.

In BizTalk Server 2013 R2, the FTP adapter supports download of files from read-only file locations. The adapter now maintains a list of downloaded files in a database. For the next download, the list of files on the FTP server is compared to the list of files maintained by the adapter, and only new files on the server are downloaded. To support scenarios where an existing file is updated between two downloads, you can configure the adapter to also check file timestamps by setting the Enable Timestamp Comparison property for the FTP receive location. In such cases, even if the file name is same but the timestamp is updated, the adapter will download the file.

Sometimes the FTP server does not support associating a modified timestamp with a file. In such cases, the adapter enables you to specify an interval after which the file will be downloaded again. You configure this interval by setting the Redownload Interval property for the FTP receive location.

The table below lists the expected behavior of the FTP adapter for different values set for the Delete After Download, Enable Timestamp Comparison and Redownload Interval properties.

Delete After Download

Enable Timestamp Comparison

Redownload Interval

Adapter Behavior


Not applicable

Not applicable

The adapter deletes a file from the FTP server after downloading it. This is the default behavior of the adapter.



Not applicable

The adapter does not delete a file from the FTP server after downloading it. Instead the adapter compares the file’s last modified timestamp using the MDTM command. Depending on the timestamp, the adapter downloads the file again.




The FTP adapter downloads a file from the FTP server after the interval you specify, irrespective of whether the file has been modified or not.

The FTP adapter available with the previous releases of BizTalk Server provided atomic file transfer only for binary mode. In BizTalk Server 2013 R2, the FTP adapter is enhanced to also support atomic file transfer for ASCII mode. To enable atomic file transfer for ASCII mode, the adapter uses the Temporary Folder property. This property defines a temporary location on the FTP server where the file is first moved to. After the file is completely transferred to the temporary location, the file is then moved to the relevant location on the FTP server. Here, the assumption is that the file transfer is atomic between the temporary location and the relevant location on the FTP server.


The extension of using temporary folder to ASCII file is applicable only for the Send, and does not apply to Receive. The primary reason for implementing this feature is that, a third party application will not read a file until it is fully written. In the case of BizTalk receiving the file, the adapter will submit the file to BizTalk only after it is completely read.


In binary mode, the Temporary Folder property can also be used to resume file transfer if there is a failure in between. This is not applicable for ASCII mode. For ASCII mode, the Temporary Folder property is only used for atomic file transfer.

Community Additions