Typically, editing web feature layers is the same as editing other vector data. The types of edits you can make to a web feature layer are controlled by the feature service properties. There are different editing patterns that are dependent on the data being published, the editor permissions, and which capabilities are enabled on the service. One such capability that affects editing patterns is the version management capability. When publishers enable this capability when they publish branch versioned data, it changes how editors can edit the web layer in ArcGIS Pro.
To learn more, see Editor permissions for feature services and Additional layers and capabilities.
Edit web layers without version management
In most cases, when you edit a web feature layer in ArcGIS Pro, the version management capability is not enabled. When making edits to these layers, most of the edits performed are stored locally on the machine running ArcGIS Pro before you save them. You can maintain or discard edits using the undo and redo options available in ArcGIS Pro. You can continue to undo and redo individual edits until you save or discard your edits.
Note:
Updates and deletes, including undo and redo operations, are stored locally until edits are saved or discarded. When you insert features, the features are immediately added to the feature service and stored locally.
Caution:
You can publish branch versioned data without the version management capability enabled.
In this scenario, editing always occurs against the default version. Editing behaves in a similar manner to editing the default version when the version management capability is enabled. Edits are saved immediately to the underlying data source, and capabilities such as reconcile, post, change version, view differences, create version, undo, redo, save, and discard are not available.
See Share branch versioned data for more information.
Save or discard edits
When you save, all updates and deletions you made since the last time you saved are applied, one at a time, to the source data. Discarding your edits removes them from the local machine. When edits are discarded, deletions are also sent to the server to undo inserts performed during the session.
Due to the client-side storage of multiple edits, the save or discard edit operation may take a long time. This also prevents updates and deletions from being visible to other users of the service until edits have been saved. It is recommended that you save edits frequently or turn on the option to save edits at recurring intervals. When you choose this option, you can set the application to save based on a time interval or on a certain number of operations. Doing this automatically saves edits to the data source regularly and allows the save operation to finish more quickly. As with other data sources, once edits are saved, they cannot be undone.
Functionality that relies on server-side edit behavior may be delayed or unavailable while in an edit session. The following are examples of this type of behavior:
- Navigating from the origin to destination in a relationship created in the edit session is unavailable.
- Attribute rules that are excluded from client-side evaluation do not display calculated values.
If your workflow requires immediate access to these behaviors or to view edits performed by others, it is recommended that you save edits frequently or turn on the option to save edits at recurring intervals. To prevent any delay, you can save after every operation. It may also be necessary to refresh the map to observe these server-side behaviors.
Note:
If an ArcGIS Pro session closes unexpectedly with unsaved edits to inserted features, these inserted features must be manually reviewed in a later session.
Edit web feature layers with version management
If the publisher enabled the version management capability when publishing the web feature layer, your editing workflow will be different than when you edit feature layers that do not have this capability. The version management capability is only available for branch versioned data.
When you edit a web feature layer with version management enabled, you either edit the default version or a named version, if one exists. See Connect to a branch version for instructions on how to access a named version in a map.
There are important differences when editing the default version compared to editing a named version. When editing the default version, edits are saved immediately to the underlying data source. When editing a named version, you can undo and redo individual edits as well as save or discard groups of edits. These capabilities for undo and redo or save and discard are not available when editing the default version.
To provide these editing capabilities in a named version, the version being edited must be isolated from other editors. To accomplish this, ArcGIS Pro uses locking mechanisms to limit access to versions for viewing or editing. The locking model allows for multiple simultaneous viewers or a single editor.
- Once an editor begins editing a named version, an exclusive lock is obtained, and no other users can connect to the version during the edit session.
- When an editor begins editing a named version, they must be the only user connected to that version.
Setting the version access permission to private when you create a named version helps avoid these blocking situations.
Additional editing behavior
Similar to the behavior described above with version management capabilities, additional editing behaviors are available based on the service and layer properties. The goal of using these behaviors is to reduce edit failures due to file size limitations or processing time.
Upload with asynchronous apply edits
Two properties determine how edits to the server are communicated: supportsApplyEditsbyUploadID and supportsAsyncApplyEdits. If a service has the supportsApplyEditsbyUploadID and supportsAsyncApplyEdits properties set to true, ArcGIS Pro can use upload and asynchronous processing when using the applyEdits operation to perform edits. When determining when to use upload and asynchronous processing for applyEdits, an algorithm described below is used.
For upload, the request size is used. The request size is determined by the payload size as well as an estimate of the URL encoding size for the request. If the request size exceeds the size of 6 MB, upload is used. The upload process aims to reduce timeouts by packaging the edit payload into a file, which is uploaded with a unique item ID. The upload's item ID is then referenced by an applyEdits call to apply the service edits.
For more information on uploading files, see Uploads.
For asynchronous applyEdits, a calculation is made to determine the cost for each applyEdits service request needed to perform a given edit. This calculation takes into account the number of records being edited and the payload size of the edit. These values are then used in the formula below:
1 + (Record Count / 1000) + (Payload Size (MB) / 6 MB)The resulting value is then rounded up to the nearest integer value. If this rounded value equals or exceeds 3, the applyEdits call is made asynchronously. If the rounded values does not equal or exceed 3, the applyEdits call is made synchronously.
For more information on asynchronous applyEdits, see Apply Edits.