So I have built a network dataset based on Ordnance Survey Open roads that I'd like to publish as a routing service on my internal ArcGIS Enterprise 10.6 setup, it's fairly vanilla at this stage and was configured using the enterprise builder tool.
While running the Publish Routing Services (publishroutingservices.py) utility I get this error:
ERROR | 2018-04-24 10:23:17 | __main__ | nas | error | 400 | GIS Server cannot access the file geodatabase containing the network dataset at E:\arcgis\NetworkServices\OSOpenRoads/OSOpenRoadsServer.gdb
ERROR | 2018-04-24 10:23:17 | __main__ | nas | exception | 418 | A geoprocessing error occurred. Details have been logged to E:\arcgis\NetworkServices\ServiceDefinition\publishroutingservices.log
DEBUG | 2018-04-24 10:23:17 | __main__ | nas | exception | 422 | Traceback (most recent call last):
File "C:\Program Files\ArcGIS\Server\tools\PublishRoutingServices\publishroutingservices.py", line 222, in publish_routing_services
prs.execute()
File "E:\arcgis\NetworkServices\ServiceDefinition\prs\ut.py", line 873, in execute
raise arcpy.ExecuteError
ExecuteError
It's clear that the file geodatabase the script is looking for (above) does not match the file geodatabase location I specified for the tool's parameters (below as -n) (explained on the ESRI website here). Though I am not sure if this is the actual problem or a "red herring". But if it is the actual error it suggests the ESRI utility is changing the URL at some point in the script?
Regarding Windows file access and permissions the script is run as an administrator and I have given the folder "E:\arcgis\" and all sub folders read/write access for the ESRI system account I created for ArcGIS enterprise to use.
C:\Python27\ArcGISx6410.6\python.exe "C:\Program Files\ArcGIS\Server\tools\PublishRoutingServices\publishroutingservices.py" -s https://domain.com:6443/arcgis -P https://domain.com:7443/arcgis -u username -p password -o E:\arcgis\NetworkServices\ServiceDefinition -n E:\arcgis\NetworkServices\OSOpenRoads\Data\OSOpenRoadsServer.gdb\OSOpenRoadsNetwork_ND
EDIT 1 - For anyone who was interested the error occurred because I had missed the "feature dataset" from the -n parameter since it goes File GeoDatabase - Feature Dataset - Network Dataset. However, I'm now encountering another error with my new parameters:
Command Line input
C:\Python27\ArcGISx6410.6\python.exe "C:\Program Files\ArcGIS\Server\tools\PublishRoutingServices\publishroutingservices.py" -s gisdomain.com -P gisdomain.com -u username -p ***** -o E:\RoutingServices\ServiceDefinitions -n E:\RoutingServicesData\OSOpenRoadsServer.gdb\OSOpenRoadsNetwork\OSOpenRoadsNetwork_ND
Debug Output
INFO | 2018-04-25 09:08:58 | __main__ | nas | info | 391 | Creating supporting files at E:\RoutingServices\ServiceDefinitions\prs\data
ERROR | 2018-04-25 09:08:58 | __main__ | nas | exception | 418 | Failed to create supporting files in E:\RoutingServices\ServiceDefinitions\prs\data
DEBUG | 2018-04-25 09:08:58 | __main__ | nas | exception | 422 | Traceback (most recent call last):
File "E:\RoutingServices\ServiceDefinitions\prs\ut.py", line 932, in execute
create_supporting_files.execute()
File "E:\RoutingServices\ServiceDefinitions\prs\ut.py", line 265, in execute
parser.set(network, prop, network_props[prop])
File "C:\Python27\ArcGISx6410.6\lib\ConfigParser.py", line 743, in set
raise TypeError("option values must be strings")
TypeError: option values must be strings
ERROR | 2018-04-25 09:08:58 | __main__ | nas | exception | 418 | A geoprocessing error occurred. Details have been logged to E:\RoutingServices\ServiceDefinitions\publishroutingservices.log
I am currently unable to solve this error and have an ESRI support case open. Any thoughts/guidance is appreciated. I will of course share any solutions as and when I get them.
EDIT 2 - In case anyone else has encountered this error, I raised it with ESRI UK support. They investigated with my network dataset and configuration, confirmed my network dataset and system met the requirements for the utility and that it was a bug/issue with the script that they had identified and planned a fix for. I was told it will be fixed with the release of ArcGIS Server 10.6.1, which is due at some point soon, touted for "summer 2018". In the meantime my case was closed as nothing else could be done aside from waiting for the fix.
Thanks
Ryan
is ***** a number?
No it's a mixture of characters, I've just put stars there to redact it.
ok... It is the error 'option values must be strings' which suggested a number was present somewhere
In case anyone else has encountered this error, I raised it with ESRI UK support. They investigated with my network dataset and configuration, confirmed my network dataset and system met the requirements for the utility and that it was a bug/issue with the script that they had identified and planned a fix for. I was told it will be fixed with the release of ArcGIS Server 10.6.1, which is due at some point soon, touted for "summer 2018".
Hi Ryan,
I'm having a very similar issue and just came across your thread. Did you get any further with this?
Francis.
Hi Francis,
Unfortunately nothing yet. I am still awaiting the patch from ESRI, I checked my server again today and still no updates are available for it.
I'd suggest your best bet, if you are an ESRI customer on support, is to contact your ESRI contract manager and make it clear you would like a fix for it. The more we ask, the better the case for a fix being prioritised is.
Thanks
Ryan
Thanks for the reply Ryan. Yes we're also speaking with ESRI UK about the issue so will hopefully get some progress soon.
Regards.
Ryan, I've been in contact with ESRI UK and they have mentioned the utility works for them with ITN data at 10.6.1, are you already on 10.6.1 and if so have you retried the utility? Appreciated you are not using ITN..
Hi Francis,
Thanks for the information. I was unaware that 10.6.1 would not be delivered through the automatic update system, so that explains why I didn't notice it. I have downloaded 10.6.1 ISO for our ArcGIS Enterprise and will be applying it in late September. I'll report back if 10.6.1 fixes the issue, I hope it will.
Ryan