Responder - ESRI Replication Support

Esri replication requires GlobalIDs in order to properly replicate without losing data. Historically, Responder has used FCIDs and OIDs, but not GlobalIDs. With the release of 9.2.1, Responder uses Global IDs to resynchronize Responder tables between two replicas of a geodatabase created by Esri Replication. First, ensure the support for GlobalIDs is properly configured.

The page describes the Responder resynchronization process to be used when changes that break replica synchronization occur in the geodatabase.

In the initial state (Figure 1), Editors work in one SDE database while Responder users typically use another. Esri replication may be used to maintain an updated version of the SDE geodatabase for Responder users.

Figure 1, Initial State

When a replica is rebuilt, the Responder and System tables must be updated on the Responder server to match the new schema. This process requires double the storage space typically needed on the Responder server. This may come as a second instance on the same database hardware or a separate database entirely.

Under normal conditions, data is replicated between the Editor and Responder geodatabases, and Responder runs normally. But if there is a schema-breaking change (e.g., a new feature class) that causes Esri Replication to stop copying data over to the Responder geodatabase, a new copy of the Editor geodatabase must be created on a second database instance. Because object IDs and feature class IDs may change in the second database instance, Responder must resynchronize its data to work on the newly created data.

Figure 2, Schema-breaking changes require replication and update of Responder and ArcFM System tables

To create a new replica of the Editor geodatabase and resynchronize the Responder tables and ArcFM system tables to work properly on the newly created replica database instance, perform the following steps.

Perform the set up for GlobalID support before continuing to the next step.
Create a new replica on the secondary Responder store. To save time, the next two steps (3-4) may be performed while the replica is being created.
Use the ArcFM Export/Import tools to export the ArcFM Properties from the ArcFM geodatabase and import them into the geodatabase on the secondary Responder store. When exporting, select all checkboxes in the ArcFM Export dialog. This step ensures that all schema changes as well as ArcFM Property changes (e.g., new model name assignments) are included in the Responder database.
Copy the following ArcFM system tables from the primary Responder store to the secondary Responder store. This step ensures that the new Responder store has the same documents, stored displays and page templates as the original Responder store. This requires a DBA to create a SQL Script that copies the tables.
- MM_DOCUMENTS
- MM_PAGE_TEMPLATES
- MM_STORED_DISPLAYS
- MM_SYSTEM_DOCUMENTS
- MM_SYSTEM_PAGE_TEMPLATES
- MM_SYSTEM_STORED_DISPLAYS
Use the Data Source Wizard to point the layers in all Documents and Stored Displays to the geodatabase on the secondary Responder store.

NOTE: The Data Source Wizard is unable to restore joins and relates after connecting a stored display to a new data source. If your stored display contains joins and/or relates, they must be restored manually after executing the Data Source Wizard.
This step is required. Perform a full compression of the secondary Responder store. This ensures that all features are mapped correctly to GlobalIDs.

At this point you have a working geodatabase and stored displays/documents on the secondary Responder store. All clients are still running against the database on the primary Responder database. The next step shuts down Responder for a short period so the clients can point to the new Responder database on the secondary store.

Stop Responder. This includes all clients, services (data and archive) and the web service.

Note: MSMQ should remain functional in order to receive SCADA/IVR data. This data is processed when Responder is restarted.
Copy the Responder database tables from the primary Responder store to the secondary Responder store. This requires a DBA to create a SQL Script that copies all Responder tables.

History tables: It is strongly recommended that you have the "Delete history after archiving" option selected when using the Build Archive From History tool. This minimizes the size of the history tables and optimizes performance when copying Responder tables.
Populate the OID_Actual and FCID_Actual fields in the RX_GLOBALID_XREF table. You will need a DBA to create a SQL script to do this step for all features in the RX_GLOBALID_XREF table. A future release will provide a tool that performs the following:
- Use the GlobalID (GUID) in the RX_GLOBALID_XREF table to look up the FCID and OID values in the replicated database and populate the FCID_Actual and OID_Actual fields with these values.
- Look for the FCID and OID values in the Responder tables (Archive tables are populated in a later step) and compare the current FCID/OID values (on the feature) with the corresponding Actual_FCID and Actual_OID values in the RX_GLOBALID_XREF table. If these values are different, the FCID and/or OID will be updated to reflect the values in the Actual fields in the RX_GLOBALID_XREF table.
Modify all configuration files to point to the secondary Responder store. If you have previously configured Miner.Responder.QueryWindowsService.exe.config, then it must be modified in this step. If it has not been configured previously, it is optional to do so now.
- Miner.Responder.Explorer.exe.config (client)
- ArcMapRemotingConfig.xml (client)
- Miner.Responder.DataServices.exe.config (server)
- Miner.Responder.PredictionServices.exe.config (server)
- Miner.Responder.QueryWindowsService.exe.config (optional, server)
- Web.config (web)
The following steps are performed while the Responder database is down. You may wish to practice these steps in a test environment before doing them in production in order to optimize the process and reduce the time necessary to complete.
Shutdown the SDE database on the primary Responder store and hide the read/alter access to the Responder tables. This prevents clients from accidentally pointing to this Responder database.
Start Responder services (Data and Prediction), the web service and all clients. This means Responder services are once again running and users may continue work. Do not start Archive Services yet.

Note: When logging into ArcMap, users will need to login to the SDE database on the secondary Responder store (instead of the primary server).
Begin the database replication synchronization process as usual.

The next steps allow you to update the Responder Archive tables. Archive tables should be updated after the rest of the Responder tables because they can be updated while the rest of Responder is running.
Execute Miner.Responder.ReplicationInitializer.exe (Program Files\Miner and Miner\Responder\Server). This populates the first three fields in the RX_GLOBALID_XREF table (FCID, OID, GlobalID) with values for existing features in the Responder database. Running this tool right before a full replication ensures that all fields in the RX_GLOBALID_XREF table are populated appropriately.

Figure 2 illustrates the tasks performed to prepare the secondary store to become the primary store. These are the tasks performed while clients are still using the primary store.
Populate the OID_Actual and FCID_Actual tables in the RX_GLOBALID_XREF table for all features in the Archive tables. You will need a DBA to create a SQL script to do this step. A future release will provide a tool that performs this task. Details are discussed in step 9.
Restart Archive Services and reconnect Responder Archive Explorer.
The primary Responder store is no longer necessary and may be archived or removed. It may also be used as the new secondary Responder store for a future replication (that includes schema-breaking changes). The secondary Responder store may now be considered the primary.

Figure 3 depicts the Responder users now pointed to the secondary store, while the original primary store is made unavailable.

Figure 3, Pause Responder to point application to new Secondary Store; original Primary Store no longer necessary