Pre-qualification Failed Handlers

Overview

A Pre-Qualification Failed Handler is a customer-implemented component used to manage failed feasibility and plan development steps in an orchestrator. During the fulfillment process, the orchestrator optionally calls out to a Feasibility Provider and always call out to a Plan Development Provider.

The Feasibility Provider analyzes the order to determine if it can be fulfilled. If it indicates that the order cannot be fulfilled, then the fulfillment process cannot proceed. The order might be referred to the Pre-Qualification Failed Handler for manual intervention if feasibility error handling is enabled.

Pre-Qualification Failed handler is an optional component in the architecture. Customers might choose to implement full error handling within the Feasibility Provider. In that case it is not valid to return anything back to the orchestrator other than passed in the case of feasibility. If anything else is returned to the orchestrator, there is no handler to process the result, and the plan remains either in a feasibility state.

Specification

Pre-Qualification Failed handlers must conform to the following requirements to be a valid implementation.

  1. Receive event messages on a JMS or REST queue.
  2. Interpret the Pre-Qualification Failed Request event and determine how best to route the failed order for further processing.
  3. Create and send a response event on a JMS or REST queue.
  4. In the response event, specify one of three possible actions that the orchestrator is to take in response to the error: resubmit, retry, or withdraw.

The three actions that can be specified are as follows:

RetryOPD The Pre-Qualification Handler confirms that the order can be processed further. In this case, the Orchestrator sends an order plan generation request to Aopd and moves the order to OPD state.
RetryFeasibility The orchestrator resubmits the order to the Feasibility Provider as it was originally submitted. If this new call fails, the order is sent back to the Pre-Qualification Failed Handler again.
Withdraw The order is withdrawn from the Orchestrator and not fulfilled. It is deleted from the engine and Transient Data Store.

The details of the Pre-Qualification Failed Handler are left as a customer-specific implementation. An example of a handler can be the following:

  1. Receive a Pre-Qualification Failed Handler Request event messages on a JMS or REST queue by a BusinessWorks process.
  2. BusinessWorks starts a process instance in iProcess.
  3. The iProcess process model creates a manual task and displays a form in a work queue for operations support. The form displays the order and the details of the failure.
  4. Operations support reviews the task and chooses one of the following options:
    1. Change the order that allows the order to pass feasibility and the order is processed further.
    2. Update configurations in back-end systems or product catalog that allows the order to pass feasibility. The order feasibility would then retry.
    3. Determine the order is invalid and withdraw the order.
  5. The task is completed.
  6. iProcess then invokes a BusinessWorks service that creates the Pre-Qualification Failed Handler Response event, and populates the event with the appropriate information and flags the response to resubmit, retry, or withdraw as appropriate. This event is then sent on a JMS or REST queue to the orchestrator. The iProcess procedure then terminates.
  7. The orchestrator receives the Pre-Qualification Failed Handler Response and processes it accordingly.