Apply edits (online)

After you have edited your ServiceFeatureTable in the online feature service editing process, you can apply local edits to the feature service through a call to ServiceFeatureTable.applyEdits(). However, this method is only meant to be used for single table workflows or tables without geodatabase behavior. More commonly, geodatabases are more than single tables used to capture spatial data, they can provide functionality that realistically models the behavior of real world features. While performing editing operations, the geodatabase takes an active role to ensure the integrity of your data, often augmenting edits made directly to the data with automated changes or validation. Such changes are referred to as geodatabase behavior.

Examples of geodatabase behavior:

• Composite relationships: Causes a feature in the destination table to be deleted when a related feature is deleted in the origin table.

• Feature-linked annotation: Text in feature-linked annotation reflects the value of a field or fields from a feature in another feature class to which it is linked.

• Utility network association deletion semantics: Values in the UtilityAssociationDeletionSemantics enum describe how deleting a feature of a specific asset type affects associated features.

• Attribute rules: User-defined rules that can automatically populate attributes, restrict invalid edits during edit operations, and perform quality assurance checks.

These capabilities are honored by the ServiceGeodatabase class because it is a container for all the feature tables connected with a given feature service. As a consequence, the service geodatabase is able to respect and apply the defined behaviors of the underlying geodatabase. If edits are applied directly to a single service feature table without a service geodatabase, it may lead to data inconsistency. This is because your service feature table could be linked to other service feature tables in the service through one or more of the above mentioned geodatabase behaviors. Using a service geodatabase is recommended in such a scenario as it will apply any dependent edits that the geodatabase behavior may require.

The service geodatabase allows you to manage edits for all tables it contains, such as checking if the service geodatabase has local edits, applying all edits to the service, or undoing all local edits. Such operations affect all service feature tables in a service geodatabase. Additionally, when the service geodatabase supports branch versioning, you can get the available versions for the geodatabase, switch the current version, or create a new version. See the Use branch versioned data topic for more information.

Get the service geodatabase

If your application loads an existing ArcGISMap or ArcGISScene (from a web map, web scene, mobile map package, mobile scene package, and so on), a ServiceGeodatabase is created for every feature service that is referenced. You can use ServiceFeatureTable.serviceGeodatabase to begin working with the available service geodatabases.

If you need to load individual tables from a feature service, you can create a ServiceGeodatabase object first, and then use ServiceGeodatabase.getTable() to get the table. This is the recommended approach, rather than creating a new ServiceFeatureTable using its constructor.

Apply edits to the service geodatabase

After making edits to data within a feature table, the edits need to be packaged and sent to the feature service. Use the ServiceGeodatabase.applyEdits() method to send all changes in all tables to the service as a single transaction. This ensures that geodatabase behavior is appropriately leveraged.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
        lifecycleScope.launch {

            // Send these edits made in the service feature table to the online service by applying them to the table's service geodatabase.
            val serviceGeodatabase = serviceFeatureTable.serviceGeodatabase
                ?: return@launch logErr("Could not get service geodatabase from table.")

            val featureTableEditResultList = serviceGeodatabase.applyEdits().getOrElse { error ->
                return@launch logErr("Could not apply edits to service geodatabase: ${error.message}")
            }
            // Use the feature table edit results to view the applied edits.
            featureTableEditResultList.forEach { featureTableEditResult ->
                featureTableEditResult.editResults.forEach { featureEditResult ->
                    // The edit result for one feature.
                }
            }
        }

The advantage of calling ServiceGeodatabase.applyEdits() on the service geodatabase, rather than on each individual table, is that it ensures that all of the edit operations take place in a single transaction. Either all of the edits are applied or none of them. If you apply edits to each table individually, it is possible that only some edits will be applied (for example, if you lose network connectivity in the middle of the operation).

Apply edits in a branch version

The edits made to service feature tables from a branch version can be applied by calling ServiceGeodatabase.applyEdits() as described previously to ensure all the edits in the local tables are applied correctly to the feature service. These edits, now applied to the service, are contained to the branch version. In order to merge these changes from a branch version into the default branch version, a back-office operation is required. Using ArcGIS Pro, a GIS professional can reconcile and post the branch version into the default version so that viewers of the default branch can see the edits. See Branch version scenarios for more information on this multiuser editing workflow.