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 Orchestrator. During the fulfillment process, Orchestrator would optionally call 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 may be referred to the Pre-Qualification Failed Handler for manual intervention if feasibility error handling is enabled.

The Plan Development Provider designs a plan from the order. If a plan cannot be designed then the fulfillment process cannot proceed and the order may be referred to the Pre-Qualification Failed Handler for manual intervention if OPD error handling is enabled.

Pre-Qualification Failed Handler is an optional component in the architecture. Customers may choose to implement full error handling within the Feasibility Provider and the Plan Development Provider. In that case it is not valid to return anything back to Orchestrator other than passed in the case of feasibility and success in the case of plan development. If anything else is returned to Orchestrator there is no handler to process the result and the plan remains either in feasibility or OPD state.

Specification

Pre-Qualification Failed 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 Pre-Qualification Failed Request event and determine how best to route the failed order for further processing.
  3. If necessary, distinguish between feasibility and plan development failures and direct the order 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 error: resubmit, retry, or withdraw.

The three actions that can be specified are as follows:

Resubmit The Pre-Qualification Failed Handler sends back a new orderRequest that Orchestrator resubmits automatically. This is handled as a pre-execution order amendment and execution begins from Submitted state. An audit history of the original order is maintained in the Transient Data Store. In order to resubmit, the orderID and orderRef in the new order must match that of the original order.
Retry Orchestrator resubmits the order to either the Feasibility Provider or the Plan Development 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 will be withdrawn from Orchestrator and not be fulfilled. It is deleted from the engine and Transient Data Store.

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

  1. Receive a Pre-Qualification Failed Handler Request event messages on a JMS 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 as well as the details of the failure.
  4. Operations support reviews the task and chooses one of the following options:
    1. Make changes to the order that allows the order to pass feasibility and plan development. The order should be resubmitted.
    2. Update configurations in back-end systems or product catalogue that allows the order to pass feasibility and plan development. The order may then be retried.
    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 queue to Orchestrator. The iProcess procedure then terminates.
  7. Orchestrator receives the Pre-Qualification Failed Handler Response and processes it accordingly.