Plan Item External Error Handlers

Overview

Plan Item External Error Handler is a customer-implemented component used to manage failed plan items. During fulfillment, the Orchestrator requests plan item execution from a Process Component. When execution completes, the Process Component may specify one of three result conditions:

  • Execution completed successfully
  • Execution completed, but with error
  • Execution did not complete

Successful execution results in the plan item being flagged as Complete and execution continuing with the next items in the plan.

Error or incomplete execution means that the plan item has not been successfully completed and therefore the next items in the plan should not begin execution until the conditions that caused the failure are rectified.

Orchestrator does not distinguish between an incomplete execution and an error response when determining how to handle the failed plan item. Both are handled the same by invoking the Plan Item Error Handler and indicating which failure mode returned. The semantics of how to determine whether a Process Component is incomplete or in error is left to a customer-specific interpretation and implementation. The implementation between Process Components and the Plan Item Error Handler should be consistent.

Plan Item Error Handler is an optional component in the architecture. Customers may choose to implement full error handling within the Process Component. In that case it is not valid to return anything back to Orchestrator other than success. If anything else is returned to Orchestrator, there would be no handler to process the result and the plan remains in an execution state without progressing beyond the failed plan item.

Specification

Plan Item Error Handlers must conform to the following requirements in order to be a valid implementation.

  1. Receive event messages on a JMS queue.
  2. Interpret the Plan Item Failed Request event and determine how best to route the failed plan item for further processing.
  3. If necessary, distinguish between incomplete execution and error response execution and interpret the Error Handler field in the Plan Item Failed Request and direct the plan item to the correct handling component.
  4. Create and send a response event on a JMS queue.
  5. In the response event, specify one of three possible actions that Orchestrator is to take in response to the reply: retry, resume, or complete.

The three actions that can be specified are as follows:

Retry The plan item is resubmitted to the Process Component to start over from the beginning. This occurs immediately upon receipt of the Plan Item Failed Response event as all dependencies have been previously satisfied. The Process Component is notified to re-execute the plan item through a Plan Item Execute Request event. If Orchestrator has been automatically set up to retry failed process components, and this retry fails as well, the retry count is not reset to zero. In other words, if the retry from a Plan Item Failed Handler response fails, then that failure is immediately redirected back to the Plan Item Failed Handler for processing again as a new failed plan item, and not automatically retried further.
Resume The plan item is resumed in the Process Component from the point of failure. The implementation details of this are left for Process Component design. However it is conceivable that the Process Component may choose to handle a resume the same as a full retry if it is not functionally possible to resume execution from the point of failure. The Process Component is notified to resume the plan item through a Plan Item Activate event.
Complete The plan item is considered to be completed and not resubmitted to the Process Component. Orchestrator marks the plan item as Complete and processing continues. Any dependencies on the newly Completed plan item is evaluated and further plan items triggered as in the normal execution.

The details of the Plan Item Failed Handler is left as a customer-specific implementation. An example of a handler could be the following:

  1. Receive a Plan Item Failed Handler Request event message on a JMS queue by a BusinessWorks process.
  2. BusinessWorks starts a process instance in iProcess.
  3. The iProcess process model makes a service call out to Transient Data Store to retrieve the order.
  4. The iProcess process model creates a manual task and displays a form in a work queue for operations support. The form displays the order as well as the details of the failure.
  5. Operations support reviews the task and chooses one of the following options:
    1. Make changes to the order which allow the order to process successfully in the Process Component. The changed order is then saved in TDS and the plan item may be retried or resumed.
    2. Make changes to back-end systems that allow the order to process successfully in the Process Component. The plan item may be retried or resumed.
    3. Implement the required functionality for the plan item manually in the back-end systems. The plan item may be completed.
  6. iProcess then invokes a BusinessWorks service that creates the Plan Item Failed Handler Response event, populates the event with the appropriate information, and flags the plan item to complete, retry, or resume. This event is then sent on a JMS queue to Orchestrator.
  7. Orchestrator receives the Plan Item Failed Handler Response and processes it accordingly.