TIBCO Order Management - Long Running Components for Technical Exception Handling
The Components involved in Technical Exception Handling outlines the components within TIBCO Order Management - Long Running that would be involved in handling technical exceptions. Note that the other components not directly involved in the solution for technical exception handling are not shown.
It must be noted however that any component within the TIBCO Order Management - Long Running can generate a technical exception. This includes those shown below, and the core components, such as Orchestrator, data access interfaces, and Automated Order Plan Development.
The following outlines the required behavior of the components that have to be built, in the context of Technical Exception Handling:
Process Component
Technical exceptions occurring during the execution of process components logs a technical exception directly to Exception Management, via the Technical Exception Logger, and stop execution. Orchestrator is not notified when a Technical exception occurs, and considers the Process Component to be in “Execution” state. The process component can be retried or continued by the Technical Exception handler, or the Technical Exception handler can notify Orchestrator directly that the Process Component is complete.
Feasibility
The Feasibility step is invoked by Orchestrator after it has received and stored the order, but before it invokes Automated Order Plan Development to get the plan. Like Automated Order Plan Development, the feasibility component can return an error to Orchestrator, if Feasibility fails. Also like Automated Order Plan Development, in the context of the example, a Feasibility error is regarded as a Technical exception, as Feasibility must always pass under normal circumstances (this might not typically be true though, for instance if order validation is performed at Feasibility).
Technical Exception Logger
This component publishes Technical exceptions to Exception Management. It must capture all Technical exceptions generated from custom components, and publish them in a standard way to Exception Management. A standard set of exception fields must be published, which must include order ids (if available), the component and service that generated the error, and an error code. The message being processed at that time might also be logged. The key requirement is that there must be enough information logged to enable Exception Management to choose a resolution type to be applied to resolve the exception, and enough information to be passed back to the Technical Exception Handler for it to be able to resolve the exception.
Pre-Qualification Failed (PQF) Handler
Its role is to receive notifications that Orchestrator publishes when it receives an error from Feasibility or Automated Order Plan Development, and publish them to Exception Management.
Technical Exception Handler
Its role is to expose the service for resolving Technical Exceptions for Exception Management to call, and to implement the logic for performing the resolution. This might involve sending messages to a process component, or to perform some custom action (such as clean up a database table and resubmit an order). It might also communicate directly with Orchestrator, for instance to send a Pre-Qualification Failed Response message.
The number of resolution types this component can expose, might grow over time as new resolutions are added.
The Process Component Technical Exception Services Overview outlines at a high level, how the Retry, Continue and Complete services could potentially be implemented.
