I have a receive service that takes in a flat file via FTP and persists it to the TN database as a content part of an XML Document, which I later process.
The problem I am having is that the server doing th FTP seems to be waiting for a response from the service after the server has completed FTP’ing the file. This is not a problem if the file being FTP’ed is a small one. When the file is a big file (20 megs or higher), the server doing the FTP times out waiting for a response.
We can see the server doing the FTP wait while the webMethods flow service is writing the file to the TN Database. I have tried using the pub.flow.setResponse service to and setting the response to the response expected by the server doing the FTP “226 ASCII transfer complete.”, but this does not seem to make a difference.
Any ideas on how I can let the server know that the FTP is complete so they can disconnect successfully while letting our webMethods server continue to process the file?
I’m assuming you have a wrapper service that you expose to the ftp client before you send the flat file to TN. This wrapper can call another service that forwards the file to TN as a separate thread. Look at the wm java API - but essentially you can call a Service.doThreadInvoke in a java service.
The side effect is that the ftp client won’t know if the saving process succeeded or not (unless you send them a separate acknowledgement) but they would at least get an instant response.
A potentially simpler solution which I just thought of is to turn off the automatic saving of the document (in the doc type or processing rule settings), make your processing rule asynchronous and then save it in your flow service using the wm.tn.doc:persist.
20MB is very large document and you ahve to use TN large document handling otherwise WM may run out of memery and FTP timeout is just a result if this.
I would sugest not to persist such a big document in TN if possible but if you must may be create a custome serviec to to do this. Run service asynchrouns or invoke thread will send a response back to FTP but WM will still need to read data from FTP IO stream and if your FTP client/server desides to cut this connection I think IO stream will be cut off as well so you will get corrupt document. Perhaps using WM client may be alternative.
I have run into this with larger files as well, and the only way we could get around it without modifying production server settings or spawning a new thread was to force the sending ftp client to extend (increase) it’s timeout value to something like 10 minutes or so. This has corrected the problem as it is now. Of course, when the files grow larger, this solution may not work anymore.