I posted the same query under a different category but didnt get a satisfactory response. can anyone help?
we have several integrations where messages are picked up from a queue by an adapter for posting to a database. If the database goes down, the messages are not retained on the queue. Is there any configuration setting that can be changed so that instead of discarding the message from the queue, it is retained if the end resource that the adapter connects to is down?
Thanks,
Munna
Munna,
I hope I understand your question right, it was not very clear. You can configure the trigger for this:
In developer, when creating a trigger, you will have to specify the broker queue type. This can be set to guaranteed or volatile.
Setting the queue to guaranteed should do the trick.
HTH
Loic
Loic,
Actually the broker queue type has been set to “guaranteed”. For some reason, when the database is down, the messagee is not retained on the adapter queue. Looks like when the adapter picks up the message from the broker queue, the broker does not wait for an ack back from the adatper to know if the message has been successfullly posted to the database ornot.
Thanks,
Shahida
Munna guaranteed delivery does not extend beyond delivery of the document to adapter, what u do after u get the document is not broker’s concern. You would have to either design your integration to handle this or use webMethods audit logging features to save failed integrations with pipeline data for later resubmission.
Hi Munna,
we use Broker to realize a guaranteed delivery to 3rd party systems
trigger
Deliver until: successfull
we have a trigger for each 3rd Party system
Each trigger is linked to a generic service, which has to make a guaranteed delivery.
This service is configured with a customizable configuration file, where all informations about the 3rd Party system is held. e.g. number of retries, Channel name and of course the name of third party transmitting service.
In the case the transmitting service signals an error (meaning 3rd party system is down) the generic service throws pub.flow.throwExceptionForRetry.
This prevents the broker from taking the message out of the broker.
Hope this helps
joe