1. Overview

This technical white paper provides an overview of the configuration details necessary to edit the RX_CUSTOMERS (RXC) table in Responder. It is written for business partners, clients, or other parties interested in learning more about how to configure Responder. This paper describes the configuration for preventing or allowing updates to the RXC table, and the ramifications of editing the RXC data. This document assumes that the reader is familiar with the basic Responder data model as described in the Responder documentation.

2. Configuration

In Responder, the RXC table is used to store customer data; that data relates the customer information to the geodatabase. Most of the data in the table originates from a client’s Customer Information System (CIS), and therefore the RXC table needs to be updated periodically.

2.1 Table Structure

Figure 1 shows the RXC table for Responder version 9.1.2. The table contains basic customer information, such as name, address, phone number, and also contains the DEVICE_OID and DEVICE_FCID fields, which serve as the link between the customer data and the geodatabase. The table is queried for many different purposes, for example: retrieval of data when searching for a customer using the Web Call Entry form, information linking the customer to a specific device, and retrieval of customer information for callback purposes.

 *Primary Key

2.2 Updating the RXC Table

Based on client preference, various fields in the RXC table may need to be updated by the Customer Service Representative (CSR) when taking a call. For example: a customer calls to report an outage and requests a callback. The customer gives the CSR a different number than is listed in the call entry interface; the desired functionality may be to allow the CSR to update the number so the customer information is kept up to date. This update, however, presents a challenge when updating the RXC table from the client’s CIS. If the changes in the RXC table are not propagated back to the CIS, they will be overwritten if the RXC table is truncated and replaced with the latest data from the CIS.

2.3 Locking the RXC Table

To prevent changes from being made to the RXC table that may be lost or overwritten during updates from the CIS, editing the RXC table is disabled by default.

The file WebConfig.xml, located on the web server in C:\Inetpub\wwwroot\Responder, contains the following line:

<WebConfig xmlns=http://tempuri.org/WebConfig.xsd
     TabIdDefault="1"
     TabIdCallEntry="1"
     TabIdCallback="2"
     AllowRxCustomerEdit="false"
     ReportDefault="4"
     ReportPath="Reports" >

The default setting, "false," prevents any editing of the RXC table (see figure 2). Setting this value to "true" will enable editing of the RXC table, therefore allowing changes to phone numbers and callback numbers (see figure 3). It is important to note that once changes are made to the RXC table, precautions must be taken in order to preserve those changes.

Figure 2. The call entry form as displayed when AllowRxCustomerEdit = “false”. None of the phone number fields are editable.

Figure 3. The call entry form as displayed when AllowRxCustomerEdit = “true”. All of the phone number fields are editable and any changes are saved in the RXC table.

3. Update Methods

There are various methods for updating the RXC table from the CIS. The client must choose a method that best fits their needs; since every implementation is different. These methods are beyond the scope of this paper. There are, however, some scenarios that need to be considered when truncating and reloading the RXC table:

3.1 Scenario 1: Active Incidents Exist During Truncate and Reload

The RXC table is truncated and repopulated as part of a periodic update. There are active incidents during the truncation and repopulation. The incident records themselves aren’t affected by truncation and repopulation of the RXC table. However, two other areas related to incident processing can be affected: 1) when callback records are created, the RXC table is used to get the customer’s account number. If the customer does not exist (since the table was truncated) errors may result. Performing callbacks at that point may return a “no customer found” message; 2) customer counts and load point records associated with each incident will not be updated retroactively due to any changes in the RXC table. For example, the addition of a customer downstream of an existing incident will not cause the customer count of the incident to correspondingly increase - this is true whether you use the truncate/reload method or update through the Responder Data Services. (It is, however, possible to “cycle” the incident, i.e., close and re-open the device to update the customer counts).

3.2 Scenario 2: Calls Are Received During a Reload

Calls are received just when the table is truncated, but has not yet been repopulated. If a call comes in when the RXC table has been truncated, the new call will be treated as a call without location. An incident will be created (and related) to the call so that the dispatcher can track it from Responder Explorer. If the RXC table is truncated, there are other scenarios to consider as well: any changes (e.g., restoring, partial restoration, etc.) of an existing incident will lead to inaccurate customer counts. Additionally, if a client uses SCADA integration and a SCADA event creates an incident while the RXC table is truncated or incomplete then your customer counts will be incorrect.

4. Updating vs. Truncating and Reloading the RXC Table

Each method of updating the RXC table has its pros and cons; here is a listing of the major advantages and disadvantages for each of the methods:

4.1 Updating (inset, update, delete, i.e., more transaction-based)

Advantages: Avoids the situations in scenarios 1 and 2 (sections 3.1 and 3.2).

Disadvantages: Difficult to reconcile and/or track changes between the CIS and RXC table; repopulating large databases could potentially take a long time and may reduce the number of updates, therefore reducing the accuracy of the RXC data.

4.2 Truncating and Reloading

Advantages: Ensures the latest CIS information is in the RXC table.

Disadvantages: Fields that may have been updated in the RXC table, such as phone numbers, will be overwritten unless they have been saved or propagated back to the CIS; callback functionality for existing incidents may be adversely affected; calls received during a reload may come in with no location if no customer data is found.

Ideally, edits to the CIS will trigger an update of the RXC table.

Send Comment to ArcFMdocumentation@schneider-electric.com