Feasibility Failed

This is the flow of events through standard order fulfillment with the Feasibility Provider indicating that the order is not feasible. The sequence is shown in the following diagram:

1. The order is submitted from Order Entry through the Orchestrator Submit Order interface. Note that this may use intermediate service layers. The order now has Start status.
2. Orchestrator sends a request to Transient Data Store to store the order. The order now has Submitted status.
3. Cache saves the order and returns a response to Orchestrator. The order now has Feasibility status.
4. Orchestrator sends a request to the Feasibility Provider to perform feasibility checking on the order.
5. Feasibility Provider may delegate the feasibility checking call to AFF Validation as well as perform some internal checking.
6. Validation returns the result of the order validation back to Feasibility Provider.
7. Feasibility Provider aggregates all order feasibility checks and concludes that the order is not feasible and sends a response back to Orchestrator. The order status is now Pre-Qualification Failed.
8. Orchestrator sends the order and the validation messages from the Feasibility Provider to the Pre-Qualification Failed Handler for manual intervention.
9. Pre-Qualification Failed Handler sends a response back to Orchestrator with one of two possible actions:
   1. Withdraw the order, which will terminate execution and the order status is now Withdrawn.
   2. Resubmit the order with an updated version. This flow continues as a normal order amendment flow.

Copyright © Cloud Software Group, Inc. All rights reserved.