RegisterGeodatabaseAsync does not work with versioned data

[JoeHershman]

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‌

[JoeHershman]

My testing has found that no matter what, in a versioned deployment the replica needs to be generated and downloaded onto the device via the API.  If it is the same user it will not create a new version, but the download process still needs to be done from that device.  I have tried to sideload a replica created on one device onto another which is being logged onto by the same user.  I have seen data move back to the server and from server to device, but not correctly.  I would observe something like device B pushes the edits to the server and they are seen on the server, but device A would not pull those changes.  The correct round trip behavior was not occurring.  If I did the full download process using the API from each device, I would only have the one version and things would sync correctly.  This, however, is not a valid workflow because doing this requires a replica be created every time you want to download a database.

[deleted-user-Ohz6rwd1kavx]

We did some testing with this recently. We used an app we have built on the ArcGIS Runtime SDK for .NET v100, UWP flavor.

Our underlying feature class is versioned, and we are syncing two way.

We tested creating features on 2 different devices and syncing. We also used ArcMap to check the contents in the back-office geodatabase.

Findings:

• If we used same .geodatabase (same replica) on Device 1 and Device 2, sync ran without errors, but it did NOT run as expected.
  • We specifically observed issue where features created on Device 1 and uploaded to server, were not correctly downloaded to Device 2.
• We changed 2 things (yes, I know this violates scientific best practices)...
  • We changed feature service advanced setting to create version per user (not per replica).
  • We created 2 different replicas (manually via REST endpoint) and sideloaded these replicas to Device 1 and Device 2
• ... after making these changes, we re-ran our same tests and things worked well.
  • We did not observe same issue as above.
  • We did not find any other issues.

So, basically this supports what you posted. The only difference, which could be useful in some scenarios, is that we were able to create our replicas and sideload. It makes sense that this works as it is basically the same thing as creating using Runtime SDK on device and downloading.

-Cory

[JoeHershman]

I have still seen the behavior you describe in your first bullet point even when following the workflow you present in the second description.  I would never get a full round trip sync from multiple devices.  Now one thing we do have that (I would guess) impacts things is we use IWA.  So that second user is not the same actual user that created the replica.

This goes back to something I have brought up before the idea of using a fake user as the sync user.  However, that would basically mean having a separate AGS at minimum to use for generating replicas (if not a separate Portal deployment).  This over complicates deployment to a point that it is no longer acceptable.  Because our primary Portal is used for much more than just hosting mobile sync, and IWA is a critical requirement of the deployment.

I would love to see esri invest more effort in a robust versioned offline workflow that could also work in a scenario where multiple services are required for 100s of offline users.  Because of the limitation of a single feature layer per feature class it is difficult to find a approach that would not require multiple services for a large deployment