FTP Output action goes stuck

OL Connect Professional Workflow
1

Hi, we use the FTP Output task to send spool files to a remote server.

It seems that if the remote server goes down unexpectedtly, the FTP Output task waits indefinitely accumulating files to transfer.

I don’t know where the FTP queue is saved, in order to clean it manually if necesary, nor I understood why the FTP Output task doesn’t return after a timeout.

My solution was to delete the process and then it runs again automatically sending all the pending spools.

Thanks for any suggestion.

2

The FTP Output task send files to the following folder: %APPDATA%\Objectiflune\PlanetPress Workflow 8\PlanetPress Watch\ftpPut. It just works as a ‘send to folder’ task. The FTP Client service is the one that takes those files and send them to the ftp site. Is there any error in PPWatch and FTP logs ? That can help us understanding the problem you reached.

3

Hi Sofie,

   I couldn't find any error in the logs.

I couldn’t even find anything wrong with the server, except that the FTP queue was not being processed. After killing the “PlanetPress Workflow 8 ftpPut Client” service running in Windows, then it started being processed.

Regards.

4

Mdi,

As you said, the remote server goes down… so the PlanetPress FTP client (that has no timeout) waits for a respond that never comes. There is nothing else to do except to restart the PlanetPress FTP client when the remote server goes up again.

Regards

5

Hi Sophie,

    it would help to have a timeout so that it just retries sending the file by establishing a new connection (which would work once the FTP server is up again).

This would help so that when the remote server goes up again, the FTP is restored automatically without requiring a human intervention. On the contrary we have a downtime.

In our case it happened during the day, but we couldn’t send away our trucks because it was impossible to print Delivery Notes due to the FTP transfer being stuck. If this happens during the night it would be a major issue.

Is there a way to have the FTP client to restart automatically after a failure?

I think that waiting forever, without ever trying a reconnection, is not a good approach.

Thanks for any idea.

6

Mdi,

You are right, the FTP service should have a timeout feature. I will enter that suggestion into our database. But in the meantime, there is little you can do unless you’re willing to create a different process that monitors the files that are waiting to be sent by the FTP service. Using the Folder Listing task, you could check how long a file has been sitting there and if you determine that it has been there more than a certain number of minutes, you can automatically restart the service.

Sample process:

  • ?Folder Listing Input task, pointing to the folder Sophie mentioned and set to sort by Date
  • Add a Scripting condition (Language set to JavaScript) with the following code:
var todayDate = new Date();
var numFiles = Watch.ExpandString("xmlget('/files[1]/folder[1]/file',Count,KeepCase,NoTrim)");
var stringDate = Watch.ExpandString("xmlget('/files[1]/folder[1]/file["+numFiles+"]/time[1]',Value,KeepCase,NoTrim)");
var fileDate = new Date(stringDate);

var diffTime = (todayDate.getTime()-fileDate.getTime())/1000/60;

Script.ReturnValue = diffTime>5;
  • This code checks if the most recent file in the folder is older than 5 minutes. If it is, the condition returns true.
  • In the True branch, add a Run External Program task that calls a batch file. The content of that batch file (save it to something like like C:\MyProgs\FTPRestart.cmd) should be :
?net stop FTPPut8
net start FTPPut8
  • ?Note that in the Run External Program task, you cannot directly call the batch file: you have to call the C:\Windows\System32\CMD.exe executable, then pass the following parameters: /c “C:\MyProgs\FTPRestart.cmd” and set the the Start In field to C:\MyProgs
7

Hi Phil,

   thank you very much for your valuable answer. I will implement your solution, as it seems very valid.

I will be back in case of further doubts.

Thanks a lot!

8

Hi Phil,

  it works, but somehow it seems that instead of the last file I should take the 1st to compare the time against. So I changed this:

var stringDate = Watch.ExpandString("xmlget('/files[1]/folder[1]/file["+numFiles+"]/time[1]',Value,KeepCase,NoTrim)");

to this:

var stringDate = Watch.ExpandString("xmlget('/files[1]/folder[1]/file[1]/time[1]',Value,KeepCase,NoTrim)");

This effectively takes the 1st created file (the oldest).

Thanks!!
9

Yes, your method is certainly valid as well.

Glad to see it provided a suitable workaround for you!