|Oracle® Communications Order and Service Management Concepts
Part Number E35415-02
|PDF · Mobi · ePub|
This chapter describes Oracle Communications Order and Service Management (OSM) order fallout handling
Order fallout occurs when an order fails during processing. Order fallout is often called order failure. Fallout management is the ability to resolve fallout and allow an order to continue processing. You can model automated fallout management, which corrects errors by compensation, or you can model manual fallout management, which supports manual intervention to correct errors.
OSM can manage fallout that occurs both internally during OSM processing, such as errors in internal data, and as the result of an error returned by an external fulfillment system. The most common fallout scenarios are:
Failure in a downstream system; for example, a failure in an activation system. Scenarios include:
The data was received, but was missing or incorrect and could not be processed. When a downstream system detects missing or incorrect data received from OSM, it returns an error, which in turn fails the order.
An internal error unrelated to the data occurred.
See "Managing Fallout Generated from a Failure in a Downstream System" for more information.
Failure in a network or system resource; for example, a network connectivity failure or a database failure. See "Managing Fallout Generated from a Failure in a Network or System Resource" for more information.
Failure when an order is created in OSM; for example, recognition or validation errors. If OSM receives a corrupted order from an external system, it accepts the order but immediately places it in Failed state. See "Managing Fallout Generated from Failure When an Order Is Created in OSM" for more information.
Failure in run-time OSM execution; for example, an unresolved dependency that prevents an order from being processed. See "Managing Fallout Generated from Failure in Run-Time OSM Execution" for more information.
Managing fallout typically follows three stages: detection, notification, and recovery.
Detection. You must be able to detect when an order has failed. For example:
A process can transition an order to Failed state. When it does, you can specify to send a message to a fallout specialist.
Order management personnel can monitor the progress of an order in the Task Web client or in the Order Management Web client. For example, the progress of an order might indicate that something failed. If an order uses orchestration, a problem in an order component can prevent dependant order components from processing.
When an order is identified as fallout, the order state is typically changed to the Failed state.
Notification. Depending on the error, you might need to notify other systems that a problem occurred and why. For example, the CRM system must know if an order has failed because of incorrect data. You can configure OSM to send email notifications to fallout managers or to notify an external trouble-ticketing application.
Recovery. Corrective measures can be taken automatically or manually to fix the problem and then resume or restart the order. Using the Order Management Web client, you can search for failed orders and examine their data to determine the cause of the error.
Order recovery can be carried out in various ways. For example:
A revision order can be submitted with corrected data. For example, if an order fails because the specified type of telephone is not available, a revised order can be submitted that changes only the type of telephone for the order.
Order management personnel can edit the order data in the Task Web client and resume processing of the order.
The order can be terminated and a new order submitted.
OSM in the central order management role can function as the central fallout management system, coordinating fallout activity for all of the order processing in your system. For example, in an order-to-activate solution, OSM can be integrated with the Siebel Service module and other systems. In such a solution, OSM might do the following:
Receive error information from fulfillment systems. This can include receiving errors from OSM running in the service order management role.
Generate trouble tickets in a trouble-ticketing system when there is order fallout.
Issue updates to trouble tickets for multiple issues on the same order item.
Update trouble ticket status when milestones are reached, such as when an issue is resolved.
If your OSM implementation includes both central order management and service order management, order fallout can occur and be managed in both instances. An order failure can affect each role independently, or the same failure can affect OSM running in both roles. For example:
An error returned from a billing system can fail an order in the central order management role without affecting service order management.
An error returned from a provisioning system can fail an order in service order management, and, if the provisioning is part of an order component, the failure might create an unresolved dependency in central order management.
Failures from a downstream system are typically caused by the following:
An invalid message request caused by insufficient or incorrect data.
The request cannot be completed because of the state of the user's account; for example, an inactive account.
The network inventory does not represent the resources in the actual network; for example, a port has been assigned that is already in use.
An internal application has occurred in the downstream system.
These scenarios typically must be resolved directly; retrying or waiting does not resolve the problem.
A failure in a downstream system is usually detected by using an automation plug-in. The failure message is received in the JMS receiver queue and correlated to an order and task context. Details about the failure are stored in the order data.
Note:OSM can maintain a history of the communications with external systems. However, because of the work that OSM must do to manage and store the messages, this can impact performance.
In addition to automated detection, order managers can use the Web clients to find failed orders.
Notification of fallout from failures in downstream systems is typically handled by the following:
Generating a trouble ticket in a trouble-ticketing application.
Sending the failure information to the order-source system.
Sending email notifications to fallout administrators.
Notifications can be based on changes to order milestones, order data, task states, or task status. See "About Notifications" for more information.
To recover from a failure in a downstream system, actions include:
Set the order state to Failed. This is often called a hard failure. This stops all processing on the order while recovery is undertaken. You can then resolve the problem in the downstream system. When it is fixed, reset the status of the order to In Progress by, for example, using the ResolveFailure Web services operation.
Set the failed task to a user-defined failed status. This is often called a soft failure, because the order is not failed. The order remains in the In Progress state, and other tasks can still be carried out while the recovery is managed. To correct the problem, you can manually complete the task or reset the state of the task to Received, which retries the task.
Transition the task to a manual fallout recovery task. This provides a specific set of data that applies to redoing the task. You can then transition the failed task back to the Received state to retry it. This option is not always applicable, because it can require the order manager to maintain data integrity instead of allowing OSM to handle the compensation.
Change the order to the Aborted state and resubmit it from the order-source system.
With all of these options, you can specify query tasks and roles to restrict the recovery to fallout managers.
A failure in network or system resources is typically one of the following:
Network connection failure
Fulfillment system down or running slow
These failures are usually temporary, and can be resolved by waiting or addressing the network problem. Order processing might be delayed, but is usually not otherwise affected.
These failures can be detected by using an automated response notifying OSM of the failure. These failures are usually handled by a jeopardy notification, triggered by a task or order not completing in the expected amount of time.
Network and system failures are usually managed by the network administrator or system administrator. They usually do not affect the status of the order; the order retries processing and resumes when the network is available. A typical recovery scenario is as follows:
The automated task receives an error.
The automation framework fails the transaction, rolls the transaction back, and sends a JMS message to the queue.
The transaction is retried. You can configure how many times to retry and how long to wait before retrying.
When the configured limit or retries is reached, a JMS error message is sent to the queue. (The default configuration is unlimited retries and no error sent.)
Failures in order creation can occur because of the following:
Failure when the CreateOrder Web services operation is used, usually while processing a validation rule or transformation rule. The order fails, and the original incoming customer order is attached. You can publish an event based on order failure.
In the case of validation errors, revise the order request and resubmit it. In the case of transformation errors, troubleshoot and fix the transformation logic, and resubmit the order.
Failure when the CreateOrderBySpecification Web services operation is used, usually because the input data is not valid or permissions are not correctly set. The error response can be:
The error response includes error details.
If either of these two faults is returned, revise the order and resubmit it.
The order is a revision order, and the point of no return based on order state transition has been reached on the base order. In this case, TransactionNotAllowedFault is returned. If you have configured a follow-on order for this scenario, you can submit the follow-on order. Otherwise, you can submit a new order.
You can specify to display a message in the Task Web client if an order fails during validation and transformation. To do so, specify the fail-order reason when you model the recognition rule in Oracle Communications Design Studio.
Tip:An order that fails to be recognized by any recognition rule is rejected by OSM and lost. No record of it is sent to the order-source system. To make sure that all orders are captured in OSM, create a recognition rule that accepts all incoming customer orders. Prioritize it at the lowest level (0) and prioritize all other recognition rules higher so they are processed first. Using this lowest-level recognition rule, an invalid order is recognized, and then it fails during validation. It then transitions to Failed state and is kept by OSM.
Recognition rules are global entities. An incoming customer order could be recognized by a recognition rule deployed in the system that you did not intend to be matched if you are not careful with the relevancy settings and the recognition rule.
Failures in run-time OSM execution are typically caused by OSM modeling errors, usually in the design of automations, rules, and orchestration. These errors are usually resolved in test systems and should not be a common occurrence in a production system.
A failure in an automation results in an exception. You can configure how the error is handled; for example, fail the order, transition the task to a user-defined failed state, or transition to a fallout recovery task.
A failed rule results in the associated tasks being marked as INVALID. Notifications are provided as system events, displayed in the Task Web client.
Orchestration failures typically result in incorrect or empty orders.
When an order fails, the Fail Order transaction transitions the order to the Failed state. An order can transition to the Failed state from the following states:
Waiting for Revision
When the problem is fixed, the order can be moved out of the Failed state as follows:
If the order was failed from the Not Started, In Progress, or Waiting for Revision states, the Manage Order Fallout transaction moves the order back to the state it was in before being failed.
If the order was failed from the Suspended state, the order is transitioned back to the Suspended state.
If the order needs a revision to be fixed, the Submit Amendment transaction places the order in the amendment queue, after which the Process Amendment transaction transitions the order to the Amending state. A revision can come from two sources:
The originating order-source system can enter a revision order.
A process exception, which includes redo and undo operations, can run.
If the order must be restarted, the Cancel Order transaction transitions the order to the Cancelling state, and then to the Cancelled state. This operation undoes all changes and returns the order to the creation task.
Note:If the order has an orchestration plan, it cannot be restarted after being canceled. The Cancelled state is a final state for orders that have an orchestration plan.
If the order cannot be revised or restarted, the Abort Order transaction transitions the order to the Aborted state.
See "About Managing Order States and Transitions" for more information.
The following example shows how fallout management combined with amendment processing can resolve an order failure:
A customer places an order for 8 MBps DSL service. The customer service representative takes the order but neglects to find out if the service is available before entering the order in the system.
OSM receives the order and begins processing it. It sends fulfillment requests to the various fulfillment systems (for example, billing, mobile provisioning and DSL provisioning).
The DSL provisioning system receives the request for HSD 8 MBps, but it cannot support that speed. It responds with an error.
At this point, the order is still in the In Progress state. This allows other components to continue processing. However, the order has an expected completion date that is not met, so a jeopardy notification is sent to the order manager.
The fallout manager receives the notification and opens the order in the Order Management Web client. Upon reviewing the order, the order manager sees that the fixed provisioning, mobile provisioning, and their respective billing functions are complete, but the DSL Provisioning function remains in the Started state.
Upon investigating the DSL provisioning order component, the order manager sees that the DSL provisioning system returned an error code of “1” and a message of “Not enough speed for HSD 8M”.
A status update is sent to the CRM system alerting the order entry personnel that a problem has occurred, and the 8 MBps speed is not available. The order remains in the In Progress state, but no further processing can happen until the DSL provisioning is resolved. There is no reason for the fallout manager to suspend or fail the order at this point.
The CRM system sends a revision order, which is based on the original order. Instead of an 8 MBps speed, the revision order requests a 1 MBps speed.
OSM receives the revision order, processes it, and the order resumes.
A typical fallout management configuration allows you to do the following:
Follow a predefined recovery process for orders. To do so, you can configure processes and tasks that fallout managers complete in the Task Web client. The fallout recovery tasks allow you to edit the order and then manually transition the order back into processing.
Configure amendment processing to handle changes that are reinstated from the originating upstream system, such as revision orders and order cancellation. See "Managing Changes to Orders" for information about amendment processing.
Model failure flows into your processes. For example, a failure flow might consist of these steps:
Wait for amendment.
Model orders that are specifically designed to handle order fallout. For example, you might create an order type that collects data about an incoming customer order that failed, with processes and tasks that allow a fallout manager to interface with a trouble-ticketing application.
Recognize incoming error messages from external systems and use them to trigger notifications in OSM.
Alert internal fallout managers and external systems about order failure and recovery status. To do so, you can configure event notifications.
Define roles to allow specific users to handle fallout-management tasks.
Create automated fallout messages based on order milestones. Figure 11-1 shows an automated fallout message triggered by the exception order milestone.
You can use the Order Management Web client to review failed orders to determine why they failed. You can configure fallout entities in Design Studio to specify the data that you want to display in the Order Management Web client. To do so, when modeling an order, create a fallout entity and include it in the order model. A fallout entity includes one or more data elements that you want the Order Management Web client to display.
Figure 11-2 shows a fallout configured in OSM. In this example, the fallout is named PortAlreadyAssigned. It is used when a task for activating a service fails because a port was assigned that is not available. The data element is asdl_service_details/port_id.
After you configure fallouts in the order specification, you can assign those fallouts to manual tasks that need them. This association enables OSM to identify the task that generated the error, transition the order to the Amending state, and initiate amendment processing.
To resolve fallout, OSM follows the same process as when it performs amendment processing: It builds a compensation plan, and then applies the required changes.
Figure 11-3 shows a fallout assigned to a manual task.
Fallout can be triggered based on a single incorrect field in a single task. Because fallout can be mapped to one or more data elements, it is possible to have multiple errors in a single task view.
You can also create fallout groups to simplify assigning fallout data to orders. A fallout group is a group of fallout specifications, each of which includes a set of data to display in the Order Management Web client. This enables you to review multiple fallouts together in the Order Management Web client when the corresponding types of fallout occur.
To trigger fallout in an automated task, use the XML API FalloutTask.Request through com.mslv.oms.automation.OrderContext.processXMLRequest.
You can configure fallout-management processes and tasks to enable your fallout specialists to manage fallout by using the Task Web client. Fallout management tasks include such tasks as submitting and responding to trouble tickets, resubmitting orders, failing orders, and undoing tasks following a failure.
Figure 11-4 shows a fallout process (OrderCreationFalloutSubprocess) included in the AIA Order-to-Activate fallout cartridge. This process manages the fallout in the event of an order creation error. For more information, see OSM Cartridge Guide for Oracle Application Integration Architecture.
In addition to creating processes and tasks specifically to manage fallout, you can add failure flows to any type of process; for example, provisioning processes.
You can use both the Order Management Web client and the Task Web client to manage order fallout.
You typically use the Order Management Web client to examine order dependencies and history to determine the cause of the failure. You can also manually suspend or fail an order. See "Managing Fallout in the OSM Order Management Web Client".
You typically use the Task Web client to run fallout management tasks; for example, fallout recovery tasks that use undo and redo tasks. See "Managing Fallout in the Task Web Client".
Both clients can be used for fallout management, but the primary differences are:
You use the Order Management Web client to search for orders that have failed and find problems based on orchestration; for example, unresolved dependencies. You can view the problem that is causing the order to fail, but you cannot resolve the order failure by changing order data.
You use the Task Web client to manage problems with tasks and processes; for example, you can manage failed orders by redoing and undoing tasks. You can change order data that may resolve the order failure.
For orchestration orders, you sometimes must work in both clients to manage fallout because you require both an orchestration view and a task-level view of the order. For example, you must find and examine an order component of an order in the Order Management Web client and then drill down to the worklist to see the task-level view of the order component's tasks in the Task Web client.
Each client can launch the other client when required. To learn more about navigating between the clients so you can quickly access the orchestration view and task-level view of an orchestration order, see the getting-started discussions in each Web client's user guide.
In the Order Management Web client, you can do the following:
Find orders that are in the In Progress state but have components that have not started because a dependency has not been resolved. An unresolved dependency can indicate a problem in the fulfillment process.
Find orders that are in the Failed state.
View details about the order to determine why it failed. For example, you can look for unresolved dependencies or display the order history.
To correct the error that caused the failure, you often must use the OSM Task Web client to run fallout-related tasks, such as fallout recovery tasks. You might also need to work with external systems. There is no functionality in the Order Management Web client to manually run tasks.
While resolving the order failure, you can suspend the order to prevent processing on it. You can resume the order when you are ready to resolve the failure.
After the problem has been resolved, you use the Order Management Web client to resolve the order. When you do, you enter a description of how the order was resolved in the Resolve Order Failure dialog box. The order state is reset to In Progress.
Note:If the order failed because of a recognition rule failure or after reaching its point of no return, it cannot be resolved. Also, the ability to suspend, cancel, or terminate an order depends on its life-cycle policy.
Figure 11-5 shows the Resolve Failure dialog box. Using this feature does not perform the steps required to resolve the failure; it tells OSM that the problem has been resolved and that the order can be resumed.
If you cannot resolve the order, you can use the Order Management Web client to cancel or terminate the order:
Canceling an order immediately stops its processing and sets the order state to Canceled. Any tasks that have already completed for the order are rolled back. If the order has an orchestration plan, the order cannot be resumed. If the order does not have an orchestration plan, it can be resumed.
Terminating an order immediately stops its processing and sets the order state to Aborted. The order cannot be resumed. Unlike canceling an order, terminating an order does not roll back any tasks that have already completed. As a result, clean-up may be required.
Note:Consider the impact on other systems of canceling or terminating orders. Depending on how your solution is configured, upstream systems may not be aware that an order has been canceled or terminated.
In most cases, orders are failed automatically. You can also use the Order Management Web client to fail an order manually. Failing an order stops its processing and sets its state to Failed. It is not possible to change the state of a failed order or to make other changes until you resolve the order failure. Orders you fail manually are treated the same way as orders that are failed automatically by the system. They are considered fallout.
Note:In most environments, fallout-handling rules detect processing problems and automatically fail orders. Manually failing orders is not normally required. There may be some situations and environments when it is necessary to manually fail orders, however.
Make sure you understand how other systems in your order processing solution handle failed orders. Depending on how your solution is implemented, upstream systems may not be aware that an order has been manually failed.
You can initiate fallout in the Task Web client by raising an exception. An exception is a mechanism used to interrupt or stop an order or to redirect it to any task in the same process or any other process. You can use two types of exceptions: process exceptions and fallout exceptions.
You can use a process exception to stop or redirect an order. Process exceptions are typically part of the configured order flow and can be used to manage the order manually. Figure 11-6 shows the Process Exception page in the Task Web client. In this example, an error has been made in the order processing, and the process exception redirects the order to correct it.
You can use a fallout exception to initiate fallout to correct an error. A fallout exception allows you to initiate fallout from a particular task to correct an error caused by a previous task. When you raise a fallout exception, the system identifies the task that generated the error, transitions the order to the Amending state, and initiates amendment processing.
To recover from order fallout, the order might require a revision order to redo some of the order processing. Figure 11-7 shows how the system manages compensation tasks due to fallout.
In this scenario, Task B is responsible for the error and Tasks C and D include the error data. The fallout exception is raised at Task G.
In this figure:
An order is processed using the above workflow following the path A, B, C, D, G.
A fallout exception is raised at Task G.
OSM determines that Task B first output the error and initiates amendment processing as follows:
Same branch: If, during the redo processing of Task B, the task completes with the same completion status as it did in normal processing, subsequent Tasks C and D are also redone and the flow is complete.
Different branch: If, during the redo processing of Task B, the task completes with a different completion status causing Task E to be the next task, the obsolete branch of Tasks C and D must be undone and the new branch of Tasks E and F must be done while still in the Amending state.
Note:If the error data was generated by the creation task, the order transitions to the Failed state. No compensation tasks are created and the order must be corrected through an external amendment.