Prepare and publish branch versioned data

The National Renewable Energy Centre of Spain (CENER) wants to install solar panels on buildings in Madrid. First, they need to calculate the solar potential of each building. Buildings in a few neighborhoods have already been calculated, but it has proven to be a large project. To speed up the process going forward, multiple people will contribute to the project as data editors.

Versioning allows multiple people to edit the same data at the same time without applying locks or duplicating data. Each editor has an isolated view of the data and can merge their changes back into the default version. There are two types of versioning in ArcGIS: branch and traditional. Branch versioning facilitates multiuser editing through feature services and the Web GIS model.

This tutorial is part of a series that describes the full branch versioning process for the Madrid solar project:

• Prepare and publish branch versioned data
• Make edits in a branch version
• Reconcile and post versions

As the lead on the Madrid solar project, you want to ensure that you understand how the branch versioning process works before asking others on your team to participate in it as editors. In this tutorial series, you'll learn how to properly publish your data, then you'll test the editing process by creating versions, making edits, reconciling versions, and posting into the default version.

In this first tutorial, you'll learn how to prepare data for branch versioning and publish it to an ArcGIS Enterprise portal.

This tutorial was last tested on October 21, 2024, using ArcGIS Pro 3.3 and ArcGIS Enterprise 11.3. If you're using a different version of ArcGIS Pro or ArcGIS Enterprise, you may encounter different functionality and results.

Requirements

• ArcGIS Pro Standard or Advanced
• ArcGIS Enterprise base deployment (this includes access to ArcGIS Server and Portal for ArcGIS
• An enterprise geodatabase
• A database user account with read and write access to the enterprise geodatabase
• A portal account with publishing and editing privileges
  • If these components are not yet installed, review the Base ArcGIS Enterprise deployment documentation and the Get started with ArcGIS Enterprise Builder tutorial. You can also review the system requirements for SQL Server and the system requirements for ArcGIS Server.

Connect to an enterprise geodatabase

In this first module, you’ll connect to an enterprise geodatabase. Branch versioning is only possible with an enterprise geodatabase. Then you’ll copy the Madrid data from a local file geodatabase to the enterprise geodatabase.

Make a database connection

To begin, you’ll make a new database connection to an enterprise geodatabase that will act as the primary data storage for the Madrid solar project. You will make the connection as a data owner, that is, a database user who can load data.

Note:

This tutorial requires an enterprise geodatabase and a database user account with read and write access (a data owner account). If you don’t have these things, follow the steps in Deploy an enterprise geodatabase for real estate. Only the first four sections of that tutorial are required to complete this one; you can stop after running the Create Database User tool.

1. Download the MadridSolar project package.

   A file named MadridSolar.ppkx is downloaded to your computer.

   Note:

   A .ppkx file is an ArcGIS Pro project package and may contain maps, data, and other files that you can open in ArcGIS Pro. Learn more about managing .ppkx files in this guide.

2. Locate the downloaded file on your computer. Double-click MadridSolar.ppkx to open it in ArcGIS Pro.

   A map appears, centered on Madrid. There is no data present aside from the basemap.

   

3. In the Catalog pane, on the Project tab, right-click the Databases folder and click New Database Connection.

   

   The Database Connection window appears. You’ll fill in the parameters of this window to create a connection to the enterprise geodatabase you plan to use throughout this tutorial series.

4. For Database Platform, choose the database management system that was used to create your enterprise geodatabase, for example, SQL Server.

   Note:

   This tutorial series illustrates how to enable branch versioning on an enterprise geodatabase using SQL Server as the database management system. You can also follow this tutorial if you are using another supported DBMS, such as Oracle, IBM Db2, PostgreSQL, and SAP HANA.

   If you select a Database Platform other than SQL Server, the remaining parameters in the Database Connection window will differ from those described below.

5. For Instance, type the name of the instance that was used to create your enterprise geodatabase, for example, MadridSQL.
6. For Authentication Type, choose Database authentication.

   This is the most widely used authentication type.

7. For User Name, type the username of a database user account with read and write access to the enterprise geodatabase.

   Tip:

   If you created your enterprise geodatabase following the Deploy an enterprise geodatabase for real estate tutorial, type GIS.

   This user will become the data owner.

8. For Password, type the password associated with the chosen database user account.
9. Ensure that the Save User/Password check box is checked.
10. For Database, choose the enterprise geodatabase, for example, MadridSolar.
11. For Connection File Name, type a name following the pattern database name_database user, for example, MadridSolar_GIS.

    This is the recommended naming convention for database connections.

    

    Note:

    Your tool parameters will differ from the ones shown in the image above. Enter connection properties specific to your database platform. For more help, see the Set up a database connection documentation.

12. Click OK.

    A new database connection appears in the Catalog pane.

    

Load data into the enterprise geodatabase

The project contains a file geodatabase, madrid_solar.gdb, with two feature classes. You’ll move this data into the newly connected enterprise geodatabase so it can be used for branch versioning.

1. In the Catalog pane, on the Project tab, in the Databases folder, click the arrow next to madrid_solar.gdb to expand it.

   

   The file geodatabase contains two feature classes. Buildings represents the solar potential of roofs in the Arganzuela district of Madrid. Neighborhoods represents the boundaries of the seven neighborhoods in Arganzuela. The Madrid solar project will eventually assess all of the buildings in Madrid, but so far, only this district has been assessed.

2. Drag the Buildings feature class onto the enterprise geodatabase connection (for example, MadridSolar_GIS.sde.)

   

   It may take a few minutes for the data to copy into the enterprise geodatabase.

3. Drag the Neighborhoods feature class onto the enterprise geodatabase connection as well.
4. Expand the enterprise geodatabase connection.

   The enterprise geodatabase now contains two feature classes, copies of the two in the file geodatabase.

   

   The name of each feature class is prepended with the name of the database user, for example, GIS.Buildings. This is the fully qualified name, a pattern that helps to indicate the data owner of each feature class in the database and to prevent duplicate names.

   Tip:

   If the enterprise geodatabase still appears empty, right-click the connection and click Refresh.

5. In the Catalog pane, click the arrow next to madrid_solar_project.gdb to collapse the file geodatabase.

   You won’t be using the file geodatabase in the rest of the tutorial.

In this module, you created a connection to an enterprise geodatabase as a data owner and copied two feature classes into it.

Prepare the data for branch versioning

Editing all of the data for this project will require multiple people. You want them to all be able to do their work at the same time, rather than taking turns. You want them to be able to undo and redo their edits, and you want to detect and resolve any conflicts that might occur, for example, if two people enter different values for the same feature. You can achieve all of these things with branch versioning.

In this module, you’ll prepare the data for versioning. You’ll configure the database connection for branch versioning, and you’ll register the feature classes as branch versioned.

Configure the database connection for branch versioning

When working with branch versioned data, it is important for publishing and administration workflows to set the versioning type of the database connection to branch.

1. In the Contents pane, right-click the enterprise geodatabase connection (for example, MadridSolar_GIS.sde) and click Geodatabase Connection Properties.

   The Database Connection window appears.

2. On the Geodatabase Connection Properties tab, for Versioning Type, choose Branch.

   

3. Click OK.

Register feature classes as branch versioned

Before you can edit a dataset in a version, you must register the dataset as versioned.

1. In the enterprise geodatabase connection, right-click the Buildings feature class (for example, GIS.Buildings) and click Manage.

   

   Note:

   If you are using a version of ArcGIS Pro older than 2.9, right-click each feature class in the Catalog pane, point to Manage, and turn on Add Global IDs, Enable Archiving, and Enable Editor Tracking. Right-click each feature class again, point to Manage, and click Register As Versioned. Skip to the next module.

2. In the Feature Class Properties window, on the Manage tab, check the Versioning check box.

   More parameters appear.

   

3. Ensure that the Branch option is selected. Click OK.

   Next, you’ll register the Neighborhoods feature class in the same way.

4. In the Catalog pane, in the enterprise geodatabase connection, right-click the Neighborhoods feature class and click Manage.
5. Check the Versioning check box and ensure that the Branch option is selected.
6. Click OK.

The data is now registered as branch versioned and the database connection is configured for branch versioning. With these configurations complete, you’re ready to share the data as a web feature layer (a feature service) so other people can access and edit it.

Publish the data as a web feature layer

Branch versioning uses a service-based architecture, which means that you must publish the data as services.

In branch versioning, the data must be registered as branch versioned and published from an enterprise geodatabase. You have already loaded the data into an enterprise geodatabase and registered it as branch versioned. The next step is to publish the data to your ArcGIS Enterprise portal.

Add layers to the map and set symbology

To publish the data, you must first add the two feature classes to a map. You’ll also change the symbology of the two layers before sharing them, to make the editing experience easier. You’ll apply symbology and labeling properties with provided layer files.

1. From the Catalog pane, from the enterprise geodatabase connection (for example, MadridSolar_GIS.sde), drag the Neighborhoods and Buildings feature classes onto the map.

   

   The data appears on the map. The colors are randomly assigned. You’ll change them to make the map easier to read.

2. In the Contents pane, click the Buildings layer (for example, GIS.Buildings) to select it.

   You’ll use the Import Symbology tool to set the symbology of the layer using properties provided in a layer (.lyrx) file.

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

   

4. In the Import Symbology window, ensure that Input Layer is set to the Buildings layer (for example, GIS.Buildings).
5. For Symbology Layer, click the Browse button.

   

6. In the Symbology Layer window, double-click the commondata folder.

   

   Tip:

   If you can't find the commondata folder, in the navigation pane, expand Project, Folders, and MadridSolar.

7. Double-click the userdata folder and select the Buildings.lyrx file.

   

8. Click OK.

   The remaining parameters are populated in the Import Symbology window.

   

9. Accept the default parameters and click OK.

   The symbology of the Buildings layer updates. Roofs with a higher solar potential are shown in dark red, while roofs with a lower solar potential are shown in orange and yellow. All of the buildings in the Imperial neighborhood are yellow because the solar potential values have not yet been calculated for this area.

   

   Next, you’ll change the symbology of the Neighborhoods layer in the same way.

10. In the Contents pane, click the Neighborhoods layer to select it. On the ribbon, click Import.
11. In the Import Symbology window, for Symbology Layer, click the Browse button. Choose the Neighborhoods.lyrx file and click OK.

    

    The Symbology Fields parameters are blank. This is expected, because the symbology that you are applying is not based on any fields.

12. Click OK.

    The layer updates to a symbol with no fill color and black outlines.

    

    The layer file also changed the labeling properties of the layer, so each neighborhood is now labeled with its name.

Share the data to your portal as a web feature layer

Now that the data is properly symbolized, you are ready to share it to your portal. You’ll use the Share As Web Layer pane to publish the feature classes from your enterprise geodatabase as a web feature layer. The editing will be performed on this web feature layer.

To publish, you must first connect to your ArcGIS Enterprise portal with a portal account that has publishing privileges.

1. Above the ribbon, click Not signed in and click Sign in.

   

2. In the ArcGIS Sign In window, type the username and password for the portal account. Click Sign In.
3. On the ribbon, click the Share tab. In the Share As group, click the Web Layer button.

   

4. In the Share As Web Layer pane, set the following properties:
   • For Name, type Madrid Solar Project.
   • For Summary, type Solar potential of each building roof in Madrid.
   • For Tags, type CENER, solar potential, Madrid, branch versioning, Esri. Press Enter.

   

   The sharing process will create one web feature layer that contains two sublayers, one for the buildings data and one for the neighborhoods.

   Under Data and Layer Type, you can choose Reference registered data or Copy all data. Branch versioning will only work if the web feature layer references registered data. When you choose to reference registered data, any changes you make to the web feature layer, such as adding, updating, or deleting features, will be reflected in the enterprise geodatabase. If you choose to copy the data instead, a web feature layer containing the data will be published, but it will have no connection to the enterprise geodatabase and version management won't be enabled.

5. Under Reference registered data, ensure that Map Image is selected. Check the Feature check box.

   

6. Scroll down. For Share with, check the ArcGIS Enterprise check box.

   This check box ensures all members of your organization will have access to this web layer.

   

   Next, you’ll enable the Version Management capability. This capability will allow you to take full advantage of branch versioning, for example, to create, modify, and delete versions, and to reconcile and post edits for versions.

7. At the top of the pane, click the Configuration tab. Under Capabilities, check the Version Management check box.

   

8. Click the Configure Pooling button. For Instance Type, choose Dedicated instance.

   

   This is a requirement for publishing branch versioned data.

Note:

You can read more about sharing parameters in the Share branch versioned data documentation.

Fix analyzer errors and publish

Before you click the Publish button, you’ll analyze the feature layer to learn whether anything needs to be fixed before publishing can succeed.

1. At the bottom of the pane, click Analyze.

   

   The pane displays the Messages tab. It lists a number of analyzer warnings and two analyzer errors. You need to address the errors before you can complete the publishing process.

   

2. Click the arrow next to the first error to expand it.

   

   This warning indicates that the source for both layers is not registered with the server. You will address this by registering your enterprise geodatabase with ArcGIS Server.

3. Under the first error message, right-click the first submessage and click Register Data Source With Server.

   

   The Add data store window appears.

   Recall that your goal in this sharing process is to create a web layer that references the data stored in your enterprise geodatabase, rather than to make a web layer that is a copy of that data. To achieve this, you need to register your enterprise geodatabase as a data store with your ArcGIS Server site. This will ensure that the web feature layer published to your portal references the feature class in your enterprise geodatabase. You can think of the data store as the connection between your ArcGIS Server site and the enterprise geodatabase.

4. For Title, type MadridDataStore.
5. For Tags, type CENER, solar potential, Madrid, branch versioning, Esri.
6. Click the Validate button to validate your server connection.

   

7. For Share with, check the ArcGIS Enterprise check box.

   

8. Click Create.

   In the Share As Web Layer pane, a green check mark appears next to the first submessage to indicate that the layer’s data source is now registered with the server. Since both the Buildings and Neighborhoods layers have the same data source, you don’t need to repeat these steps for the second submessage; creating one data store will resolve this error for both layers.

   

   Next, you’ll address the second error.

9. Right-click 00374 Unique numeric IDs are not assigned and click Auto-Assign IDs Sequentially.

   

   This is a requirement when sharing a web layer. It ensures layer IDs remain static when the web layer is overwritten.

   A green check mark appears next to the error.

10. At the bottom of the pane, click Publish.
11. When publishing is complete, click the Manage the web layer link.

    

12. If prompted, sign in with the same portal user account you used to sign in to ArcGIS Pro.

    Your portal appears, showing the item page for the Madrid Solar Project map image layer that you just created.

    

13. On the ribbon, click the Content tab.

    There are three new items in your portal: a feature layer, a map image layer, and a data store. All three items are shared with your organization.

    

14. For the Madrid Solar Project item, click the arrow next to Feature layer.

    

    The Madrid Solar Project web feature layer contains two sublayers: Buildings and Neighborhoods. In the next tutorial, you will add these layers to a map in ArcGIS Pro and edit them.

15. Close the web browser and ArcGIS Pro. There is no need to save the project.

In this module, you added the two feature classes to the map and applied symbology to better represent the solar potential of each building. You then published the data with the Version Management capability enabled and addressed two analyzer errors.

In this tutorial, you made a database connection to an enterprise geodatabase and loaded two feature classes into it. You prepared the data for publishing by registering the datasets as branch versioned. Finally, you connected to the portal with an account with publishing privileges and published a new web feature layer named Madrid Solar Project.

You will use this web feature layer to calculate and report solar potential for each building. Because it is branch versioned, multiple users in the CENER organization will be able to edit this data at the same time, allowing the project to progress faster.

In the next tutorial, Make edits in a branch version, you will learn how to consume the web feature layer in ArcGIS Pro, create named versions, connect to a named version, and perform edits.

Acknowledgements

• The Buildings feature class is from the Potencialidad solar de las cubiertas de los edificios de la ciudad data shared on Ayuntamiento de Madrid geoportal (accessed October 4, 2023; last updated November 8, 2021).
• The Neighborhood feature class is from the Barrios municipals de Madrird data shared on Ayuntamiento de Madrid geoportal (accessed October 3, 2023; last updated December 7, 2021).
• World Topographic Map sources: Esri, TomTom, Garmin, FAO, NOAA, USGS, OpenStreetMap contributors, and the GIS User Community