4 Managing Fallout Work Orders Using the Order Control Application

Work orders can fail due to a number of factors including missing parameters, requests that are not valid, switch problems, or telephone lines that are in an unprovisionable state. Work orders that fail because of hard errors are called fallouts and can result in:

• Customer inconvenience

• Loss of business

• A network element remaining in an unsynchronized state

Oracle Communications ASAP can automatically correct soft errors, but it cannot correct hard errors. Hard errors must be analyzed to determine the cause of the fallout. After analyzing the fallout, you can identify what must be corrected or changed. The process of analyzing and correcting work orders is called fallout management.

To make the fallout management process more efficient, you can develop strategies for quickly analyzing and correcting failed work orders.

Your system administrator can set up ASAP to provide as much or as little detail about a problem as you need. If you find that the system error logs do not contain enough useful information, your system administrator can reconfigure the error logs.

Determining the Cause of Work Order Failure

The search function in the Order Control Application (OCA) enables you to search for failed work orders. Failed work orders are identified with a status of Failed or All Failed in the Status field of the Work Order Query window.

To determine the reason for a work order failure:

1. In the Work Order Query window, search for work orders with the status Failed, All Failed, or Failed in Translation.

   For more information on searching for work orders, see "Searching for Work Orders".

2. Select the work order you want to investigate.

3. In the Work Order Query window, from the Work Order menu, select Details.

   The work order details window appears.

4. Select the required Common Service Description Layer (CSDL) to view the CSDL parameters, CSDL and Atomic Service Description Layer (ASDL) history, and the work order properties.

   The results appear in the lower section of the CSDL tab.

5. When you have determined the reason for the work order failure, correct the error and resubmit the work order for provisioning.

   
   

   Note: Instructions on correcting and releasing work orders are contained in the following sections.

   
   

Analyzing Fallouts

Analyzing fallouts is the most important step in the fallout management process. By analyzing a fallout, you can determine:

• Why the work order failed.

• Whether the problem can be corrected immediately, or if it can only be corrected by a network administrator.

To analyze fallouts, you can:

• Search for Failed or All Failed work orders in the Work Order Query window.

• Review the CSDL events displayed in the CSDL tab of the work order details window.

• Review CSDL details.

• Review the events listed for the work order to determine at what point in the provisioning process the failure occurred.

• Review the ASDL history and switch response logs to understand the point in the provisioning process at which the work order failed.

Common Fallout Scenarios

This section covers scenarios in which work orders fail during production. These examples are for reference only. The problems and messages you encounter depend on your implementation of ASAP.

Fallouts are caused by a number of factors. The most common scenarios are:

• Incorrect CSDL or global parameter values

• Unsynchronized data

• Improperly sequenced CSDLs

• Operational errors

  
  

  Note: If a work order allows delayed failure, the order finishes processing before reporting the failure. In this case, you must carefully analyze the CSDL and ASDL history for each CSDL in the work order.

  
  

Scenario 1: Fallouts Caused by Incorrect Parameter Values

A work order can fail because of an incorrect CSDL parameter value. The incorrect value can be an invalid Line Equipment Number (LEN), an incorrect telephone number, etc.

For example, a service representative submits a work order to activate a new telephone line. When the work order reaches the Network Element (NE), the NE informs ASAP that the number is already in service, and the work order fails.

To correct incorrect parameter values:

1. Search for the failed order.

2. Select the failed work order in the Query Results section of the Work Order Query window.

3. From the Work Order menu, select Details.

4. Select the failed CSDL.

5. From the CSDL menu, select Retry.

   A copy of the CSDL (with the status of Initial) appears. The status of the failed CSDL has changed to Aborted.

6. Examine the CSDL history and ASDL history for the failed CSDL.

   For example, the CSDL history may indicate that the telephone number in the work order is already in use.

   Compare the Directory Number (DN) in the CSDL to the DN in the host system database. Potential causes of the fallout are:

   • The DN may have been incorrectly entered.

   • The number was disconnected, but no one entered this change into the system. Therefore, ASAP registers the DN as being in use.

   • The incorrect LEN may have been specified.

   • The number is still in use.

7. To update the CSDL parameter value, select the CSDL for which you want to modify a parameter.

   For more information on editing CSDL parameters, see "Retrying CSDLs".

8. In the CSDL information section of the CSDL tab, click the CSDL Parameters tab.

   The CSDL parameters already associated with the CSDL are displayed.

9. In the CSDL Parameters tab, select the CSDL parameter that you want to modify.

10. From the CSDL menu, select Parameter, then select Update.

    The Input dialog box appears.

11. In the New Value field, enter the new value.

12. Click OK.

    The CSDL parameter value is updated in the CSDL Parameters tab.

13. Repeat steps 7 to 12 for each parameter you need to change. Do this only if the work order contains more than one incorrect parameter value.

14. After you have corrected all parameters, release the work order.

    For more information on releasing a work order to the provisioning queue, see "Releasing Work Orders for Provisioning".

Scenario 2: Fallouts Caused by Unsynchronized Data

A common cause of fallouts is unsynchronized data. This occurs when the following databases do not contain the same information:

• The host system database

• The Service Activation Request Manager (SARM) database

• The network element database

For example, a service representative submits a work order to add call waiting to a customer's line. When the work order reaches the NE, call waiting is detected on that line and the order fails.

To correct unsynchronized data:

1. Search for the failed order.

2. In the Query Results section of the Work Order Query window, select the failed work order.

3. From the Work Order menu, select Details.

   The work order details window appears.

4. From the CSDL menu, select Retry.

   A copy of the CSDL (with the status Initial) appears below the original.

5. Examine the CSDL history and ASDL history.

   In this example, the switch response indicates call waiting was not added to the line.

6. Resubmit the work order.

   The work order completes, but no services are added.

   At this point, information from the NE is sent back to the host system. The service representative can then determine when call waiting was activated on that line and, if necessary, why the customer has not been billed for this service.

   
   

   Note: This type of problem is a soft error; it should not cause a fallout. If problems like this continue to occur, contact your development department. They can rewrite the appropriate ASAP State Table to ensure work orders do not fail when they encounter this type of error.

   
   

Scenario 3: Fallouts Caused by Improperly Sequenced CSDLs

CSDL events in a work order must be in a proper sequence. This sequence determines the correct order in which ASAP adds services to customer accounts. If CSDLs are not sequenced properly, the work order fails.

For example, a service representative submits a work order to:

• Add fax access to the line (with the CSDL C-CREATE_FAX_ACCESS).

• Create a new line (with the CSDL C-CREATE_BUS_LINE).

If the CSDLs are sequenced as above, the work order will fail because the CSDLs are not properly sequenced. You must activate a telephone line before you can add fax access to it.

To correct improperly sequenced CSDLs:

1. Search for the failed order.

2. In the Query Results section of the Work Order Query window, select the failed work order.

3. From the Work Order menu, select Details.

   The work order details window appears.

4. From the CSDL menu, select Resequence.

   The Resequence – CSDL dialog box appears with the CSDLs displayed in their current order.

   For more information on resequencing CSDLs, see "Resequencing CSDLs".

5. Resequence the CSDLs in their proper order.

   In this example, place C-CREATE_BUS_LINE before C-CREATE_FAX_ACCESS.

6. Click OK.

7. Release the work order to the provisioning queue.

   For more information, see "Releasing Work Orders for Provisioning".

Scenario 4: Fallouts Caused by Operational Errors

Operational errors can occur if:

• A new NE is added to the system but is not activated.

• There is a spelling mistake in the NE identifier.

When work orders fail because of operational errors, a message similar to the following one appears on Switch History/Events Property sheet of the Details – WorkOrder window:

Network Element Routing Error, Failed SRQ xxxx

Where xxxx is the number of the service request.

For example, due to a lack of available telephone numbers, a city using the 416 area code adds the 905 area code to its outlying regions. To handle the new area code, the telco adds a new NE but does not activate it. A service representative submits a work order to activate a line in the 905 area code. However, the work order fails because the NE to which the work order was routed is not operational.

To correct operational errors:

1. Search for the failed order.

2. In the Query Results section of the Work Order Query window, select the failed work order.

3. From the Work Order menu, select Details.

   The work order details window appears.

4. From the CSDL menu, select Retry.

   A copy of the CSDL (with a status of Initial) appears.

5. Examine the CSDL history and ASDL history. Because the problem was caused by an NE routing error, check the MCLI parameter in the CSDL Parameters tab of the CSDL tab in the work order details window. Compare the name of the NE shown in the CSDL Parameters tab with a list of operational NEs.

   In this example, the work order failed because the new NE was not activated. Therefore, ASAP views the NE as being non-existent.

6. Contact a network administrator to activate the required NE.

7. Click the failed CSDL, then from the CSDL menu, select Retry Failed.

   A copy of the CSDL (with the status of Initial) appears below the original.

8. Release the work order to the Hold or Review queue.

   For more information on releasing a work order, see "Releasing Work Orders for Provisioning".

9. When the NE is activated, release the work order to the provisioning queue.

   For more information, see "Releasing Work Orders for Provisioning".

Handling Other Provisioning Errors

This section discusses situations in which work orders fail, but in which detailed fallout management is not necessary. These situations are:

• A work order fails after it is corrected.

• Network elements become unavailable.

• Release of multiple work orders.

A Work Order Fails after It Is Corrected

After you have corrected a fallout, the work order may still fail. Possible reasons for the work order failure are:

• You corrected the problem but caused another problem.

• The work order contains several errors, some of which you may have missed.

To correct this problem:

1. Abort the work order, then re-enter it using either:

   • The OCA Order Entry function

   • The upstream order entry system

   For more information on the Order Entry function, see Chapter 2, "Creating Work Orders Using the Order Control Application." For more information on releasing a work order, see "Releasing Work Orders for Provisioning".

2. Release the new work order to the provisioning queue.

   For more information, see "Releasing Work Orders for Provisioning".

Network Elements Become Unavailable

Network elements become unavailable:

• During scheduled NE blackout periods.

• When a connection to an NE is not established within a user-defined interval.

• When a port failure occurs.

When ASAP cannot establish a connection with an NE, work orders will time out but do not fail.

If NEs become unavailable, contact your network administrator to learn when the NE will become available. If another NE is available, you can edit the work order and then resubmit it to another NE.

Releasing Multiple Work Orders

When several work orders fail because of network problems, adjustments to individual work orders may not be required. You must release them to the provisioning queue when the network problem has been resolved.

Releasing a large number of work orders individually can be time consuming. However, with the OCA client, you can simultaneously release multiple work orders.

To release multiple work orders:

1. Search for the failed work orders in the Work Order Query window, then do one of the following:

   • To select all the failed work orders, from the Work Order menu, select Select All.

   • To choose multiple work orders, hold the Ctrl key and click the work orders to release.

2. From the Work Order menu, select Release.

   The Release dialog box appears.

   
   

3. Change the release settings as required and click OK.

4. Repeat step 3 for all work orders.