General Approach

TIBCO Fulfillment Order Management does not include any out-of-the-box approach for error handling. The product architecture does account for exception handlers, and provides the necessary hooks, where it can be integrated with an existing exception or fallout management system, or to which a custom solution can be connected.

The product capabilities for supporting error handling are fully described in the product documentation, and it is assumed that the reader is familiar with that document. The basics will not be covered here.

PIF Handler or no PIF Handler

A key question is whether to handle exceptions within the process component itself, or whether to manage exception handling via Orchestrator and the Plan Item Failed (PIF) handler. In the first case, process components must only return a success result to Orchestrator, and no PIF handler is required.

In the second case, it is necessary to develop a PIF handler, that receives PlanItemFailedRequest from the Orchestrator for direction on how to proceed once an error is encountered. The PIF handler must respond to Orchestrator telling it whether to Retry the plan item, or Continue (that is, mark the plan item as completed and continue with the plan).

A consideration here is the type of process component. If a process component makes use of a workflow engine for its implementation, which already includes manual tasks and GUI interaction, it would make sense for errors in the flow to be managed within the workflow engine, rather than have them passed back to Orchestrator. If the process component is BW or BE, the PIF handler might be a better option.

Functional Exception against Technical Exception

Any consideration of exception handling should consider the different types of exception that can occur, which typically fall into two broad categories, Functional exceptions, and Technical exceptions. For the purposes of this discussion, we define these as follows:

  • A Functional Exception occurs when a back-end system returns an error code to the process component, indicating a problem with the request. Functional exceptions always occur in the context of a process component. An example could be a request to allocate a phone number that is already in use. Receiving a Functional Exception is expected to occur under normal circumstances, and the system is built to handle these events.
  • A Technical Exception occurs when something goes wrong, so that the system is not designed to handle under normal circumstances. They can occur in process components and also TIBCO Fulfillment Order Management components such as Orchestrator, OMS, OPE, and so on. They are typically caused by conditions in the external environment, such as running out of memory, failure in EMS, hardware failure, and so on, but can also be caused by defects.

Different strategies may be considered for each of these types. For instance, as Functional Exceptions occur within the context of a process component, and would typically require an operator to review and decide on remedial action, it makes sense for these to be handled via the Orchestrator and a PIF handler, which might defer to an external GUI for a resolution.

Technical exception handling is more difficult, as they can be caused by almost anything. In this case, even if a Technical exception occurs in a plan item, it might make more sense to simply log it and stop execution of the plan item.