Technical Exception Handling
For Technical exception handling, it is difficult to define a pattern that always can apply, given the diverse range of possible exceptions that can be raised. Such exceptions can be raised from anywhere – TIBCO Order Management - Long Running components, process components, and any other code that might be developed as part of a total fulfilment solution.
It is of course always good general software engineering practice to build components as resilient as possible to errors. It might make sense, depending on the context, to build in mechanisms such as retry, when events such as timeouts occur. Of course, this needs to be weighed up against the additional complexity this introduces into the solution, and needs to consider the idempotency of interactions. Complex, built-in “self-healing” type mechanisms themselves increase the risk of coding defects, increase the complexity of testing, and is never be able to catch all types of errors.
The underlying principle here is, as with Functional exceptions, Technical exceptions require manual inspection to determine what to do. The default approach is that all technical exceptions are also dealt with manually. This can mean messages being manually copied from one queue to another, database entries being manually edited, and so on.
Nevertheless, it is highly desirable, in some common circumstances, for a fulfilment system to be able to resolve technical exceptions in an automated way. No system can be built to automatically resolve all exceptions, however one approach is to build a mechanism that can support incremental addition of automated technical exception resolutions, as the system evolves and experience is gained into the types of exceptions that can occur, and how best to deal with them. This section outlines a possible approach to building such a mechanism.
As with the handling of Functional exceptions, it is important to define a clear architectural separation between the fulfilment system and the system that determines what to do with exceptions. Again, we term this body Exception Management, see Technical Exception Handling Architecture Overview.
To simplify the interface, we define here a single “Resolve Exception” service, which is used to resolve all Technical exceptions. It expects an argument “Resolution Type”, which is a string that defines what specific resolution behavior is required.
It is good practice when building custom components of a fulfilment solution, such as the process components, any database adapters, and enrichment processes, to ensure Technical exceptions are caught and logged in a consistent way. We define a single “Publish Technical Exception” service for TIBCO Order Management - Long Running to use when publishing a Technical exception. This same service would be invoked regardless of the source of the Technical exception, which can be custom code, TIBCO Order Management - Long Running internal components, or even a Pre-Qualified Failed error.
When publishing an exception to Enterprise Message Service, TIBCO Order Management - Long Running needs to publish along with the exception, all the information that it would have to handle the resolution.
