I would like to know why does pub.client.ftp:login is crashing (an error popup appears) instead of returning the details of the error into the output service.
I try to use a do-catch sequence but it does not work. When the error occurs, the service crash and that’s it.
If there is a work around of something I can use. It will be appreciate. I need to be able to identify which file(s) did not works.
The built-in FTP client does not throw a service or runtime exception. Instead it will output errors/messages to a message variable in the pipeline which you must interpret to determine whether you want to throw a runtime or service exception. Works like the WmDB adapter.
However I would be surprised to see a FTP login crashing the IS server. :eek: Maybe if you are past the login and getting a file that is filling up memory or something?
I should read the message more closer next time. :o You said the login service is crashing not the IS. Still the returnmsg field should have the error embedded in it. Have you tried stepping through the service?
Actually I guess they fixed the ftp client in 6.1. That error is trappable by your catch statement. It should jump down into your catch when you hit that.
I just found my mistake. For the first “do”, it was setup to “exit on failure”. I change it by “exit on done” and it works.
do <---------------------- use exit on DONE instead of FAILURE
try (exit on failure)
login
exit (signal SUCCESS)
catch (exit on done)
getlasterror
exit (signal SUCCESS)
The services in the 6.1 pub.ftp.client folder can be a little misleading. If an error occurs, one would think that the error code and error message would be returned via the output variables (ie. returncode and returnmsg.) However, many times, the services themselves will check to see if the return code is greater than 300, and if so, they throw an exception.
This works out nicely (IMO) because you don’t need to litter your code with BRANCH statements after every FTP service call. Nevertheless, it would be nice if webMethods could document this behavior a little better so we don’t have to guess when to check the return code and when not to.
Your first SEQUENCE should be EXIT ON SUCCESS not DONE. If you use EXIT ON DONE for the parent SEQUENCE, then both your try and catch SEQUENCEs will always be executed.
Here is the way I’ve done to know if the login part is working or not.
I have made a service for the login part. At the beginning of the service, I set a field to 500 (it means error for me). After that, I’m trying to do the login command. If it fails, I still have the 500. If it works, I’m looking if the return code is 200. If it is the case I change the 500 by a 200. This way, it is easy to know if it works or not.
When I will upgrade my WM version, the ftp login service will continue to work.