Manage FTP error

I’m using webMethods Integration Server version 4.6 on jdk 1.3.

in my webMethods service I perform into a try block the following FTP command:


into the catch block I call the pub.flow:getLastError in order to retrieve the sessionKey
and try to close the ftp connection using the service pub.client.ftp:logout

Sometimes the ls or the get comamnd fails (an error is throw) but into the catch block the
pub.flow:getLastError return an empty exceptionInfo record so it’s impossible to retrieve
the sessionKey and close the ftp connection.

Any suggestions?


Hello Marco,

I strongly recommend the implementation of a java service which uses
for example the Jakarta commons libraries (
etc.; see code example below).


  1. better performance
  2. more reliable (better exception control)
  3. more ftp options
  4. better to build ‘good’ FTP reply protocols
  5. code can better be structured and made readable

Well, good luck Marco!



Code example:

String serverHost = “…”
String serverPort = “…”
String userName = “…”
String password = “…”

protocol = protocol +“Connect to " +serverHost +”:" +serverPort +“.\n”;
ftpClient.connect(serverHost, Integer.parseInt(serverPort));
protocol = protocol +ftpClient.getReplyString() +“\n”;

  protocol = protocol +"Login as user " +userName +".\n";
  ftpClient.login(userName, password);
  protocol = protocol +ftpClient.getReplyString() +"\n";


thanks a lot for your suggestion

… I believed that the webMethods FTP services were sufficiently strong and reliable :frowning:




I would have to disagree with Andre’s advice to custom code FTP services in Java. One of the advantages of using Integration Server is the pre-built [and tested/supported] services that come out of the box. Using pre-built services means that other developers [who maybe are not Java gurus] can come along and easily (visibly) understand what your code does, and how to make changes.

While I’m not saying this is always the case, I have seen quite a number of projects become overly complex and unsupportable by ignoring built-in services and reconstructing everything in Java. One of the big positives of using webMethods software is the quick implementation times, re-working (and re-testing) everything from ground up often leads to delays. I have seen numerous customers implement extensive FTP integrations using the built-in services very successfully.

So, back to your original question. You say that some errors result in a blank lastError, do you know which particular errors cause this situation? You may be best to log the issue with technical support once you isolate what particular errors cause this situation. I did find one fix to 6.0.1 that sounds similar, does this match what you are seeing? [if so, mention it in your support request and ask if a fix for 4.6 exists]:

If there is an error in a transformer, the service pub.flow:getLastError may incorrectly return a null when it should return a lastError object.

This happens if there a multiple transformation in a MAP step and one of the transformations before the last transformation raises an error. Subsequent transformation which complete successfully clear this error which causes the pub.flow:getLastError service to incorrectly return null."



didn’t want to say that is impossible to use wM Flow (we used it successfully for three years, too). However, using Java the code will be better maintainable - presuming you are familar with Java!!
Generally using wM Flow is in fact a good practice, we do that in more that 95% too. However the FTP implementation in wM is a bit weak if you use it in a complex setup (many partners with diffrent FTP setup).

Whatever you decide to do.

Good luck!



thanks a lot for your suggestions
I agree with you about using more possible the built-in services.

my webMethods service has not multiple transformers into a MAP step so I don’t think that fix that you suggest can
resolve my problem.

I would like to specify that during the last tests I have noticed that if I set up a wrong value about the input parameter transfertype for the login service
(e.g. attive rather than passive), I get what I have previously described.