General Approach

TIBCO Order Management - Long Running 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 is not covered here.

Plan Item Failed Handler or no Plan Item Failed 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 Plan Item Failed handler is required.

In the second case, it is necessary to develop a Plan Item Failed handler that receives PlanItemFailedRequest from the Orchestrator for direction on how to proceed once an error is encountered. The Plan Item Failed 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 Plan Item Failed handler might be a better option.

Functional Exception against Technical Exception

Any consideration of exception handling must 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 Order Management - Long Running components such as Orchestrator and Order Management Server. They are typically caused by conditions in the external environment, such as running out of memory, failure in Enterprise Message Service, and hardware failure, but can also be caused by defects.

Different strategies might 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 Plan Item Failed 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.