RegisterGeodatabaseAsync does not work with versioned data

872
12
03-31-2017 10:57 AM
MVP Regular Contributor

I have had this conversation with multiple people on the development team at conferences over the couple years.  Everyone will always assure me that it will be/is possible to register an offline database that uses versioned data.  Because I had only done this on pre-release on beta versions I took their word is being true once the 100.0 version was released.

However, after finally getting around to setting and running tests with the release version I will again argue it is not possible.  Whenever I try I get the following error.

Esri.ArcGISRuntime.Http.ArcGISWebException: Unable to complete operation.
at Esri.ArcGISRuntime.ArcGISException.HandleCoreError(CoreError error, Boolean throwException)
at RuntimeCoreNet.GeneratedWrappers.Interop.CheckError(IntPtr errorHandle, Boolean throwOnFailure, GCHandle wrapperHandle)
at RuntimeCoreNet.GeneratedWrappers.CoreTask.Get()
at Esri.ArcGISRuntime.Internal.CoreTaskExtensions.TaskCompletedCallbackHandler.OnCompleted(Object sender, EventArgs e)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Esri.ArcGISRuntime.Internal.CoreTaskExtensions.TaskCompletedCallbackHandler.<CreateInternal>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The code itself is incredibly simple.  So I am not sure where there would be an error in the code

var gdbTask = await GeodatabaseSyncTask.CreateAsync(new Uri("https://portaldev.domin.com/server/rest/services/Operations/UpdatableFeaturesService/FeatureServer"), _portal.Credential);


Geodatabase gdb = await Geodatabase.OpenAsync(@"D:\Mobile\Operational\Bidirectional\UpdatableFeaturesService.geodatabase");
await gdbTask.RegisterGeodatabaseAsync(gdb);‍‍‍‍‍‍‍‍‍‍

Also, looking at the documentation I notice this piece about registering offline databases

After taking copies of the original database, do not sync changes to the original until all copies have been registered.

Perhaps I am unclear on what that means, but in a large implementation this seems an impossible condition to meet.  We are deploying to over 600 users there is no way you can get every machine setup in advance of some users going out in the field and making edits that need to be synched.

Justin Colville

Will Crick

Tags (1)
12 Replies
New Contributor III

Well, I won't be able to test this until I get back to work but you may be right based on the REST API documentation:

ArcGIS REST API 

When you register an existing runtime geodatabase with a FeatureService you use the replicaOptions parameter like so:

replicaOptions = {"registerExistingData": {"refReplicaId": "{4721B2DD-CAE4-4a0f-B4E2-EAEB0AA80B0A}", "refReplicaServerGen": 100}}

The documentation on this property states:
Versioned data (layer property: isDataVersioned = true) is not supported with the replicaOptions parameter at this time.

Thus this appears to be a limitation of ArcGIS Server, unless the docs are out of date and support has since been added.

MVP Regular Contributor

Thanks for pointing to this out.  Not the answer I was looking for but at least it confirms my belief it is not supported. Digging into the depths of the rest API can be quite cumbersome.  I think the lack of ability to register an existing versioned replica makes using a versioned workflow near impossible if the offline dataset is large, because the combined time to generate and then download the replica is prohibitive

New Contributor III

Joe, are you successful with the same deployment practice using archiving instead of versioning?  

Reply
0 Kudos
MVP Regular Contributor

Yup

Reply
0 Kudos
New Contributor III

Care to share?  Is that a one-way replica?  No multi-sync from the field?  No backflow of information to the field?  Do you sync once, then recreate the one-way replica for each user?  Seems cumbersome.  Anyone from Esri care to elaborate?

Reply
0 Kudos
MVP Regular Contributor

What I have setup right now is to generate an initial replica of my non-versioned archive enabled database.  We have made the trade off to move this direction because the versioning scheme is a disaster, in my opinion, for versioned replication.

An issue I have found is that when generating a replica it will only sit on the server for a little while before being deleted so you need to generate (I do though the runtime API and then make a copy of that replica but you can do through rest directly).  If you do through rest you need to copy off the server after it is created.  Our approach right now is to put those replicas on Portal.  I zip up and tell portal it is a code file because it will load that way, defining the zip as some types Portal checks the file and it won't load.  On the clients I download the Portal item, unzip and call Register of that database.  At this point it will sync changes from that user.

Yes it is cumbersome.  I think that the new replication approach is poorly designed and not well thought out, especially for a large offline deployment.  Using versioned data in a large deployment is not possible, unless you consider managing 1000 versions realistic.  There is no way to have reconcile and post working efficiently and stable with that many versions to achieve a near real-time field updates.  Not to mentions the administration nightmare.  The limitations on replicas only having a single feature class per layer (i.e., two layers pointing to a single feature class) makes designing offline databases very difficult.  To see the same data symbolized in two ways I now need to have two offline databases and all the deployment and client side effort that involves.

Good luck -- joe

Reply
0 Kudos
New Contributor III

I (we) agree minerjoe.   There's got to be a better way to maintain a versioned workflow, but still allow mutliple(100's) field users to edit offline and sync back to the same version.  I like your use of portal for the deployments - that's great.

This is probably a stupid question, but before we give up on the versioned RegisterGeodatabaseAsync , I've got to ask.  Are you using the one way replica and only pushing updates to the server - or have you figured out how to make archiving work with the two way sync/replica?  I can't find any documentation supporting two way with archiving, but I'm also not seeing anything concrete saying you can't do it either.

Cory Eicher‌ , we've been sideloading syncable data for years - I'm starting to miss 'arcgis mobile'.  It had problems, but at least you could sync!!

Reply
0 Kudos
MVP Regular Contributor

I can sync both directions using the archive model.  But I agree I am missing arcgis mobile.  I think from an offline perspective the way the mobile for Windows API handled things worked far better than the existing replica model.

New Contributor III

We recently encountered the same exception calling RegisterReplica using v100, UWP flavor. In an earlier project, we were successful sideloading the initial .geodatabase to devices and ensuring that RegisterReplica was called once prior to sync. However, we were using archiving, not versioning.

I would be interested to hear other information on this topic. At the very least, it seems the doc could be improved. In our situation, we are dealing with fairly simple sync use cases. In the simplest case, sync works for us from Device 1 (no reg replica required). My understanding is that Device 2 can sync against same replica (hitting same version on back end). We also have additional options which are outlined in the doc, including creating a version per device.

To clarify, I think we share the same requirement as the original poster of desiring a model which scales to potentially many users/devices, but allows sideload of the initial sync-able .geodatabase.

Reply
0 Kudos