I have been working with webMethods for a short time now and have a high level architectural question about guarantying delivery of documents. Lets look at the following example:
Service A publishes a document to the broker with guaranteed delivery. Service B consumes the document fine, but Service C raises an error after picking it up off the broker. Now that the document is no longer on the broker, Service C has no easy way of re-requesting that document. If I were to re-run the publishing service, application B would have duplicate data.
Am I missing something in this scenario? This level of guarantee seems like it should be a fundamental part of an EAI environment. In webMethods, it appears that if a service raises an error while consuming a document off of the broker, the document is just lost and unrecoverable.
Randy,
service b and service c would be working off different and distinct queues so the success of one has nothing to do with the success of the other(each will have their own copy of the message). They are managed independently. you will have to take steps however to insure that your can resubmit the doc. on error which might include auditing the service, placing code in your service to handle transient errors such as the db is down as well as some types of service exceptions .etc webMethods dispatcher which handles pulling the messages off the queue would normally handle transient errors by throwing a run time exception and retrying automatically for you. however in practice if you use a try catch in your flow service this doesn’t work which is why you would have to trap the transient errors and then retry.
The other important thing to remember is the difference between runtime errors and service exceptions. Service exceptions are generally caused by logic/data problems where as runtime exceptions are caused by the transient type infrastructure errors. It would seem to be a no brainer to auto resubmit runtime errors but the same would not necessarily be true for service exceptions ie no need to keep trying a bad sql statement. Even manually resubmitting data could cause some business type issues because you have now “fixed” the data in the integration layer instead of in the source system. Sometimes this may be okay and sometimes not.
What is the solution if subscribing trigger is not working and are we able to re submit the documents again?
Let say the scenario:
service A publish documents on broker successfully
(publishing service has been developed using try/Catch block and it is 6.1 version)
some how the subscribing triggers is not working
can we able to re publish the data without reading from database again.
If your trigger hasn’t picked up the document it should still be in its Broker’s client queue. When the the trigger is reconnected/fixed it should pick the document up automatically. So there shouldn’t be a need to republish the document in this case. However, if the trigger’s subscription is invalid for some reason and there are no other subscriptions for that document type I believe the Broker will just discard the document, since there are no subscriptions to it. In that case you would need to republish the document from the source application/DB. HTH.
Hello,
You may want to try the publishAndWait. With this, you can publish a document and the service will wait for a reply. Please take care to properly specify the reply as if you don’t the initial service waits forever, so read “Building Integration Solutions Using Publication” for many of the details under Chapter 7. I would recommend that you have the toplevel service work at only being a wrapper service and to do the reply document. In that, if your inner service fails, you can send a reply of such an event and have it republish the initial document again. In fact, you can at that point switch from a publishAndWait to a deliverAndWait since you know exactly who you will later be talking to. So:
You will have an initial publishAndwait, list of services, a central reply service based on join, a deliverAndWait service for retry, the same list of services, a reply-retry service to make sure the direct calls went well. You can contain the retry of the deliverAndWait in a REPEAT step to manage that part.
Good day.
Dead-letter queuing lets you define an explicit webMethods Broker queue for documents that are published to a Broker but do not have existing subscribers. This queue is particularly useful for troubleshooting, as well as for auditing documents that are published to the webMethods messaging backbone.