We have few interfaces in production which transfers scan documents from one FTP site to another. After the scan documents are successully transferred they are moved to the archive directory so that they are not picked up again in next run.
Sometimes FTP server returns “426 Connection closed; transfer aborted.” error to wM when its trying to put the files on target FTP. Though the frequency of this issue is one in 100. When I look into the target FTP, the file are actually transferred, but for the flow services exception is being returned which causes the files to be transferred again in next run.
Why is FTP/webMethods behaving in this weird way, even when the put operation is successfull there is an exception thrown by the flow servcies.
We dont have any fire wall between webMethods and target FTP.
Have you confirmed that the files on the target side are complete and not partial files? If they are partial files, you may want to consider a transfer approach using a renaming scheme so that the target can never pick up and use partial files.
What is the target FTP server? The 426 is a response code which means the FTP server is returning that error. A search of the web for 426 and the name of the FTP software may turn up some info on possible causes.
The target file size is same as source and the file is as intact as it can be. Searching on 426 gives lot of information, but usually with this kind of error the FTP put operation also fails. Meaning the file is not transferred to target FTP. But in my case the file is transferred successfully. We are using windows FTP server.
I looking at the option to rename the file after the put operation is successful, but was still wondering about the root cause of the issue. This breaks the basic principles of engineering wherein even after the entire unit of work is successful, but FTP returns the error after that.
That’s good that the file is intact. There is something definitely odd going on causing the error to occur after the file has been transferred. Perhaps it is something after the put that is causing the error? Maybe the log out fails?
Are you using pub.client:ftp or do you use your own service that calls pub.client.ftp services like login, cd, put, logout, etc.? The pub.client:ftp service doesn’t trap any errors at individual steps so the caller cannot tell at what point the error occurred.
If you’re using pub.client:ftp you may want to create your own equivalent so that you can control error handling in a more refined manner.
If you already have your own pub.client:ftp equivalent, you might consider changing the structure a bit so that you can tell where the error occurs and ensure that logout always happens after a successful login.
I am using individual ftp service like ls, cd, rename for all the FTP operation. FTP logout is not failing because the service name in the lastError document in the catch block is pub.client.ftp.put. So its put that is definatly failing.
I think after successfully put, when FTP server is trying to return 250(put successfull) message to wM, there is something going wrong and FTP server is returning 426 with “Connection closed; transfer aborted”. I got the FTP server logs and I can trace 426 message in there too.
Right now I am changing the design to put the file to another folder and rename it if the put is successfull to avoid this kind of transient errors. I have escalated this issue to System administrator to see if they get any patch for windows server. Will keep you updated if I find anything usefull.