Hi,
But if I don’t use the concept of Suspend And Retry Latter mechanism, how Broker make sure that failed transactions should be get processed till they successful ?
Any thoughts on this …
Hi,
I have one more thing to check. In the current case as the target is a db I have used sql query to see the DB availability. But lets say if I have a webService, how can we check the availability of the webService.
My thought is to use pub.clint:http, but in this if we give url as www.xxx.com, might be server is up but service or resource on specific port might be down, in this case can we use www.xxx.com:port as part of URL of http service or do we need to use any other way. Kindly help me here as well to get more clarity to handle the situation.
Anil,
If you don’t want to use “Suspend and retry later” but you still want the docs to get automatically retried via this mechanism, you can set the “Retry until” property to Successful, meaning the message will be retried until it succeeds and the trigger will not get suspended. If you go down this route, make sure you have some type of notification in place because if you accidentally throw a “retry” exception for a fatal error, the message will retry forever and it may take you a while to realize there’s a problem.
As for the availability question, the proper way would be to require (or request) your web service provider to expose a ping operation that you can hit. If these are web services that will conform to a WSDL that you will provide, then even better. You can include the ping operation in the WSDL ahead of time.
If that’s not possible, then using pub.client:http to hit the actual HTTP server would be your next best option. You could even use the HTTP method OPTIONS or HEAD to avoid pulling data from the server with a GET, for example.
Percio
Thanks a ton percio for your inputs.
My webService provider team is not giving any thing to ping a webService. Secondly, when I used pub.client:http service and what i pass as http://www.xxx.com/ or XXX Sex - Free Porn Videos at XXX.com, its giving header/status → 200. But its not correct, kindly help me here to know whether server is really up or not.
From your statement, I didn’t understand – Retry until" property. Please elaborate a bit more.
Thanks once again for your help.
Receiving an HTTP 200 OK will tell you the web server is up. If you’re still getting an HTTP-200 but the application running on that server is actually down, then simply looking at the header status code obviously will not be sufficient. You may have to parse the HTTP response being sent back in the body.
As for the “retry until” property, look at your trigger properties. It has a property called “Retry until”. If you don’t want to suspend your trigger after all retries are exhausted (in other words, if you want to keep retrying until success), then set this property to “successful” and it will retry your document until it no longer gets a “retry” exception.
The other option is to set it up so that it throws an exception after the last retry. This means that the current document will be discarded and the trigger will move on to the next one. This is a dangerous option in my opinion because you can easily lose data if you don’t take additional precautions.
Percio
Thanks Percio for your response. Issue is thought the Tomcat server is down http service is giving always 200 status which is absolutely wrong.
Kindly see “weird behavior of pub.client:http - webMethods - Software AG Tech Community & Forums” thread for more details on this.
Thanks once again for your help.
Hi All,
Once again I need your valuable inputs.
Set Trigger properties like below under transientErrorHandling section:
Retry until: Max attempts reached
Max Retry attemps: 5
Retry interval : 10 secs
On retry failure : Throw exception
In trigger flow service as part of finally block: called throwExceptionForRetry service which is been getting executed.
Called the service which published the doc. Subscribing service got invoked and when I tried to call the target end webService, webserver is down where
webService is hosted. In IS logs, can able to see that trigger service is been invoked 5 times when the target end point is unavailable. After this I can see below line
“Exception:com.wm.app.b2b.server.ISRuntimeException: Service Temporarily Unavailable while executing trigger. Rejecting Document for TriggerStore:xxx.publishDocToClient”
Does it mean IS is deleting details of the document which got failed because of transient Error. In this case what is the use of specifiying publishable doc as Guaranteed.
How can I make sure document is delivered successfully even after transienterror happend for a few hours ?
Setting the document to guaranteed ensures that the document is persisted to the disk.
Now, in general terms, guaranteed delivery of a document is only as guaranteed as you make it. If you tell webMethods to “throw an exception” on the last retry and move on to the next document, then of course, the delivery of that particular document is no longer guaranteed.
That is precisely why in my last post I said:
I rarely (if ever) use this option. If a true transient error is occurring (e.g. web service is down), then it makes no sense to throw an exception and move on to the next document because the same transient error will likely occur with the next document, and the document after that, and so on. Next thing you know, you drained your queue and processed nothing.
Percio
Did you check the Broker queue and is the doc stil there or cleared?
Percio, I changed logic. I have same WSDL for different clients. So getting client URL’s dynamically and calling the webService by passing targetEnd URL and other data dynamically each time. So in this case I have same trigger which is sending data to different clients who are sitting on different machines.
@ RMG: Can you plz gimme steps to check Broker Q in MWS. I’m not aware of this.
Thanks for your inputs.
Login MWS:
Adminitration->Messaging->Broker Servers->Servers->click on your Broker list server name->click Brokers tab->Select your specific Broker Name->click on the Clients (Click to view) and you should see all the client id’s (ie the trigger services and a column for Docs Queued will be there and from here you can browse all the stats.
HTH,
RMG
Guys,
No need to look for this document. Once you reach the last retry, if your trigger is set to “throw an exception”, it will throw the exception and acknowledge the document so it’s removed from the Broker queue. In other words, you’re saying “I’m done retrying this document, move on.”
Percio
Percio,
In this case IS should pass on NACK to broker as it could not able to succeeded. Now its Broker turn to give the doc to IS to start processing. Isn’t it ??
Thanks,
Not sure I fully understand what you have in mind. Just to make sure we’re on the same page, when it comes to guaranteed documents, the Broker never really gives a document to the IS. It simply puts a copy of the document on a trigger queue for the IS to pick up. That copy stays there until the IS acknowledges the document to the Broker, which happens in the event of one of these: 1) the document processes successfully, (2) a fatal error occurs, or (3) the maximum retry is reached on a transient error and the trigger is set to throw an exception.
What happened to you is option #3.
So, if I understood you correctly, passing a NACK to the Broker so it “gives” the document back to the IS is really no different than changing your trigger so that instead of throwing an exception, it should just keep retrying the message.
Unfortunately, you’re in a bit of a bind because you have one trigger for multiple web service providers, meaning that an unhealthy web service provider could inadvertently affect delivery to the other ones. For you, it would be great to be able to dynamically create a separate trigger/queue for each provider, but the Broker and IS are not well suited for this (unless we get into under-the-cover APIs, which I would avoid in this case). One product that would come in handy, as I stated previously, is TN, but I’m assuming you don’t have it.
With all this in mind, here are some high-level thoughts on ways you can try to mitigate this issue given your current design:
-
Increase the number of threads on the trigger. This would help minimize the issue because you would have more threads available to process messages for the healthy web services, while the other one is retrying. Of course, if you have X threads and you receive X documents destined for unhealthy web services, you’re stuck. So this would really only work if these types of issues are expected (1) to happen rarely and (2) to be resolved quickly. In this case, you’d probably want to change your trigger to keep retrying the message until it succeeds.
-
Turn on auditing on the trigger service so that you can resubmit errors from MWS. In this case, you can keep the trigger set to throw an exception on the last retry but you would then have to manually resubmit the failed document from MWS. I’m not a fan of this option because it’s manual and you could end up with lots of errors really quickly, making it a nightmare, but I figured I’d mention it just in case.
-
Add logic to your trigger service so that once you reach the last retry, you persist the document somewhere so it can be processed again later. A few options include:
a. Persisting it to the disk or to a database and adding a scheduled task to retry them periodically
b. Publishing them to a separate trigger queue. In other words, documents for web services that are misbehaving would be sent to a different trigger, which could very well execute the same exact service as the primary trigger, but they wouldn’t affect document processing for the healthy web services.
c. Re-publishing the same exact document again. This would put the document back in the same trigger queue but at the tail end, allowing other documents to process in between. If you take this option, you would probably want to add some mechanism to flag documents that were re-published X-number of times to make sure you don’t fall into an infinite loop.
These are just a few options. I’m sure we could come up with more if needed.
Good luck,
Percio
Thanks Percio for your inputs.
Let’s say, there are 100 docs exist in Broker, there are 5 threads configured in trigger and target webService is down.
At this time, if IS also goes down by any reason is the IS able to take those 100 docs and try to push to target webService ?
Thanks,
Yes.
The document is not removed from the queue until the IS acknowledges it. The IS only acknowledges the document once it’s done with it. So, if the IS goes down before acknowledging the document, when it comes back, the document will still be there in the queue waiting to be picked up again.
If anything, in this scenario, you may end up with a document being delivered more than once rather than not delivered at all. For example, consider the scenario where the IS goes down after it has successfully processed the document but before it has acknowledged it.
Percio
YES I agree with Pierco and unless the doc is ack or cleared (manually) the guaranteed docs will not get removed from the queue.
HTH,
RMG
Thanks, i tested and its working as you said. Kindly help me on below question:
I have to send around 30K documents in a day. So set a scheduler which runs every 10 mins and pushes 200 documents to publish.Now, in the trigger I set concurrent processing, thread count 10 and when transient error happens, kept a max retry count of 10 with a gap of 5 mins before each retry.
Kindly suggest is this right approach or any other changes needed in the settings.
Thanks,
PS. To complete one schedule run ( to push 200 docs ) at present, my solution takes 30-40 secs. Kindly help me on the settings which I stated earlier.
Thanks,
Is you trigger configured as Serial or Concurrent threads?
HTH,
RMG