Software AG Products 10.7 | Integrating On-Premises and Cloud Applications | Guaranteed Delivery | Overview of Guaranteed Delivery | Handling Failures
 
Handling Failures
If a non-transient error prevents your client application or service from receiving the results from a service request, your application will receive an error message.
Records remain in the job store for a transaction until the client application or service explicitly ends the transaction. To avoid exhausting the job store, a client application or service must make sure to complete all the transactions it starts, or a site must establish administrative procedures to address failed jobs.
TContext can return the following types of errors:
*AccessException. The client application or service either supplied invalid credentials or is denied access to the requested service.
*ServiceException. The service encountered an execution error.
*DeliveryException. The Job Manager failed and became disabled. An administrator should be notified to correct this problem. For client applications, code your client application to notify an administrator when this type of error occurs. After the problem is corrected, re-enable the Job Manager using the TContext.resetJobMgr( ) method.
For services, guaranteed delivery notifies the administrator identified by the watt.server.txMail configuration setting. After the problem is corrected, re-enable the Job Manager by executing the pub.tx:resetOutbound service.
*IllegalRequestException. The client application or service made an invalid request; for example, supplied an invalid transaction ID (tid) or other invalid parameter.
*TXException. A failure occurred with the transaction. The transaction timed out, hit the retry limit, or encountered a heuristic error. Typically, this type of error indicates that the transaction became inactive either because the time-to-live (TTL) value elapsed or the retry limit was met. To distinguish between these two errors, use the isExceededRetries( ) method.
Heuristic errors will only occur if you altered the default configuration of webMethods Integration Server to fail PENDING requests when webMethods Integration Server is restarted after a failure. Use the isHeuristicFailure( ) method to determine if a heuristic error occurred.
Note:
A heuristic error does not guarantee that your transaction was not executed, only that its results could not be returned. Keep this in mind if you are processing transactions that must be executed once and only once (for example, an application that enters purchase orders or pays invoices). You might also need to implement additional mechanisms in your client application or service to ensure that a transaction does not get posted twice.