Distribute data with a checkout 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 retail department and the tourism department using a checkout/check-in replica (other tutorials in this series focus on the transportation and culture departments and use different types of replicas). Your goal is to coordinate with the retail department to acquire a synchronized copy of their data. To do so, you'll create a replica of the retail 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 May 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 checkout/check-in replica is the best solution for distributing data between the retail 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 retail data is correctly configured for replication.

Why a checkout/check-in 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 retail departments. The type of replica used will be a checkout/check-in replica, also referred to as a checkout replica.

Why is a checkout/check-in replica the best type of replication for the retail and transportation departments? Consider the following aspects of the workflow:

• The tourism department uses an enterprise geodatabase, while the retail department does not.
• The tourism department is busy managing their own data, so it cannot undertake more responsibilities, such as managing replicas. A short duration replication model is preferred.
• The replica will be created on demand, twice a year, when the retail department updates its data based on reports from local businesses.

Checkout/check-in replication allows edits to be made in the child replica data and synchronized with the parent geodatabase. The parent database is always an enterprise geodatabase, while the child database can be either an enterprise or file geodatabase. Once the data is synchronized, the checkout replica is unregistered (deleted), and additional edits cannot be made. If additional edits are required, a new checkout replica must be created.

Because the tourism department has an enterprise geodatabase while the retail department does not, the tourism department's geodatabase will be the parent. However, the retail geodatabase contains the data. By using a checkout/check-in replica, the tourism department can check out an empty feature class schema, giving the retail department access to it. Then, the retail department loads their data into the schema. Lastly, the retail department checks in the populated feature class schema, returning it to the tourism department. Afterward, the replica is unregistered.

Download the data

Now that you've determined that a checkout 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 geodatabase 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_Retail 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_Retail.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, Retail 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_retail.gdb.

   

   The database includes one feature class: Restaurants. In this tutorial, this is the dataset managed by the retail department that the tourism department wants to use in their map.

Connect to the geodatabases

The database in which the data currently resides is the project's default geodatabase. Checkout replication requires an enterprise geodatabase, so you'll need to connect to one.

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

In this workflow, the tourism department uses an enterprise geodatabase, while the retail department uses a file geodatabase. First, you'll connect to the enterprise geodatabase to represent the one used by the tourism department. Then, you'll create a file geodatabase to represent the one used by the retail department and copy the data to it.

1. If necessary, create an enterprise geodatabase in your instance of SQL Server (or other supported relational database management system) named Tourism_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.

   Note:

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

6. For Database, choose the Tourism_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 Tourism_BA_[your database user name].sde.

   Note:

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

   

   Next, you'll create a file geodatabase to represent the one used by the retail department. File geodatabases do not use ArcGIS Enterprise and can be created and accessed without credentials. However, they lack some of the functionality of enterprise geodatabases.

9. Right-click Databases and choose New File Geodatabase.

   

   The New File Geodatabase window appears. You can use this window to browse to where the file geodatabase will be saved and give it a name. By default, the geodatabase will be saved in the project's default folder. For the purposes of this tutorial, this location is fine.

10. In the New File Geodatabase window, for Name, type Retail_BA. Click Save.

    The new file geodatabase is added to the Catalog pane. Because this geodatabase isn't an enterprise geodatabase and doesn't require credentials to access, you won't rename it to include a user name.

    Next, you'll copy the retail data from the default geodatabase to the new file geodatabase.

11. In the Catalog pane, drag the Restaurants feature class from tourism_and_retail.gdb to Retail_BA.gdb.
12. Expand Retail_BA.gdb to view its contents.

    

    The data has been copied.

13. Collapse tourism_and_retail.gdb.

    You are now connected to the two geodatabases you'll use in this tutorial. One represents the file geodatabase managed by the retail department; it contains data about restaurants in the city. One represents the enterprise geodatabase managed by the tourism department; it is empty.

Create a new feature class

For a replica, the parent database must be an enterprise geodatabase. However, in this workflow, your enterprise geodatabase does not contain data, while the file geodatabase does.

To replicate the file geodatabase's data to the enterprise geodatabase, you'll create an empty feature class in the enterprise geodatabase. This feature class will have the same type and attribute fields as the Restaurants feature class, but won't include any actual data. Later, your checkout/check-in replica will copy the empty feature class to the file geodatabase, where it can be populated with actual data before being copied back to the enterprise geodatabase.

1. Right-click Tourism_BA.sde, point to New, and choose Feature Class.

   

   You'll create a new feature class that has the same parameters as the restaurants data. The Restaurants feature class is a point feature class, so you'll make sure your new feature class has the same type.

2. In the Create Feature Class pane, for Name, type Restaurants_Tourism, and for Alias, type Restaurants (Tourism). For Feature Class Type, choose Point.

   Caution:

   Ensure that the name of your new feature class is unique. If the name is the same as the one in the retail database, the original data will be overwritten when you create the replica.

   

   By default, the new feature class will be added to the current map. You're not interested in accessing the feature class on the map right now, so you'll turn off this option.

3. Uncheck Add output dataset to current map.

   

4. Click Next.

   Next, you'll add attribute fields that match those in the original Restaurants feature class.

   Tip:

   You can check a feature class's attribute fields by right-clicking it in the Catalog pane and choosing Open Table.

5. Add fields using the following table:

   Field Name	Data Type
   ID	Long Integer
   Name	Text
   Type	Text
   Cuisine	Text
   PhoneNumber	Text
   Hours	Text
   StreetName	Text
   City	Text
   PostalCode	Text
   Longitude	Double
   Latitude	Double

   

   There are other parameters you can set for the new feature class, including its spatial reference, resolution, and storage configuration, but for this tutorial you don't need to set them.

6. Click Finish.

   The feature class is created.

7. In the Catalog pane, expand Tourism_BA.sde.

   

   In an enterprise geodatabase, data is prefixed by the name of the user who owns the data. In the example image, the owner is an account named EMMA; your user name will differ.

Enable global IDs

Next, you'll enable traditional versioning and global IDs for the enterprise geodatabase and the new feature class. When data is versioned due to editing, global IDs help map edits made in multiple versions of the same data. In a checkout/check-in replica, unlike a one-way or two-way replica, versioning and global IDs are not a requirement. However, the tourism department intends to use their data for sharing and web consumption, so versioning and global IDs will be useful in this context.

1. In the Catalog pane, right-click Tourism_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 the three feature class.

4. In the Catalog pane, for Tourism_BA.sde, right-click Restaurants_Tourism 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.

   Now, the feature class is ready for replication.

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

   

So far, you've confirmed that a checkout/check-in replica is the appropriate replication type to distribute data between the retail and tourism departments. You've also connected to the enterprise geodatabase you'll use in the tutorial, created a new feature class, and prepared the database connection and feature class for replication.

Create a checkout replica

Next, you'll create a checkout/check-in 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 Tourism_BA.sde, point to Distributed Geodatabase, and choose Create Replica.

   

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

2. For Replica Datasets, click the Browse button.

   

3. In the Replica Datasets window, under Project, expand Databases. Click Tourism_BA.sde.
4. Click Restaurants_Tourism to select it.

   

5. Click OK.

   The dataset is added to the parameter in the Geoprocessing pane.

6. For Replica Type, choose Check out replica. Confirm that Output Type is set to Geodatabase.

   Next, you'll ensure the data is replicated to the retail 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 Retail_BA.gdb and click OK.
9. For Replica Name, type Retail_to_Tourism.

   Although the tourism database is the parent in this replica, data will primarily be sent from the retail database to the tourism one. This name indicates the data flow direction.

   

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 Tourism_BA.sde, point to Distributed Geodatabase, and choose Manage Replicas.

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

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

   

   Information about the replica is displayed. The owner is the database user who created the replica (in the example images, EMMA). 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 tourism database is both the parent and data receiver. It'll be the retail database that checks in edits, while the tourism database only checks out the empty feature class schema.

3. Close the Manage Replicas pane.

   Next, you'll confirm that the empty feature class was replicated to the child database.

4. In the Catalog pane, right-click Retail_BA.gdb and choose Refresh.

   The Restaurants_Tourism feature class has been replicated to the geodatabase.

   

5. Right-click Retail_BA.gdb, point to Distributed Geodatabase, and choose Manage Replicas.
6. In the Manage Replicas pane, expand the Retail_to_Tourism replica.

   The information about the replica, when accessed from the retail geodatabase, indicates the role as child and the status as data sender instead of data receiver.

   

7. For the replica, click the Options button and choose Properties.

   

8. In the Replica Properties window, click the Description tab. Confirm that the Restaurants_Tourism feature class is listed as replicated data.

   

9. Close the Replica Properties window and the Manage Replicas pane.
10. Save the project.

You've created a checkout/check-in replica between the retail and tourism databases. You confirmed the empty feature class was properly replicated and inspected the replica from the parent and child perspective to assess the data flow. You're now ready to edit the empty feature class with the original restaurants data and synchronize it with the tourism database.

Synchronize changes

Now that you've created a checkout/check-in replica, you'll use the empty feature class from the tourism department's database to transfer the retail department's data to the tourism department. You'll load restaurant data into the empty replica feature class obtained from the tourism department, then synchronize changes to check the data back in to the tourism department's database.

Load data

First, you'll load restaurant data into the replica of the tourism department's empty feature class.

1. In the Catalog pane, under Retail_BA.gdb, right-click Restaurants_Tourism and choose Load Data.

   

   The Geoprocessing pane appears, showing the Append tool. This tool updates a target dataset with data from an input data. A warning indicates that this tool modifies the target dataset. Because your target dataset is an empty feature class with no data, you don't need to worry about this warning.

2. For Input Datasets, click the Browse button.
3. In the Input Datasets window, browse to Retail_BA.gdb, select Restaurants, and click OK.
4. Confirm that Target Dataset is set to Restaurants_Tourism.
5. For Field Matching Type, choose Use the field map to reconcile field differences.

   

   The Field Map section appears. In this section, you can match fields between the input and target datasets. Doing so ensures data is loaded into the correct fields.

6. For Field Map, under Output Fields, click Name.

   

7. Click Add New Source, check nombre, and click Add Selected.

   

   The name field in the empty feature class is now mapped to the name field in the original restaurants dataset.

8. Map the following fields in the empty feature class to their corresponding field in the restaurants dataset:
   • Map Type to categoria.
   • Map Cuisine to cocina.
   • Map PhoneNumber to telefono.
   • Map Hours to horario.
   • Map StreetName to calle_nombre.
   • Map City to barrio.
   • Map PostalCode to codigo_postal.
   • Map Longitude to long.
   • Map Latitude to lat.
9. Click Run.

   The tool runs and the data is appended. You'll add the data to the map to confirm it was appended correctly.

10. Close the Geoprocessing pane. Confirm that the Retail map view is active.

    

11. In the Catalog pane, under Retail_BA.gdb, right-click Restaurants_Tourism and choose Add To Current Map.

    

    The data is added to the map. Instead of being an empty feature class, which would not display any features on the map, there are many points that represent restaurants. These are the features that you appended to the dataset.

    

12. In the Contents pane, right-click Restaurants (Tourism) and choose Attribute Table.

    

    The table appears. It contains the correct attribute information. (Some cells have null values, but this is because they were null in the original dataset.)

    

13. Close the table.

Synchronize changes

You've confirmed that the data was correctly appended to the Restaurants_Tourism feature class. Next, you'll check in the feature class so that the changes are sent back to the parent geodatabase, which is the tourism department's database. You'll check in the changes by running a geoprocessing tool.

1. In the Catalog pane, right-click Retail_BA.gdb, 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 retail database), while Geodatabase 2 is the other database involved in the checkout/check-in replica (the tourism database).

   There are also parameters regarding conflict resolution. These parameters are set so that conflicts are automatically resolved in favor of the retail geodatabase. Because the original feature class in the tourism database was empty, there shouldn't be any conflicts in need of manual conflict review.

   The only parameter you need to change is the Reconcile with the Parent Version parameter. When the checkout replica is created, the parent geodatabase is versioned to contain the changes from the child. This parameter ensures the data is reconciled between the checkout version and the version of the geodatabase to which you are connected.

2. Check Reconcile with the Parent Version (Checkout only).

   

   Note:

   A warning may appear next to the Conflict Resolution Policy parameter. This warning informs you that conflicts will be automatically resolved. You can ignore this warning.

3. Click Run.

   The tool runs and the changes are synchronized. You'll confirm the replica was deleted.

4. Close the Geoprocessing pane. In the Catalog pane, right-click Retail_BA.gdb, point to Distributed Geodatabase, and choose Manage Replicas.

   The pane is now empty.

   

   Checkout/check-in replicas are designed for a single data transaction. The replica is automatically deleted after synchronization.

5. Close the Manage Replicas pane.

   You'll confirm that the edits have been synchronized with the parent geodatabase.

6. Activate the Tourism map.

   

7. In the Catalog pane, under Tourism_BA.sde, right-click Restaurants_Tourism and choose Add To Current Map.

   The data is added to the map. It contains the data from the original restaurants feature class, indicating that you have successfully replicated the retail department's data to the tourism department's database.

8. Save the project.

In this tutorial, you helped the department of retail share its data with the department of tourism. You identified a checkout/check-in replica as the best type of geodatabase replication for the workflow. Then, you created the replica between two enterprise geodatabases. Lastly, you loaded the restaurants data into an empty feature class and synchronized the changes. You also confirmed that the replica was deleted after the data was synchronized.

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

You can find more tutorials in the tutorial gallery.

Acknowledgements

• The Restaurants feature class is from Buenos Aires Data (accessed May 23, 2023) and originates from Secretaría General y Relaciones Internacionales, Ente de Turismo (ENTUR). The data is shared under the CC BY 2.5 AR license.
• The gallery card image was taken by Walter Nieto and is shared under the CC BY-SA 3.0 license.
• Topographic sources: Esri, HERE, Garmin, FAO, NOAA, USGS, Intermap, METI, OpenStreetMap contributors, and the GIS User Community