We need to implement the best error handling technique to log errors when posting the xml files to a Web Service. we need valuable suggestions for the following scenerios.
Here is what we were thinking if the web Service becomes unavailable for some reason (to log errors):
“Post the failed XML documents to a DataBase. Write another flow service which is scheduled to run say every half an hour
(poll for the failed docs) and if there are messages, try to post again to a webservice. This time if that’s a success, delete the document from DB; else keep trying the same.”
But we are worried on how to handle the above case in the following situations:
"If the first failure generates a trouble ticket, and then you retry, and then again fail, will all of these failures keep generating trouble tickets?
Could there ever be a situation where you legitimately don’t want one of those records to reprocess?
If so, will there be a facility to not retry that one? Such as, a database column to disable, etc.
Will there be a need for some way to reprocess these ‘on demand’ and not on the schedule (what if you have thousands of errors and want to search and see which ones need to be reprocessed)?
If on demand will be necessary, will you need a GUI to do it, and what will this GUI be like, and is there more work involved for creating it?
Will there be a need for some way to view the content of these messages that failed and selectively run or reprocess them (what if you have thousands of errors and only want to reprocess a few hundred)"
Could anyone please suggest the best implementation for the above scenerio.
Check the GEAR6 Error Handling Guide (Download it from Advantage site)if it helps.
Also look at sample.errorHandling:approach1 and approach2 in the WmSamples package for two approaches to exception handling. Generally we prefer use approach2 which creates a try-catch block through Sequence statements.
we dont wish to use debug Log for scrutinizing errors and thats the reason why we are thinking to go for a better technique/s. what is your opinion on the idea we had (logging errors onto a database and polling it).
went thru error handling guide but doesnt think we find the best solution.
In one of the client we used to log errors to DB depends on the InterfaceName(this is unique example:SectorName_001)and documentType.
So we created a table for just logging the errors (network errors,transient errors,mapping errors etc…)and another table for storing the xml’s as a blob and depends on the interfacename,TransactionSeqNumber,documenttype,update statusflag(P=Processsed,F=Failed etc)and everyday we scheduled a service which will and pull the xml’s which ever status is “F” for reprocessing and upon the results we have loop thru it and invoke the main service.once it is successfull finally we update the statusflag to “P” depends on the TransactionSeqNumber.
This would seem to be a good scenario in which to use Trading Networks. It has automated and manual retry facilities. You can control retries by partner (though not doc type). You can log all activity, not just errors.
We implemented TN and used custom delivery services to provide transport (http, ftp, mq, soap, smtp) and error notification. The notification alerts were structured such that on first occurrence, an e-mail/page was sent. If the same type of error occurred within a configured timeframe (10 minutes) then an e-mail would not be sent.
You should take a serious look at using TN. At the very least, you could mimic some of its facilities with your own and not completely reinvent the wheel.
We used an other approach for error handling!
This technique is not popular and is not documented.
Our error handling is base on the use of triggers.
The trigger send the document error “pub.publish.notification:error” when the associated service failed.
The document contains :
the error message
the parent context ID
the client sender
the error message is a technical message, like this :
com.wm.pkg.art.error.DetailedServiceException: [ART.117.4002] Adapter Runtime (Adapter Service): Unable to invoke adapter service test.insert:insertSimple. [ADA.1.316] Cannot execute the SQL statement “INSERT INTO TOTO(NOM, PRENOM) VALUES (?, ?)”. " (23000/1401) ORA-01401: valeur insérée trop grande pour colonne " ORA-01401: valeur insérée trop grande pour colonne
(sorry in french but it said value too long for column)
if the service was audited, you can extract xml data from wmMonitor and replay service with the parent context ID
Using this error handling, you don’t need to make try catch on database service for example, and it also see the OutOfMemory error, bug developpement.