topic Re: RegisterGeodatabaseAsync does not work with versioned data in .NET Maps SDK Questions

RegisterGeodatabaseAsync does not work with versioned data

JoeHershman — Sat, 11 Dec 2021 23:32:34 GMT

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‌

Re: RegisterGeodatabaseAsync does not work with versioned data

NicholasHaney — Wed, 05 Apr 2017 23:31:57 GMT

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.

Re: RegisterGeodatabaseAsync does not work with versioned data

JoeHershman — Thu, 06 Apr 2017 00:09:50 GMT

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

Re: RegisterGeodatabaseAsync does not work with versioned data

KarynTareen — Tue, 25 Apr 2017 17:32:47 GMT

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

Re: RegisterGeodatabaseAsync does not work with versioned data

JoeHershman — Tue, 25 Apr 2017 17:35:41 GMT

Yup

Re: RegisterGeodatabaseAsync does not work with versioned data

KarynTareen — Thu, 27 Apr 2017 15:02:00 GMT

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?

Re: RegisterGeodatabaseAsync does not work with versioned data

JoeHershman — Thu, 27 Apr 2017 17:03:15 GMT

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

Re: RegisterGeodatabaseAsync does not work with versioned data

deleted-user-Ohz6rwd1kavx — Thu, 27 Apr 2017 17:16:47 GMT

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.

Re: RegisterGeodatabaseAsync does not work with versioned data

KarynTareen — Thu, 27 Apr 2017 17:30:50 GMT

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!!

Re: RegisterGeodatabaseAsync does not work with versioned data

JoeHershman — Thu, 27 Apr 2017 18:32:17 GMT

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.

Re: RegisterGeodatabaseAsync does not work with versioned data

JoeHershman — Sat, 29 Apr 2017 12:53:36 GMT

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.

Re: RegisterGeodatabaseAsync does not work with versioned data

deleted-user-Ohz6rwd1kavx — Thu, 18 May 2017 15:57:36 GMT

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

Re: RegisterGeodatabaseAsync does not work with versioned data

JoeHershman — Tue, 23 May 2017 14:19:37 GMT

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