Feature services support both versioned and non-versioned data with the Sync capability. This article will focus on syncing traditional versioned data.
If you’re not sure what we mean by a version, have no fear. A version is sort of a view of an enterprise geodatabase that compartmentalizes edits. Versioning your data allows multiple editors to alter the same data without applying locks or duplicating data. When you first connect to the enterprise geodatabase, you are connecting to and working with the Default version. It cannot be deleted and essentially represents the current state of your data. You can also create and work with named versions. See the following topic on versioning for more information.
Sync can be used while preparing read-only services and read-write services to use in offline workflows. Let’s distinguish between these two. Read-only services allow you to download the latest changes from the server but not make edits and upload from the client during sync. Read-write services allow you to not only download the latest changes from the server, but also upload edits made locally on the client during sync. To learn more about preparing your data for offline use, click here.
Let’s get to the fun part, taking your data offline. When you work with your published feature service, more than likely you’ll be working with it in a map. When you download and take a map offline, the map can contain more than one type of service. Maps can have feature service layers that are read-only and layers that are read-write. Each is taken offline in a separate back-end process when you take the map offline. The following describes the process of taking read-only and read-write services offline.
Read-Only
When you take a map offline that has only Query and Sync capabilities, it will create a read-only copy of your data. With read-only copies, the map will be downloaded from the published version. This means that when you sync, edits from the published version will be downloaded to the client. Prior to 10.6.1, if you were a data owner, taking your data offline would create a read-write replica. This allowed you, as an owner, to make corrections and update your offline data regardless of the capabilities set on the service. The only way to get a read-only copy was to create the service as a non-owner. In 10.6.1, a change was made for versioned data to create read-only replicas, even if you are the owner. Since versioned data is typically administered in ArcGIS Pro or ArcMap directly from the enterprise geodatabase, this change simplifies the process without affecting data management workflows.
In the next section, we talk about taking read-write feature services offline where additional versions are created and additional data management steps are required. These steps are not required when taking read-only feature services offline as the additional versions are not created. It’s important to note, however, that hidden, system versions are created even for read-only feature services. Hidden system versions are managed by the system and do not appear in the version manager. These are needed by the sync process to determine the edits to download. You should make sure to sync your offline data on a regular basis and unregister replicas from the server that are no longer in use. This will help make sure that the version compress process is working effectively.
Read-Write
When you take a map offline that contains versioned, editable feature service layers (read-write), the copy is created from a version that is a child of a published version. Meaning, if you publish a feature service from the Default version, when you take the map offline the copy will reference a version that is a child of the Default version. The way the version is created depends on whether you are using version per offline map (default) or version per user. When you sync, edits uploaded from the client go into the child version, not the published version. This means that you will not see your edits when you query the feature service from the published version. Likewise, edits downloaded from the server will also be from the child version, not the published version.
To share edits across multiple read-write clients and the published version, you need to run a reconcile and post process. You can run this process manually in ArcGIS Pro and ArcMap, but the most efficient way to do this is by running a reconcile and post python script, allowing you to execute it on a schedule, e.g. nightly.
It is highly recommended you review this topic for information on how to best organize the workflows with sync and versioned data.
Commenting is not enabled for this article.