Hi Everybody
I have some question on TN. I am using TN Primary HTTP as my delivery method. I have a retry parameter set for 2 hours after every 2 minutes. My question is how I can handle a condition if the partner server went down for more then two hours. I checked in my TN that after all retries the processing status was done after 2 hours.
Can anyone give some suggestion how to handle this type of conditions?
John
If the retry fails - the document should get flagged with a ‘FAILED’ status in TN.
You can write sql against the TN database to look for failed docs. (might want to use a date parm)
SELECT *
FROM BizDoc OUTTER INNER JOIN
DeliveryJob ON OUTTER.DocID = DeliveryJob.DocID
WHERE ((DeliveryJob.JobStatus = ‘FAILED’) AND
((DeliveryJob.TimeCreated > ‘04/22/2002’) and (DeliveryJob.TimeCreated < ‘04/24/2002’)))
This will produce a results set that will have a jobid
Then check your row count - branch over the result set
and run wm.tn.task:restartTask - map the resultset jobid to the task id and it will do a restart of the failed docs.
If you can set the dates up as parms - you can schedule this to run as a scheduled job too.
Thanks Mike but when I checked my TN the Processing status is DONE. Mike where will I get this FAILED status.
John
I would have thought once your retry ran out - the document would have gone to a FAILED status in the TASK status, not the USER status. That’s what happens to ours if we try to do an HTTP post to a server that is down, or even an FTP?
I also had a requirement in which I had to send the document to a partner. But if the document is not sent and all retries run out I had to set the document status to FAILED, send an email to a group of users and also take some other optional action.
This is what I cam up with.
Create a contact type in the TN profile and add users to it who need to receive the delivery error notification email. And then create a custom delivery service that calls the pub.client.http service to deliver the document. If the service returns an error code, check the value of the variable retriesRemaining. If its value is 0 set the status of the input bizdoc to FAILED, call wm.tn.route:alert service to send out an error email and then call an error service. You can have different error services for different doctypes and partners configured in a config file or you can have the same service for all of them. If you use the same you can have BRANCH steps dealing with each document type and partner. The service can do anything from retrying the document send to logging the document in a retry database or nothing at all.
It works and is better the the in-built service.
Hi Rupinder
Is there any way I can chage the status to failed with in-build primaryhttp service.
John
“…a retry parameter set for 2 hours after every 2 minutes.”
What are your retry settings? The comment above doesn’t seem to match the settings that are available:
Delivery Maximum Retries
Wait Between Retries
Retry Factor
The combination of these items determines the number of retries and implicitly determines the duration of the retries. Perhaps you’re not seeing “FAILED” because your retries were not yet exhausted?
I agree with Rupinder about using a custom delivery service. We do the same thing since the built-in delivery services don’t have any notification/alert facility.
Hi Rob
I got the TaskStatus as FAILED.I am using the following values…
Delivery Maximum Retries 60
Wait Between Retries 120000
Retry Factor 1
This way it will retries for two hours after every 2 minutes.
The simple answer to your original question (what happens if the server’s down for more than 2 hours?) is: Make your task retry for longer than 2 hours!
You seem to be looking at the TransactionAnalysis Processing status rather than the Task status. Since the Delivery task is asynchronous this status is separate from the actual receipt of the original document. I think you indicated in your last email that you are getting the FAILED status - so you could manually restart these tasks or automate this by checking TN for failed tasks.
I always try to remind people that “Guaranteed Delivery” is supposed to handle ‘transient’ failures. We’ve had clients who’s server will be down for almost the entire day want us to make sure the docs get there ‘guaranteed’. If their server is down for extended periods of time, why not have them pick up the docs when they’re actually up? But then again, I’m an idealist. ;o)
Will
D’oh! I misread and thought you weren’t getting a failed task status. My bad. What Will says is dead on.
This is another reason we use a custom delivery service–we set the User Status of the doc to indicate delivery activity (SENT, FAIL).
I would also recommend changing the retry values so that you’re not banging away every two minutes but backing off for an increasing amount of time after each retry. There is a great .xls file in the shareware area for helping to determine the retry settings.