Managing ArcGIS applications

Feature layers includes a Sync capability, which when enabled, allows client applications to take feature layers offline, perform edits and sync it back to the layer. When you checkout some features and store it offline in the client, you call that a replica. The FeatureLayerCollection class under the features module allows users to create and work with replicas. The workflow of using sync involves these three operations:

To create a replica, we need a feature layer that is sync enabled. We can use the syncEnabled property of a FeatureLayer object to verify that. Further the syncCapabilities property returns a dictionary with fine grained sync capabilities

In [1]:

# connect to a GISfromarcgis.gisimportGISimportarcgis.featuresgis=GIS()# connect to www.arcgis.com anonymously. # we will use a public sync enabled feature layer

To create and work with replicas, we need to create a FeatureLayerCollection object. A FeatureLayerCollection object can be created from either a feature layer Item or directly using a feature service URL.

Here, we will connect to a sample service by esri with URL https://sampleserver6.arcgisonline.com/arcgis/rest/services/Sync/WildfireSync/FeatureServer/

Now, let us create our own replica of this feature layer. The create() method accepts a number of parameters allowing you to adjust what needs to be replicated and customize other options. For more information on this operation, refer to the documentation here.

The full capability of the sync operation allows you to check out data from a feature layer, make edits and sync the deltas (changes) back to the server and update the features. This is popular in use cases which involve client applications such as ArcGIS Runtime or ArcGIS Desktop applications check out data, go offline (such as in areas where network connectivity is limited), make edits, then synchronize the data back to the server and update the features. The capability allows multiple clients to do this in parallel, thus enabling a large data collection effort.

However, if your purpose of a replica is only to check out the data (one directional), then you can verify if the extract capability is enabled on the feature layer and create a replica that is just meant for data check out. We will see this use case below:

In [ ]:

# list all capabilitieswildfire_flc.properties.capabilities

Out[ ]:

'Create,Delete,Query,Sync,Update,Uploads,Editing'

This layer has disabled 'Extract'. Hence let us search for a different layer

In [ ]:

portal_gis=GIS("portal url","username","password")search_result=portal_gis.content.search("Ports along west coast","Feature Layer")

Thus, we were able to checkout data from this feature layer into a file geodatabase. Clients can use this data in any way they wish, for instance, publish it as another feature layer to a different portal or just store it for archival.

The sync operation is expensive on the resources of your web GIS. Hence, it is a good maintenance practice to remove unnecessary replicas. An ArcGIS admin could use the ArcGIS Python API to script and automate the process of scanning all feature layers and removing stale replicas on each of them.

A replica can be removed by calling the unregister() method and passing the id of a replica that needs to be removed.

In [ ]:

# Let us query all the replicas registered on the ports feature layer from beforereplica_list=ports_flc.replicas.get_list()