TIBCO Fulfillment Order Management Components for Technical Exception Handling
The Components involved in Technical Exception Handling outlines the components within TIBCO Fulfillment Order Management 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 should be noted however that any component within the TIBCO Fulfillment Order Management can generate a technical exception. This includes those shown below, as well as the core components, such as Orchestrator, data access interfaces, and AOPD.
The following outlines the required behavior of the components that need to be built, in the context of Technical Exception Handling:
Process Component
Technical exceptions occurring during the execution of process components will log a technical exception directly to Exception Management, via the Technical Exception Logger, and stop execution. Orchestrator will not be notified when a Technical exception occurs, and will consider 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 AOPD to get the plan. Like AOPD, the feasibility component can return an error to Orchestrator, if Feasibility fails. Also like AOPD, in the context of the example, a Feasibility error is regarded as a Technical exception, as Feasibility should always pass under normal circumstances (this may 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 should capture all Technical exceptions generated from custom components, and publish them in a standard way to EM. A standard set of exception fields should be published, which should include order ids (if available), the component and service that generated the error, and an error code. The message being processed at that time may also be logged. The key requirement is that there should be enough information logged to enable EM 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 AOPD, 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 may 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 may also communicate directly with Orchestrator, for instance to send a PQF Response message.
The number of resolution types this component can expose, may 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.
