Replication of 'sync' enabled data

Question

I have been having an issue setting up data replication using a geodata service on 'sync' enabled data. Does anyone have any ideas how to get past the issue below?

We have a cloud server with a number of datasets that are going to be used for offline editing in AGOL. To enable the data to be used offline, it must be stored as non-versioned. This is fine, no issues here.

The issue comes when we want to replicate the same data off the cloud server, to our servers within our network, for displaying in internal GIS viewers, etc. In order to replicate data, the data must be versioned.

So does anyone have any ideas how I can get around this issue when one process requires non versioned data while the other process required versioned data. I have tried and discounted the following idea...

- Having two copies of the data on the cloud server. One is non-versioned (the source data) and also have a versioned copy which is updated using delete/append. I can't really use this as this would mean that every time the data was synchronised through the replica, all data would be transferred each time as it would all be 'new' as the delete and append assigns new Object ID's. The download size would be too big to be practical.

Any other ideas would be appreciated.

Thanks

MalcolmJ · Answer

That's very useful information. Thanks for that

MarcoBoeringa · Answer

I have been having an issue setting up data replication using a geodata service on 'sync' enabled data. Does anyone have any ideas how to get past the issue below?

We have a cloud server with a number of datasets that are going to be used for offline editing in AGOL. To enable the data to be used offline, it must be stored as non-versioned. This is fine, no issues here.

The issue comes when we want to replicate the same data off the cloud server, to our servers within our network, for displaying in internal GIS viewers, etc. In order to replicate data, the data must be versioned.

So does anyone have any ideas how I can get around this issue when one process requires non versioned data while the other process required versioned data.

I think you are actually working outside the intended "scope" of this functionality of "offline editing in AGOL with 'sync' enabled data", when you attempt to replicate it back to "on premises" (at least at the current state of affairs / technology).

As this Help page clearly states:

"Do not use this scenario

�?�If you want to publish a service type other than a feature or WFS-T service.
�?�If your data already resides in an enterprise geodatabase.
�?�If you want to publish database tables accessed through an OLE DB connection file (.odc)
�?�If you want to synchronize changes between the publisher's machine and ArcGIS Server's Managed Database."

It seems "replicating" back is not supported in this scenario, also illustrated by the following remark on the same page:

"Once published, you and your users should only work with the data exposed by the feature or WFS-T service. If you want to update the data in ArcGIS Server's Managed Database, you can add the feature or WFS-T service in ArcMap and use the local editing commands to upload the new data."

So what can you do to move data back? According to the same Help page, you need to "copy" the data of the server manually:

"If you want to save your data before deleting the service, you can use the tools in ArcGIS for Desktop to export the enterprise geodatabase data into a file geodatabase that you can transfer to your local machine."

Also mind the big caveat(!):

"�?�Deleting the service deletes the service's data."

If you are not careful, and delete the service without backing up the data in the ArcGIS Server's Managed Database, you will have lost all edits synced to the offline editing Feature Service.

Also be careful when updating from the "on premises" to the ArcGIS Server's Managed Database, per this caveat:

"�?�Whenever you update your data on premises, you must do an overwrite of the dataset in ArcGIS Server's Managed Database in order for the server to reflect the changes."

Your other option is to NOT use offline editing, but only online editing and "normal" publishing of a Feature Service as described here. This will allow full synchronization back and forth between publisher's database and webserver's database. E.g. see this quote from that page:

"This scenario is also well suited for publishing feature services to on-premises or cloud servers. For example, if you publish a feature service using this scenario, edits made on-premises could be pushed to the server's geodatabase, thereby becoming available to end users of your feature service. Conversely, if web editors change any features in the server's geodatabase, the edits can be synchronized with the publisher's geodatabase."

Maybe that a future version of this offline editing functionality will contain more options, including a better option for synching back to the publisher's geodatabase, as it still seems in full development.