Field Maps, Replicas, and enabling/disabling Sync via the ArcGIS API for Python

[AaronKoelker]

Often in our Field Maps mobile projects, we have a need to include non-editable reference data in the web map. Sometimes this reference data changes fairly frequently, and the hosted feature layer needs to be updated. In some instances, we've found the easiest/most reliable way to do this is to schedule an ArcGIS Notebook to do the update for us.

However, in order to take a Field Maps project web map offline, all layers in the map need to have sync enabled, regardless of whether or not they are editable. Sync can be enabled/disabled on hosted feature layers using the ArcGIS API for Python, which is required in order to make updates to the data, however, sync can not be toggled off if the hosted feature layer has any outstanding replicas.

So all that said, I am trying to figure out the best workflow to make automated updates to a hosted feature layer that has sync enabled, and may often have outstanding replicas as users check out the data for their offline Field Maps projects.

I know I can unregister replicas via the python API, however I'm wondering how that may affect other layers in the offline web map when the user later tries to sync. Since the service I'm unregistering would not be editable regardless, would this essentially have no affect on the user when they go to sync their projects? Or is syncing an all or nothing process, where other editable layers in their offline project with changes will fail to sync because their replica for a reference layer was unregistered? Hope that makes sense. Appreciate any help.

If nobody knows, I'll eventually try to set up a test and report back, but hoping someone else already knows the answer and can save me the trouble of setting that up.

[DougBrowning]

How big is it?  You could wipe the records and replace them instead of the entire service.  It would mean a lot of updates on a sync however.  Or you can edit dates and only update the changed records in the service.

I still really wish you could add VTPK as layers vs just basemaps.  We had a 3rd party app that could do that like 8 years ago.  We could have roads, streams, etc each as their own VTPK that we could turn on and off in the layer list.  Burning it all into the basemap is so limiting.   I asked several times to open this up but I am not sure they get it.  This asked me a bunch of questions but never did it.  It should be the best use case for VTPK really.  Basemaps as vectors makes way less sense than vectors as layers.  

[AaronKoelker]

@DougBrowning 

It's a pretty big service, and has multiple layers/endpoints. I actually am truncating the entire table and appending the new data back in using the ArcGIS for API for Python, which otherwise works fine, but I get an error whenever an outstanding replica is present. While I suppose I could make the service for the reference data editable, and try to apply the changes like normal field edits by checking out a copy, that would potentially open up a lot of room for field users to accidentally make edits to the reference data, if the web map owners don't have their web maps set up correctly to prevent that.

I was hoping these layers could be a resource for lots of different users within our org to include in a multitude of offline projects—and it wouldn't really be feasible to monitor every person that grabs them for a project and make sure that they set up their maps to prevent edits to the reference data, or expect them to read some specific instructions on the item details page that they might never even see.

It's entirely possible I'm completely over complicating this workflow and there is some simpler solution I'm just overlooking. I did consider creating a custom basemap, but a lot of the reference data isn't just visual reference, and is only really useful to some users if they can click on the features and get pop-up attributes.

Also, go Pack go!

[Kevin_MacLeod]

I agree Doug. Tiled vector layers are great. But in a perfect world, we could simply have feature layersn that are tile-able. So there is no need for twin layers where one has attributes (and is not visible) and the other looks good, for fast display. Best of both.  For now, I just enabled sync on everything, seems to work. 10.91 SDE.

Offline seems complicated. Support for many different use cases is by definition complex but I imagine 80% of customers have the same or similar need. A layer or two in Field Maps they edit, and then a few layers that are simply there for display. For example hydrants are editable and pipes are just for viewing in order to understand and confirm which hydrant is which.