Example Approach
This topic describes an approach for implementing exception handling, where order fallout is managed externally to the TIBCO Fulfillment Order Management implementation. This is a good approach where the customer site has an existing order fallout management system, providing GUI screens, and so on. whose functionality can be leveraged. In the rest of this topic we will refer to this external error handling system as Exception Management, or EM. Please note this is an example only, and may not be applicable for your particular circumstance.
In this case, Functional exceptions are managed via the PIF handler, and Technical exceptions via a separate mechanism.
For Functional exceptions the requirements are to forward all to Exception Management, for an operator to analyze. The possible resolutions are:
- Retry the Plan Item step, with the possibility to edit input values for the downstream call that failed. Note this is different to retrying the plan item from the beginning. Some process components could internally be orchestrating multiple steps.
- Continue the Plan Item, with the possibility to edit output values from the downstream call that failed (note this may not be quite the same as the Complete PIF handler response, which will instruct Orchestrator to complete the plan item. There may be activity that we require the process component to complete after the downstream call but before it completes).
- Rollback the entire order, performing compensating actions if required.
The architectural approach here is to define a clear separation of concerns, between what TIBCO Fulfillment Order Management will do, and what EM will do. The following diagram shows the approach in the case of Functional exceptions. Also, the data access GetPlanItem and SetPlanItem calls are used to support the functionality of editing input/output values.
The Example Functional Exception Handling TIBCO Fulfillment Order Management Components shows an approach for how this could be implemented within the application:
