Cannot use batch geocoding in AGOL with an Enterprise 10.9 GeocodeServer

[Jay_Gregory]

We have an AGOL / Enterprise hybrid environment to support a variety of use cases, and our users are generally using ArcGIS Online while they behind our firewall, so they can access services published to ArcGIS Enterprise.  

I have tried to register an Enterprise GeocoderServer with our AGOL instance (Setting-->Utility Services-->Geocoding).  I am able to add my Enterprise GeocoderServer URL, which enables "geosearch" in the map viewer (and I've tested this and it works as long as I am behind our firewall). 

However, "Allow Batch Geocoding" is greyed out to off, and I'm unable to change it.  

I've checked the network tab and see two failures:

1. 400 error on https://myagolorg.maps.arcgis.com/sharing/proxy?https://myenterpriseorg/arcgis/rest/services/locator...

2.  Preflight error on https://myenterpriseorg/arcgis/rest/services/locators/APTLocator/GeocodeServer?f=json

Does anyone know what's happening here, and if there is some security setting (either in Enterprise or AGOL) that I'm missing, or if this just isn't supported?

Thank you!

[Scott_Tansley]

In some situations (security/CORs) an enterprise portal or AGOL portal will proxy requests to the ArcGIS server.

9 times out of 10 you will ask for something in a browser and a message will go from your browser to AGOL or AGS.  The other time the message goes to AGOL and then to ags.  Needs must.

the first url you shared says it’s trying to use the proxy.  AGOL cannot communicate with AGS because it’s behind your firewall. 

[Jay_Gregory]

Thank you - this was my suspicion - but why they decided to use the proxy to query the GeocodeServer information is beyond me.  Unfortunately,  it does prevent this pattern - and since we're unable to publish custom geocoders into ArcGIS Online, this functionality in inaccessible to our AGOL users (upload a CSV of asset IDs and use a custom geocoder to turn them to a hosted feature service for example).  I'm curious if this is done by design for some reason, or is an oversight from the product team.  

Maybe the proxy is implemented because of the size of the potential payload in a batch geocoding request?  If it exceeds the standard size then a proxy must be used.  This is where my technical knowledge can't keep up. 🙂

[Scott_Tansley · Accepted solution]

Sorry yes.  A get request has a limit of ~2000 chars.  That includes the url to the endpoint and the query parameters.  As soon as that is exceeded then ‘the internet’ states you have to post and that’s another reason for using the proxy.  So, too many characters will force the proxy to come in.

using the proxy is always ‘last resort’ if it’s being used, then it needs to be used.  😞 

[Jay_Gregory]

But the GeocodeServer supports POST which is another way to get around those limits in a batch geocoding scenario.  I'm now just wondering if this is an unnecessary limitation, and I can try to convince the product team to change things to support this - either allow creation of customer geocode services or stop using the proxy and just use POST for batch geocoding from AGOL to enterprise. 

[Scott_Tansley]

The service will support a post.  off the top of my head a post will cause the CORS issue so the remedy to that is a server to seever request. Not a client to server request.  To avoid CORS we use the proxy.

on that note we may be able to force it.  If you go to AGOL -> organisation -> settings then you should be able to add your server as a ‘trusted server’ - that may be enough to force it direct. 

[Jay_Gregory]

Interesting - that's a good suggestion.  If I add my server URL to Allow origins, it fixes the Preflight request but the first request still uses the proxy (and still fails).  Adding the URL to Trusted servers seems to have no effect in this scenario.  So ultimately still doesn't work, but at least I have enough information to take it to the product team and plead my case.