Set Up GUID Support
Responder provides the RX_GLOBALID_XREF table in order to support GlobalIDs. The RX_GLOBALID_XREF table provides a cross reference between the FCID/OID used by Responder to identify features and the GlobalID (GUID) used by Esri Replication. This table contains the following fields:
-
FCID
-
OID
-
GlobalID
-
FCID_Actual
-
OID_Actual
You will need to create the RX_GLOBALID_XREF table using the scripts provided with Responder. By default, these scripts are installed here: \Program Files (x86)\Miner and Miner\Responder\Developer Resources\Implementation Scripts\[Oracle or MS-SQL]\Addons. Run Replication_mssql.sql or Replication_Oracle.sql to create the RX_GLOBALID_XREF table.
When configured properly, Responder populates the first three fields for all features impacted by an incident. The FCID_Actual and OID_Actual fields will be utilized by future functionality.
This configuration is completed on the Responder server machine and must be completed before the first replication that includes schema-breaking changes. It should not need to be done a second time.
In order to configure Responder to support GlobalIDs, perform the following steps.
- Open the SubmitRulesConfig.xml file with any application that views XML. By default, this file is installed here: \Program Files\Miner and Miner\Responder\Server.
-
Look for the following bit of XML:
<!-- BEGIN Global ID rules --> <!--<b:RuleClass Key="" Type="Miner.Responder.Processors.SubmitRules.Pre.InsertInitialGlobalId, Miner.Responder.Processors"/>--> <!-- END Global ID rules -->
- The above line of XML is commented out in SubmitRulesConfig.xml. Remove comment tags (<!-- and -->) to uncomment it out and enable the submit rule. This submit rule will populate the first three fields in the RX_GLOBALID_XREF table whenever an incident is created in Responder.
- Save and close SubmitRulesConfig.xml.
-
Open Miner.Responder.ReplicationInitializer.exe.config.
By default this file is installed here: \Program Files\Miner and Miner\Responder\Server.
NOTE: This step is not necessary if you are performing a new Responder installation.
-
Look for the <connectionStrings> tag.
<connectionStrings> <!--Below are examples of how to configure the Replication Initializer with Oracle--> <!--<add name="Active" connectionString="Data Source=activeDatasource;User ID=activeUserId;Password=activePassword" providerName="System.Data.OracleClient" /> <add name="Archive" connectionString="Data Source=archiveDatasource;User ID=archiveUserId;Password=archivePassword" providerName="System.Data.OracleClient" />--> <!--Below are examples of how to configure the Replication Initializer with SQL Server--> <!--<add name="Active" connectionString="Data Source=activeDatasource;Initial Catalog=rxCatalog;User ID=activeUserId;Password=activePassword" providerName="System.Data.SqlClient" /> <add name="Archive" connectionString="Data Source=archiveDatasource;Initial Catalog=rxArchiveCatalog;User ID=archiveUserId;Password=archivePassword" providerName="System.Data.SqlClient" />--> </connectionStrings>
- Determine whether you'll be using an Oracle or SQL connection. Remove the comment marks (<!-- and -->) for the appropriate section.
- Enter the connection information (connectionString attribute) for the Responder server and the Archive server.
-
Toward the bottom of this file look for the following bit
of XML.
<channels> <channel ref="msmq" isServer="false" ComputerName="ServerName"/> <channel ref="tcp" port="2063"/> </channels>
- Replace ServerName (shown in the example above) with the name of your Responder server. This value can be "." if the Responder server is local.
- Save and close Miner.Responder.ReplicationInitializer.exe.config.
- Execute Miner.Responder.ReplicationInitializer.exe. This populates the first three fields in the RX_GLOBALID_XREF table (FCID, OID, GlobalID) with values for existing features in the Responder database. After this tool has been executed, the submit rule (steps 1-4) will automatically populate this table (the first three fields only) for all features associated with any new incidents. It is good practice to execute this tool right before a full replication (one that includes schema-breaking changes).