All,
I have a Flow service in 6.0.1 using the standard try/catch sequences:
Sequence (Exit on Success)
Sequence (Exit on Failure)
Sequence (Exit on Done)
When we encounter an exception in an embedded Java service we return a string variable called “Exception”. The calling service branches on this variable and uses an ‘Exit and signal Failure’ step to throw the exception. I know we could just have the Java service throw a ServiceException, but we haven’t gotten to tweaking that yet.
Normally, this works very well and we get clear, focused error messages from the source of the failure. However, I now have a situation where the exception isn’t being found by the getLastError call in the catch block. I’ve traced it, and I can see that the exception is being recognized from the Java service, since my branch steps in to the Exit step. The Exit is set to signal FAILURE and contains a failure-message. Yet getLastError doesn’t return a lastError. Anybody know what might be going on here? TIA.
Oh, a little more on that situation. I noticed that when I execute the Exit step it adds the TN data (TN_Parms, bizdoc, flags, rule, sender, receiver) to the pipeline. This seems bizarre, but I don’t know if it’s part of the problem or not.
That’s good to know Rob, thanks. But my Exit is inside the Sequence that exits on Failure. I can tell that the Exit does indicate failure and that the sequence does exit, because the flow falls through to my catch sequence immediately after the Exit. The first thing in that sequence is getLastError, which doesn’t return anything. Bizarre. While I want to investigate this, I’m going to change the Java service to throw the ServiceException natively to see if that helps. It’ll make my code a little cleaner anyway :-).
I think your outer sequence which exits on success is what’s causing the behavior. This is the behavior I’ve seen. Your approach should to the trick just fine.
I had the same problem. Is this mean we need to throw the SeviceException specifically in the java service in order to get the last error? But what will happen if the built-in service failed. How can we access the error message?
I’ve registered support calls with webMethods on exactly this question before. Apparently the failureMessage that you specify with the Exit step doesn’t qualify as an error for the purposes of getLastError. I was told that there was no way to reliably retrieve the failureMessage value from an Exit step within the same service. Rob’s workaround with ServiceException is exactly the same approach we used.
Lwang, if a built-in service fails, you’ll be able to get the error message normally with getLastError - at least, that’s always worked for me.
Hi. Having a problem with Error (Exception) handling within my flow service (v 6.0.1.)
My goal is to get the flow service pipeline into the audit database so the input document can be resubmitted to the flow service. The problem is that when I go to the Integration Server Monitor web page (WmMonitor) and search for service errors, I don’t see my flow service.
I have the following Audit settings in my flow service:
Enable Service Auditing = Always
When to Log = Error only
When to include input pipeline: On errors only
Here is the structure of my flow service:
I have a Flow service (v 6.0.1) using the standard try/catch sequences:
Sequence1 (Exit on Success)
Sequence2 (Exit on Failure)
Sequence3 (Exit on Done)
Within Sequence 2 (My Try step) I have a REPEAT (with the label “Repeat”) and within the Repeat I have a SQL Insert to a db tbl (using jdbc adapter service).
If the number of retries exceeds the max repeat value then I do an: EXIT “Repeat” and signal FAILURE. This takes me into Sequence 3 (the Catch step)
The first thing I do in Sequence 3 is getLastError. So far so “good”.
My last line in this sequence was: Exit ‘Catch’ and Signal FAILURE.
After reading this thread I tried Rob’s idea about using a Java service that takes an error message as input and then throws a new Service Exception. I invoked this service as the last line in my Sequence 3 (I disabled the step: Exit ‘Catch’ and Signal FAILURE
Long story short: I still don’t see my service in WmMonitor
Hi Wayne,
what do you mean with: “I still don’t see my service in WmMonitor”
If you want to see a “red cross” in your modell you shoul let your service crash with an exception. So you can throw an exception in yout CATCH-BLOCK with EXIT-Failure. So you can make your Errorhandling ind the CATCH-BLOCK and finally throw an exception, so the process fails at this point in the process-modell
Is that what you want ?
Ralf
I am not using Process Models in webMethods Modeler (I just want to see my service show up in WmMonitor)
I have tried using: Exit ‘Catch’ and Signal FAILURE
in the last line of my Catch sequence
and I have also tried using a java service that throws a new Service Exception…but when I go into WmMonitor I do not see my service
Like I said above, my flow service is using the standard sequences:
Sequence1 (Exit on Success)
Sequence2 (Exit on Failure)
Sequence3 (Exit on Done)
In Sequence3 (the Catch) we want to get the last error, publish an error notification document, and then we want the service along with the pipeline to appear in WmMonitor.
As your sequence 3 is “Exit on Done”, no exception will be thrown even if raised explicitly.
You can set a flag in sequence 3 if you want to raise an exception and create another variable which will have the error details from getLastError.
You have to add another sequence with “exit on failure” in the same level as sequence 1 and then u can branch on the error flag to raise an exception using either an Exit step “signal failure” or a “throwServiceException”. This will raise the exception and it will be logged in monitor. You can provide the error details that you got from the get last error as an input to throw ServiceException.
We discovered if we used “Exit $flow and Signal Failure” as the last line in Sequence 3 (our Catch) then the service would show up in WmMonitor.
We previously had “Exit <sequence_3_label> and Signal Failure”. The problem/solution was discovered in webMethods Advantage.
Hi,
I am totally new to webMethods. We have to decide on the error handling Architecture for our project. I am searching for some best practises docs other than GEAR . It would be helpful if I can get some sample flow steps also.
HI pavithra,
Welcome to webMethods. You can find a lot of good articles on error Handling in this forum. Search this forum you can find a lot of them. Basic error Handling can be done by Try Catch blocks which looks something like this…
SEQUENCE(EXIT on SUCCESS)
SEQUENCE(EXIT on Failure) (Try Block)
All your logic should go under this sequence block
SEQUENCE( EXIT on Done)
All your Exception Handling should go in this block (For example you can have getLastError service which catches the last error occured in the Try Block and do whatever you want to do with the error…you can mail the total error to an administrator using the smtp service…or build your custom logic).
There is a lot more for exception handling. Please search the forum you can get very useful inforamtion.
Thanks for that !! I was searching this forum and got good stuff but all seem to centre around this sequence flow steps. I have tried this basic 3 sequence try / catch and it works fine . I wanted still more complex scenarios and solutions. I wanted to try more scenarios before I actually get into development.
Hello,
Pradeep to you about to most useful form of error handling that is not heavily custom. I think it would cover about +80% of your integrations. It follow the Java form of try-catch and the only thing it doesn’t do is the finally in the form Pradeep gave you. For that you can have:
[SEQ]
-[SEQ] ## TEST, exit on Success
–[SEQ] ## TRY, exit on Failure
–[SEQ] ## CATCH, exit on Done
-[SEQ] ## FINALLY, exit on Done
The only other thing that you may be interested in is persistence of the state of the pipeline at the moment of error. Sometimes the getLastError does not have the pipeline stored for me to access. In most, cases all variables defined (above and outside) the “catch” will be visible inside it on error. I think it is because the SEQ does a rollback on variable initializes and assignments on error so the don’t exist or are blank in the CATCH.
Hi,
I am facing a strange problem. I have a small flow service
++ Sequence ( Exit on Failure)
+ pub.web:loadDocument
+ …
++ pub.flow:getLastError
Now I give an empty url for the loadDocument and expect it to fail and I want to capture the error in the getLastError but what happens is, the system throws the exception inspite of calling getLastError. DeveloperUsersGuide says if we use sequence with exit on failure the flow continues with the next flow step. But this does not seem to happen.
If I change the sequence to exit on success then the exception is not thrown.
Has someone faced this situation before ? Am I doing something wrong ( Actually it is not my code) or is it a known webMethods fault ?
Pavithra,
If your call to getLastError is inside the Sequence that is exiting on Failure it won’t get invoked in this situation, because the Sequence has exited. What you probably want to do is place the call to getLastError in a separate Sequence after the one you’ve illustrated. See the examples earlier in this thread for illustrations of the best-practice structure. HTH.
Hi Michael,
I am not calling the getLastError inside the sequence ( refer to the flow steps I had posted). So logically as per webMethods documentation it is a valid service. I understand that it is not the best way of coding. My job is not to correct the structure but to convert the existing architecture to a publish-subscribe model and replace some deprecated methods. So I may not be able to change all these methods using the normal try-catch best practice. There are lots of services ( atleast 150) like this and I just wanted to know the reason so that I can escalate the matter to higher officials. Any suggestions are welcome.
What happens here is totally normal. When you give a blank url, then your load fails (means creates the exception). As it is a sequence (exit on failure), the sequence exits, and give the exception to the upper level, which is the service itself.
A service always behalves like an “exit on failure” sequence, so that your service exits and gives the error to the upper lever, which is the calling service, or developer, or the scheduler …