Collector App not syncing

[ZacharyHart]

Environment:

• ArcGIS Server Enterprise Standard 10.4.1
• SQL Server Standard 2012
• Collector 10.4.2 Android
• Web map hosted on AGOL

Accessing the map and taking it offline initially works just fine; existing features in the FS appear in the offline map as well. Able to navigate & collect just fine. When I sync, the process runs, error but nothing is pushed up. If I make edits elsewhere (using the FS OR editing directly in desktop), no changes are pulled down either. No errors in the server logs. I tried connected via WiFi as well as (4G LTE) Cellular and still nothing syncs.

No attachments or related tables. Editor tracking enabled and two fields have domains.

I'm at a loss as to where to start diagnosing this problem.

[ScottFierro2]

So guess as step 1: Log into Server Manager and confirm the sync service is started and has available instances running.

Step 2: Can you make edits in AGOL, save them, close the browser, go back in and see the edits?

If not, then your issue is tied to the communications between AGOL and your backend so you'd need to examine what you pushed into AGOL. If yes, then can check next.

Step 3: If its allowing you to properly make live edits then all the pieces between AGOL, ArcServer and SQL DB are working correctly so the issue is specific to offline usage. Log into your REST services page and navigate to the Feature Service you are trying to use. At the bottom select the "Replicas" option. (URL looks like this: http://<servername>/arcgis/rest/services/<folder>/<service as FeatureServer>/replicas) Confirm that there are replicas being generated (these are the geodatabases stored on the server that match the SQLite DB's loaded to the users device at time of download or last sync)

If this page is blank then there is something wrong with your server configs that isn't actually building the ArcServer pieces necessary to match what the user is taking offline. If there are replicas here you can follow the directions on this site to confirm the edits that were being made in offline mode on the device actually made it back to these replicas. http://desktop.arcgis.com/en/arcmap/10.3/tools/conversion-toolbox/copy-runtime-geodatabase-to-file-g... If they did then it's time to call ESRI or perhaps someone else can assist because if the edits made it that far and simply didn't post back to your SQL DB aside from the Sync service we already checked above I can't say what the issue is.

Not knowing your backend configuration I can tell you 1 thing we saw (granted this was 2.5+ years ago) that might fit this. We used the Web Adaptor on an IIS web server VM in our DMZ with our Arc Server on a separate VM server behind the internal firewall. I put 6 testers in a room after they had collected 20 records each with between 1 & 5 pictures per record. I had them all hit sync at the same time. The primary bottleneck was by far the Web Server RAM. We had 2 of the 6 testers fail to sync but all they saw was a message that said something like "failed to sync" on the device and there was no good logs or anything else to determine the issue. Re-conducted the test while watching all servers performance in the environment and was able to identify the RAM spikes. Increased the RAM and re-tested and all users had successful syncs.

[ZacharyHart]

Ok, now we're getting somewhere:

1. Service is started just fine.
2. Much to my surprise, when I edit in AGOL, the edits are not transacted to the backend DB (nor can I see the changes in the mobile app for whatever that's worth). This makes no sense to me since its not a hosted feature layer, but a legit feature service on our GIS server. Furthermore, we have other feature services where the edits do take place.
3. I did check via the REST interface and replicas are indeed being created for what that's worth. But its a little odd that the first replica doesn't have that numerical suffice...

[ScottFierro2]

Interesting so thought I had an idea until you said you have others that are working just fine. Want to be sure that means you have other Feature Services on the exact same ArcServer which you are actively able to edit in AGOL?

If the above is true then as much as I hate to say it I'd consider replicating things through as copies from the ground up. By this I mean I'd go back to the DB make a new version of the tables configured for archiving/versioning, etc. build a new MXD, feature template, publish a new service with different name. Eliminate chances for some minor thing that got missed somewhere that's causing this behavior.

If the above is false then the possibility for network or system configuration issues is still possible.

One last item to consider, launch your AGOL edit session into Chrome, hit F12 and choose the Network tab, make your edit(s) and then save the edits and watch for any message that are not 200 status. That will help to begin troubleshooting if there is some networking/system config issues.

[ZacharyHart]

Just verified, editing other FS works just fine...sigh...I was worried that some extraordinary sanitation was going to be the only fix. On top of that, I can't get the copy runtime gdb to fGDB to work (I've read everything I can), so all the field data is lost I guess.

Thanks for your help looking into this, I'll keep you posted.

Doesn't bode well for enterprise deployment though...

[ScottFierro2]

I'd reach out to ESRI to not lose valid user collected data. If it's in the runtime gdb it's most likely recoverable and they should be able to assist with the running of that tool. As far as what went askew on this single data set(s) it is hard to say since it sounds like other things are working so then odds of it being a networking or system configs issue is minimal. It does point to some minor piece that is off and may still be able to correct but across 4 pieces of a 5 piece architecture (DB, ArcServer, Web Server, AGOL, Collector App) there are enough possibilities its throwing darts to try and hit. So walking back through from the DB and moving up the architecture piece by piece will be the only way to pinpoint.

As for Enterprise its about as Enterprise as anything else from ESRI. It covers and does a lot but probably not all things that many of us want it to do. We architect work arounds and back doors to what ESRI is doing constantly to meet bigger complexities we have or want. I can say we use Collector across 6 data sets to date with another 10-15 on the calendar thus far across 500+ users spread across the state using 400 iPads and its meeting and exceeding most needs from users/business units. That said certainly room to grow and we will keep pushing and punishing it as much as we can.

[ScottFierro2]

So something else I forgot about that we did see not to long ago and have identified as an issue. How do you manage/control user ability to update the device OS as well as the Collector App?

I can't say that we have seen an issue yet with iOS updated but we have with the Collector App. Since you mentioned some services and devices were working the issue may be specific to a particular user/device. If that is the case the lesson we learned is that if the user has "offline maps" on the device, performs an update of the Collector App, then later tries to sync the data back it will not work. The reason is that during the application update something occurs with the SQLite DB on the device. From error logs and various tests we have tried it comes through as if the replicaID on the device no longer matches what's on the server. Since no match is made the device can't use the replica to sync edits back to the enterprise DB.

[am7196]

When the issue was device-specific, was there anything you could do to save the points that wouldn't synchronize?

[AdamCommeford]

Hi Scott.

Any ideas why none of the data is making it through to the GDB? There is no error during syncing from offline, and for some strange reason, only the deletes will be passed through. no new points or attribute updates get pushed from offline. Any help would be greatly appreciated.

[ScottFierro2]

a.commeford Sounds as though your Feature Service isn't properly configured. If the deletes are working/going through but updates/new features are not check your service to be sure those capabilities have been properly enabled. In the screenshot below have circled the items you need to be sure are checked. Sounds like all your service has checked to be available is "Query" and "Delete". Here is an example: