Hi All,
How do we make sure that guaranteed document is not deleted from trigger document store when there is a failure in the service executed by the subscribe trigger. I wanted to reprocess the same document in case of a failure in the subscribe service.
Env: wm6.1. We are not using Broker.
Please advice.
Regards,
Pauly
Pauly,
See if this service helps: pub.flow:throwExceptionForRetry. It’s documented in the Built-In Services Guide. If you use it, make sure you code your service in a manner that will not cause infinite loops (ie. use throwExceptionForRetry conditionally. ex.: IF retry count < MAX_RETRY THEN throwExceptionForRetry)
Thanks Percio. I do not want to loose the data from trigger store even if the processing service failed after max retry. Any more ideas?
Regards,
Pauly
throwExceptionForRetry is the answer that most use. You need to construct your flow services so that this is throwned outside of your normal try/catch. It will allow the trigger to resubmit automatically the document for processing. Your trigger settings will determine how long the retry will attempt, you can do a few attempts or until successful.
You would only want to trap non-logic related errors in this retry attempt otherwise you will end up in a loop that you can’t get out of. Non-logic would be database not available, web server not available etc. Bad data or bad logic should not trigger this.
If you have a need to resubmit a document that failed because the data is incorrect or the logic is incorrect then you should consider using WmMonitor and auditing. You can set this for success and/or failure and preserve the input pipeline. An important note about this: If you very high transaction volumes, auditing the service will give you a performance hit.
Pauly,
Like Mark said, if you don’t want to lose the data, you can set your audit settings so that the exception is logged to the Monitor database along with the pipeline. You will then have to login to the Monitor to reprocess the data.
One other approach that I have used is that assuming you’re dealing with a transient error that can be fixed on the target system or will fix itself over time, you can suspend the trigger and then resume it once the problem has been fixed. This is helpful in that you don’t get a ton of errors being written to the Monitor and you don’t have to go manually reprocess each one of them.
The resume and suspend services are in the pub.trigger folder of the WmPublic package. These services are available in 6.5, but there’s also a fix for 6.1 that installs them.
Thanks Mark and Percio.
Wouldn’t Exit with failure in the catch block of the service, do the retry even if I set Retries on error/Max attemps value for the trigger?
Do I have to use throwExceptionForRetry only for this? If yes, do I have to use it outside the catch block?
Regards,
Pauly
No exit on failure will not cause the service to retry. The runtime engine of the IS server is looking for a specific type of error to engage the retry capability. It is called a system exception instead of the more common service exception. Your exit on failure will bubble up as a service exception and will not engage the retry capabilities.
The throwruntimeexception must be done outside of your try/catch sequence. You can catch the error in your catch block and then pass it to your steps outside of the catch to evaluate it and see if a throwruntime is warranted.
Seq (exit on success)
Seq(try) (exit on failure)
Seq(catch) (exit on done)
branch on error
throwruntime(if it matches critirea)
or just exit
I should add that the JDBC adapter throws the type of exception for connection oriented or transient failures that you are looking for ie the system exception instead of the service exception. All of the Integration Server adapters don’t do this so you will need to evaluate the error message thrown by the adapters for these transient errors. Ie the http client doesn’t through a system exception when it cannot connect to a web server instead it returns a 40x status code within a variable back to you. Each adapter, service, built client etc behaves a bit differently so you will need to evaluate each one that your are using to figure out how to react to the types and formats of the errors returned for transient failures.
Thank you so much Mark. By the way I am using JDBC Adapter.
Regards,
Pauly