A question on Broker

Hi All,

Lets say I have specified a particular publishable doc to be Guaranteed.

I have defined a scheduler which runs on every 2 mins and pulls 200 records from a DB which it sends to a service ( publishing service ) which in-turn converts 200 records data to a document and publishes to Broker. At the subscribing side, we are looping over each record and calling a consumer webService to push the data record by record.

In the 1st run of the Scheduler, when the subscribng service tried to access webService, if the Webservice is down, is the data persists at broker which auto again calls the subscribng service to push the data to Webservice or do we need to explicitly do any work ( My understanding is Broker & IS will take care of failed
documents untill the subscribing service is successful or till the time to live property of doc expires if we use transient error handling )
In the 2nd run of the scheduler, when the subscribng service tried to access webService, it is available, so it pushed all 200 records successfully.

My question is when the webService was down, is the resubmission of all 200 records or records which got failed taken care by Broker or any manual efforts needed.

Thanks a bunch for your time to read this thread and helping me on this topic

Hello All,

Can some one shed light on this thread.


Hopefully, our discussion in this thread, Need inputs for solving my problem - webMethods - Software AG Tech Community & Forums, has answered these questions. If not, let me know.

Just a quick thought: if possible, I recommend publishing the records individually. This will make your application more flexible in case you need to add subscribers later on that are only interested in specific types of records. It will also simplify your error handling on the subscriber side, especially since you’re dealing with a web service.

For example, consider this scenario: on the subscribing side, you’re halfway looping through the 200 records when the web service goes down. This causes you to throw an exception for retry which keeps the document in the trigger queue to be retried. When the web service comes back up, you will try processing that document again, but unless you take some additional precautions, you will end up resubmitting the first 100 records again, potentially generating duplicates.