Currently we have years worth of data stored in MS Access. I've created a few detailed surveys in Survey123 Connect that haven't yet gone "live"; still testing. Ultimately, we want all data to reside in SDE, with historic data migrated and new data coming in via Survey123. We have sample sites (points) where field data is collected an a regular basis.
The surveys and test data that I've been working on are currently residing in my AGOL. I started out with a new survey and have been working on the XLS forms in Connect. Next step, create new data tables in SDE and make sure the surveys are pointing to them and not my AGOL.
I have been reviewing https://community.esri.com/groups/survey123/blog/2017/09/25/working-with-existing-feature-services-i..., and it seems that that I may have gone about this process backwards, but the principles are still the same....correct? I already have my surveys built, and "test" data saved, so I figured we could just export to FGBD from AGOL and add that data to SDE. Which was nice, since that export include the relationship classes and related table (I have repeats), and everything!
But when I added this submission URL, https://gis.test.slco.org/slcogis/rest/services/VueWorks/Engineering/FeatureServer/3 to the settings worksheet and got this error when I tried to publish the survey: "The custom feature service submission url is not compatible with this survey (Request error 498 invalid token)"
Is my process faulty? The URL?
The submission_url is expecting the link to the feature service's entry in your portal, not the direct link to the feature service. This is because a relationship between the form and the service is created at the time of publishing, which is then used to determine the submission endpoint.
The image below (from Use Survey123 with existing feature services—Survey123 for ArcGIS | ArcGIS ) provides an example:
Note the link is to a location in the portal's sharing API: Item—ArcGIS REST API: Users, groups, and content | ArcGIS for Developers
It appears you copied and pasted the Item Details (a human readable web page) link. The submission_url uses the REST API content location. It's easy to translate from the Item Details to the REST endpoint:
https://<portal server>/<web adapter>/sharing/rest/content/items/<itemID>
in your case,
would refer to the item at
(if I typed the ID correctly; I usually copy/paste that part from the Item Details page).
Thank you very much for your help. The instruction how to compile the correct submission_url was the decisive hint. Meanwhile, I managed to switch my survey to an enterprise geodatabase-based feature service. Besides your help I mainly consulted this blog post from Ismael Chivite (section “If your feature service has attachments and/or relationship classes”):
But, although I finally managed to publish the geodatabase-based survey, there is still some uncertainty prevailing. I’d like to take the opportunity and ask some more questions. Your answers will help me to get a much better understanding of the entire process.
From the blog post, step #3: In ArcGIS Pro, run the Add Global IDs geoprocessing tool on all layers and tables in your File Geodatabase.
From the blog post, step #4: In ArcGIS Pro, run the Migrate Relationship Class geoprocessing tool against relationship classes (including those for attachments) in your File Geodatabase.
From the blog post, step #5: In ArcGIS Pro, run the Disable Editor Tracking geoprocessing tool against your File Geodatabase data.
From the blog post, step #6: In ArcGIS Pro, set all the Editor Tracking fields in your File Geodatabase to "Read Only" using the Design/Fields view as shown in the next animation.
From the blog post, step #8: In your portal in ArcGIS or ArcGIS Enterprise, Enable Editor Tracking (in the Setting Dialog of your feature service as shown in the next screenshot) in the Form's Feature Layer.
Due to copying the feature class and tables from the FGDB to my enterprise geodatabase (PostgreSQL) their names were composed of the original names prefixed by the name of the schema owner and geodatabase. One crucial step in the entire process was to rename the layers in my map document (to be published) to exactly match the feature class and table names of the survey. In the end, my success was a combination of your help, investigation in GeoNet and some trial and error.
And finally: I was working in an ArcGIS Enterprise 10.6/ArcGIS Pro 2.1 environment.
I hope that my questions are not disproportionate. Thanks once again.
First, I will note the article you mention is a migration guide for already existing feature services that are not compatible with Survey123's requirement that applyEditsWithGlobalIDs be true. Based on question #5, this is in the context of moving an existing Survey123-created feature service to ArcGIS Enterprise, correct? In that case, the article is not relevant- the feature class/table design is already set up to be used by Survey123.
1. If GlobalIDs are already present, then you do not need to recreate them.
2. Per Migrate Relationship Class—Data Management toolbox | ArcGIS Desktop, the geoporcessing tool only migrates ObjectID-based relationship classes to GlobalID-based ones. The primary relationship class this addresses is an attachment relationship. If this feature class was created by Survey123, it appears the option to not use GlobalID in the relationships was selected - the fields cited are created by Survey123 Connect in that situation (they should be GUID fields). No alteration is needed.
3. The purpose for disabling editor tracking is to preserve the lastEdit information. If left on, those values will be overwritten with the username of the user performing the action (and the lastEditDate if the time of the geoprocessing). Many users, in doing these migrations, wish to preserve the information as it indicates the last business transaction (as compared to this maintenance operation).
4. Editor tracking is enabled at the geodatabase for a non-hosted ArcGIS Server Service. Please refer to Editor tracking for feature services—Documentation | ArcGIS Enterprise for more information on Editor Tracking
5. It sounds like you have been doing the recommended way to copy a survey table- download the fGDB from ArcGIS Online/Enterprise, copy using the Catalog tools (if you copy a feature class with Catalog, the relationship classes will be detected and copied along) and then publish the service with the new feature classes (matching names is nice but not required, though do not include periods in the names). After that, make a copy of the survey, update submission_url to the new feature layer item, the form_id to the name of the parent table, and publish. Refer to Use Survey123 with existing feature services—Survey123 for ArcGIS | ArcGIS for more information
6. Yes, all of this applicable to 10.4+. Again, note that the article is for migrating existing feature classes on enterprise databases so that their feature services will be compatible.
I've had much success with about seven different survey123 docs, in which we use a submission URL which we would get from creating a survey from feature service (the feature service being the 'item added from web' with stored credentials that is a URL to our featureserver) https://chautauquacounty.maps.arcgis.com/sharing/rest/content/items/5047b2623ad34b60baa59890362b1f31
Everything was great, except that our users didn't like that they weren't able to edit data without downloading a map area first. So in an attempted solution, we figured if we republished the feature service, but this time not storing credentials to our server. Everything check out until I got to the last step where I have to create a dummy survey to get submission url, and I got the error code 468 invalid token, and it would not let me create a dummy survey. So I tried getting the URL off of AGOL on the feature service page's url on the right side bottom, still did not work. I continued to get the incompatibility error code. I went back and switched back to stored credentials and was able to successfully republish, only problem being we can edit data points 'live' . We are using ArcGIS Online, have SDE 10.5.1 and arcgis server 10.5.1. Web Adaptor
So my question is: Can this Survey123/collector workflow be successful without Portal for ArcGIS and without using stored credentials?
Any help is greatly appreciated,