BizTalk Server FTP issue: The FTP server did not accept a FTP command for an unexpected reason.

BizTalk Server FTP issue: The FTP server did not accept a FTP command for an unexpected reason.

This is not the first time I have worked with the FTP adapter. Almost all my clients have a File transfer solution, and FTP is used in many of them. But today was probably the first time I had the need to configure an After Put command on the FTP channel. Basically, we need to upload the file as .tmp, and after it is uploaded to the FTP we need to rename it to .xml.

The BizTalk Server FTP adapter contains an After Put property that allows you to specify the FTP commands to run after the file PUT. You can provide a chain of commands by separating each one with a semicolon (;).

So, yes, this is what I want to use. On the first approach, I try to add the following command:

rename orders.20231124115951.054.tmp orders.20231124115951.054.xml

And to my surprise, I got the following error:

The command “rename orders.20231124115951.054.tmp orders.20231124115951.054.xml” failed on the FTP server. Inner Exception details: “The FTP server did not accept a FTP command for an unexpected reason. “.

To troubleshoot the adapter, I defined a log file and tried it again, and I got the following traces:

> CWD /inbox
 PWD
 TYPE I
 PORT 10,0,0,224,228,205
 STOR orders.20231124115951.054.tmp
< 150 Opening BINARY mode data connection for orders.20231124115951.054.tmp
 rename orders.20231124115951.054.tmp orders.20231124115951.054.xml
 QUIT
< 221 Goodbye.

After a quick look at this error, I saw a post saying that mv command instead of the rename:

mv -- -orders.20231124120624.055.tmp orders.20231124120624.055.xml

But I endup receiving the same error:

> PWD
 TYPE I
 PORT 10,0,0,224,229,79
 STOR orders.20231124120624.055.tmp
< 150 Opening BINARY mode data connection for orders.20231124120624.055.tmp
 mv -- -orders.20231124120624.055.tmp orders.20231124120624.055.xml
 QUIT
< 221 Goodbye.

Causes

While using and troubleshooting the FTP adapter, it is always good to set the Log file. This will contain all the instructions made by the adapter. By doing so, I realized that the traditional commands we use, like dir, delete, or rename, are not supported in the FTP adapter.

The logs show that the commands used are CWD and STOR, which are the equivalent of dir and put or PWD to display the current directory.

CWD is the Net::FTP method name; CD is the standard FTP and shell command for changing directories. That means that the BizTalk Server FTP adapter uses Net::FTP commands.

Solutions

The solution is quite simple to accomplish:

  • Replace the rename command with the equivalent in Net::FTP that is:
    • RNFR FTP command: The RNFR command is issued when an FTP client wants to rename a file on the server. The client specifies the name of the file to be renamed along with the command. After issuing an RNFR command, an RNTO command must immediately follow.
    • RNTO FTP command: The RNTO command is used to specify the new name of a file specified in a preceding RNFR (Rename From) command.

So that means that the After Put property needs to be set as:

RNFR orders.20231124120624.055.tmp;RNTO orders.20231124120624.055.xml

Hope you find this helpful! So, if you liked the content or found it helpful and want to help me write more content, you can buy (or help buy) my son a Star Wars Lego! 

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.

He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
View all posts by Sandro Pereira