Could someone tell how many times and how often does the Integration Server tries the trigger service if we invoke pub.flow:throwExceptionForRetry?
Does IS try until the service is successful? Is that advisable to implement pub.flow:throwExceptionForRetry for unavailable of webservice. (will IS try until the message is succesfully posted to a webservice?)
Are there any other options to succesfully post to a webservice if its unavailable for longer than expected?
raj,
The throwExceptionForRetry works in conjunction from messages submitted via the broker to an IS service. The settings for the specific IS trigger that is receiving the document controls the number of retries and the backoff time. You will have to trap and evaluate specific error messages that will generate a retry condition. In other words, you wouldn’t want to retry on logic errors but would want to retry connection oriented errors.
Thanks for your feedback. To my knowledge, pub.flow:throwExceptionForRetry can be used only for transient errors (for resource unavailability) and will that service be still invoked if webservice/resource gets unavailable for say 3 or 4 hours?? becos usually retry count is set in seconds and IS might invoke the trigger so many times before thats successful.
Is that a good idea to implement that service in that case either?
and do we need to include that service in catch block? and what happens if it has tried Max attempts and still the resource was unavailable? will that be thrown as any other error into the catch block?
The throwExceptionForRetry is just a wrapper service around the existing error method within webMethods. They introduced this in the 6.1 version. The real error method is ISRuntimeException. Generally a flow service will throw one of two types of errors -
com.wm.pkg.art.error.DetailedSystemException (Runtime) this is the one you want
com.wm.pkg.art.error.DetailedServiceException (Service) logic/data type errors.
Unfortunately not all services or adapters throw the Runtime error, which is why I said you have to make sure your check for it or another type of error that would be considered a runtime exception.
For example The webMethods JDBC adapter will throw a com.wm.pkg.art.error.DetailedSystemException if it cannot connect to a database. You can catch this and then apply the throwExceptionforRetry outside of the catch block. This will cause the document to be resubmitted.
The WmDB adapter will not throw this error. It relies on the jdbc driver to pass back the error in the dbmessage or dbconnection variable. You then have to evalute whether it is an exception for which you want to retry or if it is a logic or data exception. The service will not do this for you. Again the throwExceptionForRetry outside of the catch block.
All of the webMethods adapters and built in services handle this differently. So you have to get to know the adapter or service and what type of errors it throws. There is nothing from preventing you from throwing the throwExceptionForRetry on a data or logic problem. It will put you into a nice endless loop.
Number of retries is really up to you, you can give it a limited number or deliver until successful. Whatever makes you sleep better.
I have a related question on this topic. I’m looping thr. a DocumentList (say have 3 docs that need to be published). I successfully published the first one but failed on the second. Then I use throwExceptionForRetry and I’d like to start the retry at the failed (second) doc rather than at the beginning.
Things that I’ve tried and failed:
set some variable in the doc to skip this the failed one (I think the Broker takes the orig. to work from)
remove the already processed element (related to #1?)
set an independent variable to skip (get reset at the re-start)
Quoc,
You could try using an in memory variable. Set the key and value after each successful publish. These values would not go away after the ExceptionForRetry is thrown. So when the document is resubmitted, have your flow service read in the value in memory to determine it’s course of action. There are some samples provided by professional services folks, I believe the package is called PSUtilities. You can get it from advantage if you don’t already have it.
I’ll look into it. Another way I was thinking about doing this is to write to a file and read it back when it (re-)starts. Don’t know if it’s overly complicated way of doing this or not.
Hello Mark,
You said, “There is nothing from preventing you from throwing the throwExceptionForRetry on a data or logic problem. It will put you into a nice endless loop”.
Is this true even when we retry only until Max count is reached?
Hi,
Did anyone try throwExceptionForRetry for a toplevelservice not a trigger service. It works if toplevelservice is a trigger service but does not work if its just a toplevelservice. I remember document says we can throwexceptionforretry for trigger service and toplevelservice. I am not sure if i understood right. Can any one clarify on this.
Thanks
What would retry your top-level service if it were not a triggered service? IS trigger management does this for triggered services, there is nothing similar to do this for top-level services.
Thanks for clarifying. I was little bit confused when I saw this info in IS built reference guide page 183.
[FONT=PalatinoLinotype][SIZE=2]
“Only top-level services or trigger services can be retried. That is, a service can be retried only when it is
invoked directly by a client request or by a trigger. The service cannot be retried when it is invoked by another service another service (that is, when it is a nested service).”
In my case I have a schedular which talks to db. I want to set retries if there is transient error “Adapter Runtime (Connection)”. Can I do that ?
Another option is to write the wrapper service to do the retries using a repeat structure. You can dynamically configure the number of retries and the wait between retries.
