Distribute data with a two-way replica

Argentina's tourism department wants to create a web map to help tourists navigate Buenos Aires, the nation's capital and largest city. However, the data needed for this map is spread across the transportation department, the culture department, and the retail department, each using their own enterprise geodatabase for spatial data management. The data is updated frequently, meaning the web map will become out-of-date if it uses a static copy.

This tutorial will focus on distributing data between the culture department and the tourism department using a two-way replica (other tutorials in this series focus on the transportation and retail departments and use different types of replicas). Your goal is to coordinate with the culture department to acquire a synchronized copy of their data. To do so, you'll create a replica of the culture department's enterprise geodatabase. You'll identify the appropriate type of replication, implement it, and synchronize changes after the data is updated.

This tutorial was last tested on June 23, 2023, using ArcGIS Pro 3.1. If you're using a different version of ArcGIS Pro, you may encounter different functionality and results.

Requirements

• ArcGIS Pro Standard or Advanced (see options for software access)
• ArcGIS Server installed and authorized
• Microsoft SQL Server (or another supported RDBMS) installed

Prepare the data

First, you'll confirm that a two-way replica is the best solution for distributing data between the culture and tourism departments, compared to other types of replicas. Then, you'll download the data, connect to the enterprise geodatabases for both departments, and ensure the culture data is correctly configured for replication.

Why a two-way replica?

Geodatabase replication is useful for managing and distributing spatial data across multiple locations and geodatabases. It involves creating replicas, or copies, of data in a source geodatabase and transferring those replicas to a target geodatabase. One advantage of replicas is that they can be synchronized with the source data on a regular basis. Synchronization means that any changes made to the source data will also be reflected in the replica data, which is useful for managing data that is frequently updated.

There are three types of geodatabase replication: one-way, two-way, and checkout/check-in. The type you use will depend on how the data is stored, what way the data is intended to be distributed, and the data's editing requirements.

This tutorial will focus on the replica between the tourism and culture departments. The type of replica used will be a two-way replica.

Why is a two-way replica the best type of replication for the culture and transportation departments? Consider the following aspects of the workflow:

• Both departments store their data in an enterprise geodatabase.
• The culture department needs to share its data with the tourism department.
• The tourism department will help the culture department do a data cleaning process. This process will ensure the data is accurate before it becomes publicly available.
• Both departments will require editing access to the data.

Two-way replications allows data changes to be sent multiple times from the parent replica to the child replica and vice versa. In situations where the same data is edited in both replica geodatabases, a conflict is detected during replica synchronization. The conflict can be automatically resolved in favor of either replica geodatabase, or manually reviewed using versioning.

Download the data

Now that you've determined that a two-way replica is best for your workflow, you'll download and open an ArcGIS Pro project package that contains the data used in this tutorial.

Note:

For this tutorial, you'll be using your own enterprise geodatabases to complete the workflow. Ensure that you have ArcGIS Server installed and authorized and Microsoft SQL Server (or another supported relational database management system) installed. To learn more about installing these components, review the Base ArcGIS Enterprise deployment documentation and the Get started with ArcGIS Enterprise Builder tutorial.

1. Download the Tourism_and_Culture project package.
2. Locate the downloaded file on your computer.

   Note:

   Depending on your web browser, you may have been prompted to choose the file's location before you began the download. Most browsers download to your computer's Downloads folder by default.

3. If you have ArcGIS Pro installed on your machine, double-click Tourism_and_Culture.ppkx to open the project. If prompted, sign in using your licensed ArcGIS account.

   Note:

   If you don't have access to ArcGIS Pro or an ArcGIS organizational account, see options for software access.

   The project contains two maps, Culture and Tourism, one for each department participating in the replication. These maps are zoomed to Buenos Aires, Argentina, but contain no data other than the basemap.

   

   The project also contains data in the project geodatabase.

4. In the Catalog pane, expand Databases and expand tourism_and_culture.gdb.

   

   The database includes three feature classes: Libraries, Museums, and Religious_sites. In this tutorial, these are the datasets managed by the culture department that the tourism department wants to use in their map.

Connect to enterprise geodatabases

The database in which the data currently resides is a file geodatabase. Two-way replication is only possible when the parent and child databases are enterprise geodatabases, so you'll need to move the data.

An enterprise geodatabase uses ArcGIS Enterprise. It has added functionality and dataset types; it also allows synchronization with feature services published from its data.

First, you'll create or connect to the enterprise geodatabase that will represent the one used by the culture department. You'll copy the data in the file geodatabase to it. Then, you'll create or connect to the enterprise geodatabase that will represent the one used by the tourism department.

1. If necessary, create an enterprise geodatabase in your instance of SQL Server (or other supported relational database management system) named Culture_BA.

   Note:

   If you already have an enterprise geodatabase available to you, you can use it instead of creating a new one. If you need help creating a new enterprise geodatabase, refer to the Create an enterprise geodatabase section of the Deploy an enterprise geodatabase for real estate tutorial.

   Next, you'll connect to the enterprise geodatabase.

2. In the Catalog pane, right-click Databases and choose New Database Connection.

   

   The Database Connection window appears. The parameters you use to connect to the enterprise geodatabase will depend on your SQL Server or relational database management system (RDBMS) instance.

3. For Database Platform, choose the RDBMS your instance uses. For Instance, type the name of your RDBMS instance.

   Note:

   The example images use a SQL Server instance named BASQL; your instance will be different.

   

4. For Authentication Type, choose Database authentication.
5. For User Name and Password, type the credentials for an account that is able to access and load data to the enterprise geodatabase.

   This user will act as the data owner for the culture department's enterprise geodatabase. In an ordinary workflow, this user is different than the geodatabase and database administrator user.

   Note:

   The example images use a user named BRUNO; your user name will be different.

6. For Database, choose the Culture_BA enterprise geodatabase you created (or another enterprise geodatabase you have access to and can modify for this tutorial).

   

7. Click OK.

   The enterprise geodatabase is added to the Catalog pane. By default, the database is named after the instance. (For instance, the example database is named BASQL.sde.) You'll rename the database to follow the following naming format: database name_database user.sde.

8. In the Catalog pane, right-click your enterprise geodatabase and choose Rename. Change the name to Culture_BA_[your database user name].sde.

   Note:

   In the example images, the user name is BRUNO, so the enterprise geodatabase is named Culture_BA_BRUNO_sde. Your user name will be different.

   

   Next, you'll copy the data in the file geodatabase to the enterprise geodatabase.

9. Drag the Libraries, Museums, and Religious_sites feature classes from tourism_and_culture.gdb to Culture_BA.sde.

   Tip:

   Press Ctrl and click each of the feature classes to select all three at once, then drag them to copy all three at once.

10. Expand Culture_BA.sde to view its contents.

    

    The data has been copied. The copies are prefixed by the name of the user who owns the data. In the example image, the data owner is an account named BRUNO; your user name will differ.

11. Collapse tourism_and_culture.gdb.

    Next, you'll connect to the enterprise geodatabase used by the tourism department. For a two-way replica, the child database also must be an enterprise geodatabase.

12. If necessary, create an enterprise geodatabase in your instance of SQL Server (or other supported relational database management system) named Tourism_BA.
13. In the Catalog pane, right-click Databases and choose New Database Connection.
14. In the Database Connection window, set the appropriate parameters to connect to the Tourism_BA geodatabase you created (or another enterprise geodatabase you have access to and can modify for this tutorial).
15. Click OK.
16. Rename the new database connection to Tourism_BA_[your database user name].sde.

    In the example images, the user name for the tourism database is EMMA; your user name will differ.

    

    You are now connected to two enterprise geodatabases. One represents the enterprise geodatabase managed by the culture department; it contains data about cultural institutions in the city. One represents the enterprise geodatabase managed by the tourism department; it is empty.

Enable global IDs

Next, you'll prepare the culture department's data for replication. First, you'll confirm that the database connection uses traditional, rather than branched, versioning. Replication is not supported with branch versioning, as replicas require a direct connection to the geodatabase for editing. Then, you'll enable global IDs for the feature classes. When data is versioned due to editing, global IDs help map edits made in multiple versions of the same data.

1. In the Catalog pane, right-click Culture_BA.sde and choose Geodatabase Connection Properties.
2. In the Geodatabase Connection Properties window, confirm that Versioning Type is set to Traditional.

   

3. Close the Geodatabase Connection Properties window.

   Next, you'll enable traditional versioning and enable global IDs for each of the three feature classes.

4. In the Catalog pane, right-click Libraries and choose Manage.

   

   The Feature Class Properties window appears.

5. In the Manage tab, check Versioning and choose Traditional. Confirm that Global IDs is checked.

   

6. Click OK.
7. For the Museums and Religious_sites feature classes, open the Feature Class Properties window, enable traditional versioning, and confirm global IDs are enabled.

   Now, all three feature classes are ready for replication.

8. On the Quick Access Toolbar, click the Save button to save the project.

   

So far, you've confirmed that a two-way replica is the appropriate replication type to distribute data between the culture and tourism departments. You've also connected to the enterprise geodatabases you'll use in the tutorial and prepared the database connection and feature classes for replication.

Create a two-way replica

Next, you'll create a two-way replica between the culture and tourism geodatabases.

Create the replica

To create the replica, you'll run a geoprocessing tool.

1. In the Catalog pane, right-click Culture_BA.sde, point to Distributed Geodatabase, and choose Create Replica.

   

   The Geoprocessing pane appears, showing the Create Replica tool. First, you'll set the datasets to be replication.

2. For Replica Datasets, click the Browse button.

   

3. In the Replica Datasets window, under Project, expand Databases. Click Culture_BA.sde.
4. Press Ctrl and click Libraries, Museums, and Religious_sites to select all three.

   

5. Click OK.

   The datasets are added to the parameter in the Geoprocessing pane.

6. For Replica Type, choose Two way replica. Confirm that Output Type is set to Geodatabase.

   Next, you'll ensure the data is replicated to the tourism department's database.

7. For Geodatabase to replicate data to, click the Browse button.
8. In the Geodatabase to replicate data to window, under Project, click Databases. Select Tourism_BA.sde and click OK.
9. For Replica Name, type Culture_to_Tourism.

   

10. Click Run.

    The tool runs and the replica is created.

11. Close the Geoprocessing pane.

Explore the replica

Now that the replica has been created, you'll inspect the replica from the perspective of both the parent and the child database.

1. In the Catalog pane, right-click Culture_BA.sde, point to Distributed Geodatabase, and choose Manage Replicas.

   The Manage Replicas pane appears. It lists one replica: the Culture_to_Tourism replica you created.

2. Under Culture_to_Tourism, click the arrow to expand the replica.

   

   Information about the replica is displayed. The replica owner is the database user who created the replica (in the example images, BRUNO). The information also includes whether the database is the parent or child and whether it is sending or receiving the data.

   

   In this instance, the culture database is both the parent and data receiver. Because the replica is a two-way replica, the database can both send and receive data even if its status is set to receiver.

3. Close the Manage Replicas pane.

   Next, you'll confirm that the data was replicated to the child database.

4. In the Catalog pane, right-click Tourism_BA.sde and choose Refresh.
5. Expand Tourism_BA.sde.

   

   The three feature classes have been successfully replicated in the child database.

6. Right-click Tourism_BA.sde, point to Distributed Geodatabase, and choose Manage Replicas.
7. In the Manage Replicas pane, expand the Culture_to_Tourism replica.

   The information about the replica, when accessed from the tourism geodatabase, indicates the role as child and the status as data sender instead of data receiver. Because you're using a two-way replica, the database will be able to send and receive data regardless of its status.

   

8. Close the Manage Replicas pane. Collapse the Tourism_BA.sde connection.
9. Save the project.

You've created a two-way replica between the culture and tourism databases. You confirmed the data was properly replicated and inspected the replica from the parent and child perspective to assess the data flow. The data is now ready for synchronized edits.

Synchronize changes

Now that you've created a two-way replica, you'll make use of its ability for data synchronization. In this part of the workflow, assume that the culture department is cleaning their data to ensure it is accurate before making it available publicly. Because the data is extensive, the tourism department has offered to help. However, both departments will be editing the same data at once, which can lead to conflicts.

First, you'll perform the edits using the data in both databases. Then, you'll synchronize the changes and review any resulting conflicts.

Add the data to the map

One of the features in the religious sites feature class has been duplicated. You, acting as a GIS specialist for the culture department, will edit the data to remove the redundant feature. First, you'll add the data to the map and change its symbology.

1. Confirm that the Culture map is the active map.

   

2. In the Catalog pane, under Culture_BA.sde, right-click Religious_sites and choose Add To Current Map.

   

   The feature class is added to the map. (Your default symbology may differ from the example images.)

   

   Next, you'll change the symbology. To save time, layer files have been included in the project folder. You'll import the symbology from those files.

3. In the Contents pane, ensure that Religious sites is selected.

   

4. On the ribbon, click the Feature Layer tab. In the Drawing group, click Import.

   

   The Import Symbology pane appears.

5. For Input Layer, confirm that Religious sites is chosen. For Symbology Layer, click the Browse button.
6. In the Symbology Layer window, under Project, expand Folders, Tourism_and_Culture, and commondata. Click userdata.

   

7. Click Religious_sites.lyrx and click OK.

   The file is added to the tool parameters.

   

8. Click OK.

   The symbology is applied.

   

Edit the culture department data

You'll navigate to the location of the duplicated feature and delete it.

1. On the ribbon, click the Map tab. In the Navigate group, click Bookmarks and choose Iglesia San Francisco.

   

   The map navigates to Iglesia San Francisco, a church in Buenos Aires. The church appears to have two features associated with it.

   

   You'll investigate each feature to learn more.

2. On the map, click the feature on the left.

   Its pop-up appears. This feature has an ID of 99. Notably, this feature has a value of 0 for the Altura (height) field. This value is definitely incorrect, meaning this feature is probably erroneous.

   

3. Click the other feature.

   The pop-up indicates that there are actually two overlapping features. One has an ID of 27 and is for Iglesia San Francisco, with accurate attribute information. The other has an ID of 34 and is for Iglesia San Roque, which is incorrect.

   

   You'll delete the two incorrect features. You'll also modify the correct feature to remove the word Basilica from its name.

4. Close the pop-up.
5. On the ribbon, click the Edit tab. In the Selection group, click the Select button.

   

6. On the map, click the feature with the ID of 99 (the feature on the left).

   The feature is selected.

   

7. On the ribbon, in the Features group, click Delete.

   Caution:

   Deleting data is permanent. It's recommended to save a backup of any data before deleting features from it. In this tutorial, you already have a backup copy in the tourism_and_culture file geodatabase.

   

8. If asked whether you are sure you want to delete the data, click Yes.

   The feature is deleted.

9. On the map, draw a box around the remaining Iglesia San Francisco feature to select it.

   Note:

   It's necessary to draw a box around the feature instead of clicking it; otherwise, you'll only select one of the two overlapping features.

   Because the two features overlap, you'll need to ensure you delete the correct one.

10. On the ribbon, in the Selection group, click Attributes.

    

11. In the Attributes pane, right-click San Roque and choose Delete.

    Note:

    If you only see the San Francisco option and not the San Roque one, draw a box around the feature on the map to ensure you select both overlapping features.

    

12. If asked whether you are sure you want to delete the data, click Yes.

    The feature is deleted. Lastly, you'll edit the San Francisco feature's name.

13. In the Attributes pane, confirm that San Francisco (Basilica) is selected. For Nombre, delete (Basilica) from the name and press Enter.

    

14. At the bottom of the pane, click Apply. Close the Attributes pane.
15. On the ribbon, in the Manage Edits group, click Save.

    

16. In the Save Edits window, click Yes.

    Your edits to the data in the culture department's database are saved.

Edit the tourism department data

Next, you'll make edits to the same features, but using the data in the tourism database. Because the changes made by the culture department have not been synchronized, the tourism department's data does not include the new edits.

The tourism department's edits will be different from those made by the culture department. When the changes are later synchronized, this will generate conflicts between the two datasets that you'll need to resolve.

1. Activate the Tourism map.

   

2. In the Catalog pane, expand the Tourism_BA.sde database connection. Right-click the tourism department's Religious_sites feature class and choose Add To Current Map.
3. Optionally, for the Religious sites layer, import symbology using Religious_sites.lyrx.

   Note:

   The example images will show the imported symbology, but it is not necessary to import the symbology to proceed with the workflow.

4. On the ribbon, click the Map tab. In the Navigate group, click Bookmarks and choose Iglesia San Francisco.

   The map zooms to the area of interest. Although you deleted one of the visible features in the culture department's copy of the data, the feature is still there in the tourism department's copy.

   

   In examining the data, the tourism department has reached a different conclusion than the culture department regarding the data edits. The culture department deleted the feature on the left (feature 99), due to its incorrect attribute information. By contrast, the tourism department will delete the feature on the right (feature 27), because the point is not located in the middle of the church's location on the basemap.

   However, the tourism department will delete the San Roque feature, like the culture department did.

5. On the ribbon, confirm that the Select button is still active.
6. On the map, draw a box around the feature on the right to select it.

   

7. On the ribbon, click the Edit tab. In the Selection group, click Attributes.
8. In the Attributes pane, press Ctrl and click San Francisco (Basilica) and San Roque to select them both. Right-click either feature and choose Delete.

   

9. If asked whether you are sure you want to delete the data, click Yes.

   Both features are deleted. Next, you'll edit the remaining feature's attributes so that they are accurate.

10. On the map, click the remaining feature to select it.
11. In the Attributes pane, for Altura (height), type 380. For Tipo (type), type Iglesia.

    

12. At the bottom of the pane, click Apply. Close the Attributes pane.
13. On the ribbon, in the Manage Edits group, click Save. In the Save Edits window, click Yes.

Synchronize changes

Both departments have made edits to their versions of the data. Now, they want to synchronize changes so the other department's version of the data reflects their edits.

In two-way replication, both the parent (culture) and child (tourism) databases can synchronize changes. In this scenario, the tourism department made their changes last, so they will synchronize.

1. In the Catalog pane, right-click Tourism_BA.sde, point to Distributed Geodatabase, and choose Synchronize Changes.

   

   The Geoprocessing pane appears, showing the Synchronize Changes tool. The tool parameters are automatically filled in. Geodatabase 1 is the database that is synchronizing changes (the tourism database), while Geodatabase 2 is the other database involved in the two-way replica (the culture database).

   By default, the direction of the synchronization is Both directions. If there are conflicts, they will automatically be resolved in favor of the database doing the synchronization. However, you don't want to synchronize this way, as you want conflicts to be resolved manually. You'll adjust the parameters.

2. In the Synchronize Changes tool, for Direction, choose From geodatabase 1 to geodatabase 2. For Conflict Resolution Policy, choose Manually resolve conflicts.

   

3. Click Run.

   The tool runs, but completes with warnings.

4. For Synchronize Changes completed with warnings, click View Details.

   

   The tool window appears. The warning says that the synchronization was successful, but there were conflicts detected. You'll need to resolve the conflicts before exporting changes from the replica.

   

5. Close the tool window. Close the Geoprocessing pane.

Resolve conflicts

To review the conflicts, you'll manage versioning from the parent database, Culture_BA.sde.

1. Activate the Culture map.

   The data in this map is from Culture_BA.sde.

2. In the Contents pane, click the List By Data Source button.

   

   The data is organized by the source of the data. The map has three data sources, two for the basemap and one for the culture department's data.

3. Click the database connection for the Religious sites layer to select it.

   Note:

   Your database connection may have a different name than the one in the example images.

   

   On the ribbon, the contextual Versioning tab becomes available.

4. Click the Versioning tab. In the Versioning group, click Manage Versions.

   

   The Versions view appears for the database. There are two versions: the default version, which was created when you first connected to the culture department's database, and the Culture_to_Tourism_15 relative replica version, which was created automatically to store the conflicts. The version name is the same as the replica name and the owner of the new version is the user name you used to connect to Culture_BA.sde (in the example images, BRUNO).

   

   You'll change the version being used by the database to the new version.

5. Close the Versions view. If necessary, activate the Culture map.
6. In the Contents pane, right-click the database connection for the Religious sites layer and choose Change Version.

   

7. In the Change Version window, select the Culture_to_Tourism version that begins with your user name.

   

8. Click OK.

   The version is changed. In the Contents pane, the data source for the Religious sites layer is now the Culture_to_Tourism version. Additionally, the map changes to show the tourism department's edits to the data, instead of the culture department's edits.

   Next, you'll compare and reconcile the differences between the two versions.

9. On the ribbon, on the Versioning tab, in the Versioning group, click Reconcile.

   

10. In the Reconcile window, leave the default parameters and click OK. In the warning window that asks you whether you wish to review the conflicts, click Yes.

    The Conflicts view appears.

11. In the Conflicts view, expand Religious_sites. Expand Delete-Update and Update-Delete.

    

    There are two conflicts. The Delete-Update conflict has the number 27, referring to the feature with the ID of 27. This conflict indicates feature 27 was deleted in the current version (the tourism department's version), but updated in the target version (the culture department's version).

    The Update-Delete conflict, by contrast, indicates that feature 99 was updated in the current version, but deleted in the target version. There is no conflict related to the San Roque feature, which was deleted in both versions.

12. Click 27.

    The feature's attributes appear for the current version, the target version, and common ancestor (the original data).

    

    After reviewing the conflicts, the culture department believes that the target version is correct. You'll resolve the conflicts in favor of that version.

13. Right-click 27 and choose Replace With Target Version.

    

14. Right-click 27 and choose Mark As Reviewed.

    You'll also resolve feature 99 in favor of the target version.

15. Right-click 99 and choose Replace With Target Version. Right-click 99 and choose Mark As Reviewed.

    Next, you'll make the edits available to the default version.

16. Close the Conflicts view. On the ribbon, on the Versioning tab, click Post.

    

    Clicking this button also saves the edits you made.

    Now that you've manually reviewed the conflicts and determined which edits to keep, you'll synchronize the changes to make them available to the child database.

17. In the Catalog pane, right-click Culture_BA.sde, point to Distributed Geodatabase, and choose Synchronize Changes. In the Synchronize Changes tool, change the following parameters:
    • For Direction, choose From geodatabase 1 to geodatabase 2.
    • For Conflict Resolution Policy, choose Manually resolve conflicts.

    

18. Click Run.

    This time, the tool runs and completes without warnings, as you've resolved conflicts already.

19. Activate the Tourism map.

    Now, the tourism map shows the changes made by the culture department.

    

20. Save the project.

In this tutorial, you helped the department of culture share its data with the department of tourism. You identified a two-way replica as the best type of geodatabase replication for the workflow. Then, you created the replica between two enterprise geodatabases. Lastly, you edited both versions of the data, synchronized changes, and resolved conflicts. With this two-way replica, both departments will be able to update the data for accuracy as necessary.

This tutorial focused on distributing data between the culture department and tourism department using a two-way replica. Other tutorials in the series focus on distributing data from the transportation and retail departments using one-way and checkout/check-in replicas.

You can find more tutorials in the tutorial gallery.

Acknowledgements

• The Libraries, Museums, and Religious sites feature classes are from the CABA Points of Interest layer created by Aeroterra SA. Aeroterra SA compiled the layer based on data published to Buenos Aires Data, which shares its data under the CC BY 2.5 AR license.
• The gallery card image was taken by PabloNuñoAmoedo and is shared under the CC BY-SA 4.0 license.
• Topographic sources: Esri, HERE, Garmin, FAO, NOAA, USGS, Intermap, METI, OpenStreetMap contributors, and the GIS User Community