Hi,

We are using Transaction MQ connections with Asynchronous notifications and Configured triggers for publishable documents.

In the trigger we specified the maximum number of retires.

In the case the trigger retired for maximum number of times and still the message was not sent successfully(or if the IS goes down before the trigger process the document) the message would be left in the Document Store.

In this case how can i retrieve the documents from the document store for reprocessing.

We are not using the broker .So if many messages fail it may be a problem for the Document Store to handle all of them. So we want to process the documents in the Document Store on a Scheduled basis.

Thanks a lot in advance
-Kiran

When the IS was restarted it would resume processing documents in the document store that had not exceeded their retry limit. No need to schedule anything.

If you want a solution more robust than the IS document store use Broker.

Mark

Mark,

Say if the message is retried for maximum number of times but not successfull.Then what happens to the message.Can i retrive it from the Document store?

Thanks a lot.
Kiran

Messages that exceed the max retries are deleted from the store. You could, of course, check the retryCount and publish them to another “queue” or written to a database table for some type of second chance or dead letter processing.

Mark

Thanks Mark,

May be this should help.So programatically in the Service i can check the retryCount and if it is max could persist it to an alternate storage.Can you please point me how to get the retryCount of a message.

-Kiran

Got it. May be this should help. pub.flow.getRetryCount.

Thanks
Kiran

That’s the one. Of course, you need to be using the pub.flow:throwExceptionforRetry (see many forum posts on this topic) and not just exiting your Flow with an error condition.

Mark

The question is, if the maxRetryCount is exceeeded, but you don’t really want to throw the document away (or signal an error for manual intervention) then why not increase that setting? Why devise yet another storage and retry mechanism?