Data Flow Details
Overview
This section discusses in detail the data flows that are relevant to the Generic IVR Adapter. The data flows generally involve bilateral database tables that are populated or polled by the adapter or stored procedures that access internal NMS tables directly. The adapter data flows are turned on through command line switches, but the actual data transfer may be affected through the use of stored procedures.
Trouble Calls
New trouble calls need to be sent to Oracle Utilities Network Management System to apply the outage analysis algorithm to predict the outage device. The Generic IVR Adapter provides the submit_call stored procedure to pass trouble call information from the external application to Oracle Utilities Network Management System.
There are two PL/SQL packages available for interacting with the Generic IVR Adapter. Package pk_ivr_interface allows a full range of functionality provided by the adapter to be used. Package pk_ccb, which supports integration of NMS to Customer Information System (CIS), provides procedure for submitting trouble calls through Generic IVR Adapter.
Data Flow Characteristics
The following are characteristics of the Trouble Calls Data Flow
Data Flow Steps
1. The external application invokes the submit_call stored procedure to submit a trouble call.
2. The submit_call stored procedure inserts the trouble call in the TROUBLE_CALLS table. Upon insertion, the TROUBLE_CALLS.CALL_STATUS field will be set to 'N' signifying a new trouble call.
3. The Generic IVR Adapter polls a configurable number of new records from the TROUBLE_CALLS table within a configurable poll period. The TROUBLE_CALLS.CALL_STATUS field is updated to 'I' (in progress) signifying that the trouble call is in the process of being submitted to the NMS Job Management Service (JMService).
4. Once processed, the retrieved records are submitted to NMS' JMService so the outage analysis algorithms could be used for the submitted trouble calls. The TROUBLE_CALLS.CALL_STATUS field is updated to 'C' (complete) signifying the trouble call has been successfully submitted from the external application to NMS.
Below is a summary of the information required to submit a trouble call via the pk_ccb.submit_call stored procedure.
If no numeric trouble code is provided, the default trouble code, which is generally a 1 followed by however many zeros are necessary to satisfy the project defined trouble code, will be used. The length of the trouble code is defined by the number of distinct "group_order" entries in the srs_trouble_codes table.
Note that the pr_trouble_calls stored procedure is also provided to accomplish essentially the same goal - inserting a trouble call record into the trouble_calls table.
The pk_ccb.submit_call stored procedure is used to submit:
• Trouble calls for a particular customer (known premise/service point). This includes entering the meeting time for job site appointments when there needs to be a planned outage to perform non-utility work at a location, such as tree removal near a power line or house painting.
• Fuzzy calls
When a fuzzy call is created at least one of the following call identifiers must be provided:
• The caller's name
• The caller's phone number
• The caller's ID.
• Location must also be provided.
A location can be either
• A street intersection (by providing two street names)
or
• A street segment (by providing a block number and the street name)
City and State are optional
Callback Requests
A customer may request that they be called back as soon as the outage that they reported has been restored. The Generic IVR Adapter provides the stored procedure pr_trouble_callback_requests to be used by an external application that is managing the callback process. This procedure returns a list of calls where the customer has requested a callback.
Data Flow Characteristics
The following are characteristics for the Callback Request Data Flow:
Data Flow Steps
1. When an outage with a corresponding callback request is restored, Oracle Utilities Network Management System builds a callback list.
2. From the list, callback requests could be assigned to callback agents or to the external application, either in a manual (using Oracle Utilities Network Management System Web Callbacks) or an automated manner (via SRS rules).
3. The Generic IVR Adapter retrieves all callback requests assigned to the external application and inserts the callback requests to the TROUBLE_CALLBACKS table. The PROCESS_STATUS field of the callback request in the table would be set to 'N' signifying that the callback request is new. The CALLBACK_DONE field of the callback request in the table would be set to 'N' signifying that the callback has not yet been done.
4. The Generic IVR Adapter provides the pr_trouble_callback_requests stored procedure, which picks new callback requests from the TROUBLE_CALLBACKS table.
5. The external application could use the pr_trouble_callback_requests stored procedure to pick new callback requests. Callback requests that were picked are marked with a PROCESS_STATUS field equal to 'I' (callback response in progress) on the TROUBLE_CALLBACKS table.
Callback Request Notes
Once an outage event or a non-outage event is restored, callbacks are generated if the call is marked for a callback. All events have a restoration, either explicit or implicit, so any event can generate a callback. Also, in the event that the customer called multiple times, the customer will receive multiple callbacks if he requested a callback on each call. JMService gathers every call associated with an event, without filtering duplicate callers. Every call that is marked for callback will receive a callback.
Callback Responses
The external application calls the customer to confirm if power has been restored or not. The result of this call is passed from the external application to Oracle Utilities Network Management System via the pr_trouble_callback_responses stored procedure.
Data Flow Characteristics
The following are characteristics of the Callback Responses Data Flow:
Data Flow Steps
1. The external application calls the customer to confirm if power has been restored. The result of this call is passed back to Oracle Utilities Network Management System via the pr_trouble_callback_responses stored procedure.
2. The stored procedure uses the incident number and premise ID combination (or the external ID and premise ID combination if the first combination is not provided) to identify a callback record in the TROUBLE_CALLBACKS table that would be receiving a response.
3. The stored procedure updates the identified callback in the TROUBLE_CALLBACKS table by updating the following fields:
• The callback's CALLBACK_DONE field to 'Y' signifying that the callback was already done.
• The callback's CALLBACK_TIME field. CALLBACK_TIME field defaults to the system date if no value was provided.
• The callback's CALLBACK_STATUS field with the appropriate callback response code.
4. The Oracle Utilities Network Management System Generic IVR Adapter queries the TROUBLE_CALLBACKS table for new callback responses received and sends this information to Oracle Utilities Network Management System.
5. In Oracle Utilities Network Management System, the callback could get completed or cancelled or a new event (with the original call information) will be created, depending on the callback response.
Callback Response Notes
When a callback is made and no response from customer is received, a callback time will still be recorded. Any callback time that is submitted with a status is propagated, even if the status is no reply from the customer. It is understood in this case to be the last attempted callback. Also, when a nested outage is found, the new call and event are backdated to the original outage time.
Note: NMS does not track callback history.