Hi,

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?

Thanks for ur valuable inputs in advance.

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.

markg
http://darth.homelinux.net

Mark,

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?

Please clarify my basic doubts
Thanks.

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.

markg
http://darth.homelinux.net

Hi All,

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:

1. set some variable in the doc to skip this the failed one (I think the Broker takes the orig. to work from)
2. remove the already processed element (related to #1?)
3. set an independent variable to skip (get reset at the re-start)

Any ideas?

Thanks in advance.

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.

markg
http://darth.homelinux.net

Thanks Mark.

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.

Thanks again.

QN

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?

Thanks
Srini

Hi Srinivas,
No if you set the max retry, it will keep you out of the endless loop.

markg
http://darth.homelinux.net

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.

Mark

Thanks for clarifying. I was little bit confused when I saw this info in IS built reference guide page 183.
[FONT=PalatinoLinotype][SIZE=2]

[/size][/font]

I believe by “client request” the documentation is referring to a IS Java API client that can check the type of exception that was thrown.

Mark

How can set I retry for my service which is a schedular service for transient errors ? Any ideas…

Create a wrapper service which does what you want (maybe by publishing a doc to be picked up by a trigger) and schedule that instead.

Mark

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.