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
