Is this correct? Pro-editing versioned feature classes published to a federated server result in extra child versions that revert edits and do not unregister.

[ThomasColson]

In SDE 10.6.1 GDB (SQL 2014 CU11 ENT), create a database. Provision with a point, line, and poly FC using Geography storage type, and add a photo attachment able to the point FC. Enable editor tracking on all, register as versioned but do not check the “Move edits to base” thingy. Then enable archiving on all. Create a child version.

In Pro, add the 3 FC’s to a map using the child version connection string, share as web layer, share to PTL 10.5.1, and pick a federated (not hosted) 10.5.1 server, where the SQL GDB is a registered data store using the default version, and where there is also a registered data store using the child version in the connection string. Enable the time zone do hicky, and check export data and sync and feature service. Validate reports no errors, and yes, you are using the child version, and the child version data store. Publish to the root of the server (no folder stuff).

In Arc Map 10.5.1, add data from PTL, create local copy for editing. In Pro, GDB Connection properties, note that no versions have been created. In Arc, drop a few points, delete some, etc…sync back to server. Note how the data synced in the map view in Arc, and in a Portal map, and looking at the map service on another Arc Map different computer. All are pointing to the same child version that is driving the service.

In Pro, add the same service to a map (from Ptl), download the map. Note that a new child version [username_unixtimestamp] is under the original child version in GDB connection properties. Add some new points, delete some. Hit sync. Happens…really fast. Go to PTL, none of your edits are shown in the service, which is driven by the first child under default. Make more edits. Sync. More edits. Hit remove. Wait for it…….all your edits are now gone! Note that child version [username_unixtimestamp] still exists.

I’ve figure this much out: your edits are syncing to the “child of the child” that was created when you hit download map. However, when you remove the offline map, guess what? Your edits are reverted in the child-of-child version! They’re gone, as is the SQLite GDB that gets created when you download the map.

I can’t imagine how this would be the expected behavior. Imagine a database with 6 child versions under default (for regions of the country). Each child is pushing its own feature service. 100 users hit each child in Pro, and “Download Map”. There’s now 100 children that now need to be rec’ed and posted to each child.....and why are the edits removed when I remove the offline map?

I haven’t tried this with “Moving edits to base”, but that’s a versioning workflow I don’t support, and I can’t find in the documentation where not checking move edits to base results in this behavior. It’s entirely possible I’ve missed a checkbox somewhere, but I’ve checked them all on and off and get the same behavior.

Confident this is an operator headspace error and one of you know the correct box to check....

[ThomasColson]

So it turns out archiving and not moving edits to base is the only way to go Enabling archiving—ArcGIS Help | ArcGIS Desktop  so you're stuck with all of those "child of the child" versions. Head scratcher for sure. 

[ThomasColson]

Same behavior if I just pull it off of default. Children of the default, when I sync and remove the map, the map reverts to default. Rec and post works, but the child versions fails to delete. But it gets better......I said the rec and post GP tool worked. What also worked well, was....everything was deleted from both versions!  weird what appear to be null geometry issues...(original points are in the base table, whatever was in the child version that got rec and posted is not there....). 

[ScottPrindle]

Hello Thomas,

This is the same sync workflow that has been used with Collector for some time now. There is a bit of a footprint in the number of versions created, but these should be managed by ArcGIS Server as long as the offline map and its associated replica remain open. The way that ArcMap edits a feature service does not use sync, so it can't be used as a direct comparison for this workflow in Pro.

When publishing versioned data as a feature service, a new version "child of the child" should be created for each downloaded map. This note describes how this child version is named. Since this is a versioned dataset, the need to reconcile and post will be maintained on all of these offline maps. If you have 100 people downloading an offline map, that's 100 child versions to maintain the version hierarchy down to the client.

When you delete the offline map in Pro, its replica at REST should also be removed. In your versions at this time, "Esri_Anonymous_<feature service name>_<ID>" will remain. Since this is versioned data, your edits remain in this child version until you rec and post back to the first generation child (which the feature service is using). As long as the offline map was synced before it was removed, all edits should be in that "child of the child".

As you noted, archiving is another option for managing edits for sync. If versioning is not required for your data model, or the rec and post process is too time consuming for the number of editors you'll have, then archiving may be the way to go. In the end, offline maps used by Collector and Pro are extending the versioning tree a step further via replication. Some of the links above can be used to build context around what all of the moving parts in Pro, ArcGIS Server, and the Enterprise Geodatabase are doing. Let me know if this raises any new questions!

Thanks,

Scott

[ThomasColson]

I get all the steps, as described, as "How it should work", but what I'm seeing is, upon sync,and sync and remove map, whatever was on the SQLite GDB is not making it to the child, or the child of the child. There's nothing to rec and post. That specific issue sounds like a TS case....stay tuned....I'm hoping other GN folks have some thoughts on this and I've missed one little itty bitty check box somewhere. 

With regard to comparison to the offline editing workflow in Arc, I think the distinction is very important in terms of sys admin workload. I was very excited with Pro came out (Finally!) with the "Equivalent" to offline editing in Arc. I've put a few months into testing it, developing and documenting workflows, and have rolled the procedure out to my staff for beta testing. Now on to the next phase, do it all over on versioned Geodatabases. A particular need came up, a nationwide application where we could have up to 9 "regional" child versions of default, where we need to support offline-capable editing of a feature service connected to each one of those versions, due to poor network performance being a barrier to "live editing" of a feature service in Pro for about 75% of our customers, and, what has a slight chance to shake out as a requirement to support the same on collector, for say 10%. So tuning on Archiving is the only way we can support that offline-capable-feature service requirement, unlike Arc, which doesn't require archiving to support offline. I may be reading your response wrong? But my interpretation is, we're going to have to rec and post, on average, 50 (extreme top end if every single customer actually edits these data) child-child versions for each regional version (450 potential)? This gets better when that process is repeated, so let's say 20% of our customers want to do an offline edit workflow every 3 months. This is where the comparison to Arc comes in, again, I may be wrong, but with "Create Local Copy for editing" I don't recall having to rec and post each individual check out to a child of default, or default. Consider I'm no expert at versioning and avoid it whenever possible if the data steward needs don't require it. I get how and why archiving is needed to get that offline capability with Pro, and I'm a big fan of offline working starting at 2.1, but having to put hands on that many children is.....not workflow I can support, nor is locking folks into "live editing" when it takes all day to download a single windows update. 

[ScottPrindle]

Hey Thomas,

Archiving isn't required for offline workflows to be supported. When it comes to feature services and sync, the requirement is either enabling archiving or versioning on the datasets. At a minimum, one of these is needed for sync to function.

It sounds like there are two processes that we should separate to address the issues you've encountered:

1. Offline edits being synced to the "child of the child".
2. Unregistering the replica, and rec and post of the edits in the "child of the child" to the child, then to DEFAULT.

If your edits from the runtime geodatabase (.geodatabase) aren't appearing in the "child of the child" version, then there is something going wrong during sync. Number one should be verified before attempting to delete the offline map. During your testing, do you see any edits making it back to your enterprise geodatabase? If we can examine this part of the workflow, we can determine if there's a problem getting edits from Pro to EGDB.

Number two above is primarily a cleanup process. The replica that gets unregistered when you delete an offline map is maintained by ArcGIS Server and the geodatabase. Once you remove that, sync can no longer be done with the runtime geodatabase you had downloaded previously. As you noted, removing the offline map in Pro will also delete the runtime geodatabase from your machine. It is possible to make a copy of this file to back things up if you think things aren't going as planned (ex. location: C:\Users\username\Documents\ArcGIS\Projects\projectName\featureServiceName_GUIDvalue.geodatabase).

Based on all of the details you've shared so far, I would be curious if there are any errors or additional information in the ArcGIS Server logs at the DEBUG level. Information about the sync process will show up under the SyncTools GP service. This will purely be focused on figuring out what is going on with your offline edits, and isn't necessarily related to versioning yet.

At the end of the day if everything is working as expected, but the versioning management is still a headache(450 may get tedious without automation via Python), you might consider sticking with only archiving, but splitting out your regions with separate feature services. This would cut out any version trees you'd need to manage, where a region's data is dictated by a definition query on the layer (ex. based on a "region" field). This is just another approach to consider, but it could directly address your concerns about "child of the child" versions building up in your database.

To somewhat cover how ArcMap is editing with "Create local copy for editing": this client is taking more of a web editing approach to offline editing. It will query the service to place all of the data in a file geodatabase in your user profile. Any editing is done against that local data, which is technically offline. The difference is when you go to synchronize your offline edits, ArcMap will submit an applyEdits operation. This is essentially how a web application (Web AppBuilder, ArcGIS Online, etc.) will edit in a connected environment. The big difference between ArcMap and Pro is that when this "Create local copy for editing" process successfully syncs, the local copy is removed from your machine.

Pro is using a more complex process (with versioning/archiving and all that), but it will actually synchronize rather than submit an applyEdits request. Additionally, that offline map will persist, allowing a user to continue working offline, without creating another local copy for editing.

I hope this information is useful, but let me know if there are other concerns it raises.

Thanks,

Scott

[ThomasColson]

"Archiving isn't required for offline workflows to be supported." Am I reading Take a map offline—ArcGIS Pro | ArcGIS Desktop wrong? Seems the only way to achieve that is enable archiving....if that's NOT the case (I can still "Download Map with a feature service" and edit it offline WITHOUT having to enable archiving, that solves 90% of what we're dealing with today). 

However, we're not seeing the child sync hitting any version, including the child of the child, when we hit sync, or remove and sync, in Pro 2.1.2. We worked through some permission issues in SDE, but....nothing. As far as splitting the regions into their own FS's, that was (is) the plan, still seeing the "where are the edits" after sync (remember, nothing to rec and post). 

"During your testing, do you see any edits making it back to your enterprise geodatabase?" No, that is where the mystery lies. 

I'm working up a detailed steps to repro, and will submit a TS case tomorrow. Still convinced a)missing a check box and b)reading the wrong documentation. 

Your response is incredibly helpful, I'm printing it off to take home and read.......

[ScottPrindle]

Hey Thomas,

I don't see any references to archiving or versioning in the link you shared. However, there is a related link here, which is listed on that page. This outlines some of the different approaches to preparing your data for offline use, whether that's with versioning or archiving. There may be multiple ways to get to the same result, but we certainly want to figure out what's happening with your offline edits in the current workflow.

It's also possible that something is amiss in the data model or the workflow in Pro. I would definitely encourage a support case to get an analyst's assistance in troubleshooting the issue. If you are seeing essentially the same behavior between versioning and archiving (the offline map is successfully created, but edits that are synced do not appear in the enterprise geodatabase), then the problem doesn't lie with those settings specifically, but perhaps somewhere else (data model, DBMS permissions, web map permissions, Pro functionality, etc).

Sync is a pretty complex process, and it is still pretty new to Pro, as you noted previously. There are database replication topics, ArcGIS Server/web server topics, ArcGIS Pro client workflows, etc. All of these things overlap and really muddy the waters when something goes wrong, so I think it's important to identify and isolate every variable at play.

Please feel free to PM me if you have any questions or issues with the case you create with us! As more is discovered about the sync issues you're encountering, keep us posted in this thread.

Thanks,

Scott

[ThomasColson]

This case finally closed, there were a lot of issues found but ultimately the issue causing the problem was a configuration error (Configure your portal to use a reverse proxy server—Portal for ArcGIS (10.6) | ArcGIS Enterprise ).

Two bugs originated out of this BUG-000114839 Overwriting an existing service from a federated ArcGIS Server instance from ArcGIS Pro fails and BUG-000115083 When viewing the catalog window in ArcGIS Pro. Double clicking in the name field of an offline feature service causes all text after the @ symbol to disappear (because in our environment, the grandchild version name is getting an @ character after the user name) Rendering the local child un-usable as it cannot sync back to its parent.

We spent a lot of time reviewing the disconnected editing workflow using Pro and versioned feature classes, and came to the stunning but "by design" discovery: When a non DBO created a child version from Default, and publishes a feature service from it, any offline edits to that feature service in Pro will create a grand-child version. Upon sync and remove, the editor will then be reverted back to child version (the one driving the feature service). No dispute as to how the versioning workflow works, but what do you think those editors are going to do? "Crap, my edits didn't take! Let me do that again.....".

But wait, it gets better. So no disputing that one has to reconcile and post grand children to children for those deltas to hit the feature service. Well-documented behavior. But guess what? Only the DBO (sysadmin) can do that! Because.........the service account running the GIS server/Ptl is the owner of the grandchildren, not the person that created the child off of default....unless....the child version is changed to public, which kinda defeats the whole purpose of versioning (you know, so no one else messes with my data....). In a nationwide application with potentially hundreds of editors and several children of default telling folks that "Pro is better!" doesn't carry a lot of weight.  Sure, we can python automate the rec and post process, but call me old-fashioned, the point of rec and post is to see where conflicts pop up and make human decisions about how to resolve them (like when the editor whom correctly inferred their edits didn't take downloads and edits the same offline feature service 3 times). 

Thanks to tech support, they got a lot of folks involved that had "Engineer" in their title. 

FWIW, Offline Editing in Pro where your stuff isn't versioned still blows Arc Map out of the water and has the added side benefit of making the same data mobile-editing-ready. Think I'll stick to non-versioned feature classes and just eat it on data quality and protection.