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 Fulfillment Order Management components, process components, and any other code that may 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 may 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 will never be able to catch all types of errors.
The underlying principle here is, as with Functional exceptions, Technical exceptions will 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 will expect an argument “Resolution Type”, which is a string that will define 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, enrichment processes, and so on, to ensure Technical exceptions are caught and logged in a consistent way. We define a single “Publish Technical Exception” service for TIBCO Fulfillment Order Management 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 Fulfillment Order Management internal components, or even a PQF error.
When publishing an exception to EMS, TIBCO Fulfillment Order Management will need to publish along with the exception, all the information that it would need to handle the resolution.
