"A python error occurred"

[cashewbeep]

Tool fails with "A python error occurred. Details have been logged to C:\arcgis\ArcTutor\ArcScan\ExerciseData\PublishRoutingServices.log Traceback (most recent call last): File "", line 280, in execute File "C:\Users[user]\Desktop\network-analysis-services-2.1\ut.py", line 1037, in execute street_points = [cursor.next()[0], cursor.next()[0]] StopIteration"

Using my own network dataset generated from OSM data (covering city of Chicago) and using ArcMap 10.5.1 with ArcGIS Enterprise 10.6 with Network Analyst enabled on both ends. ArcGIS Enterprise is a Linux install using Portal federated with ArcGIS Server.

[deelesh]

@cashewbeep The version of ArcMap and ArcGIS Enterprise used for this workflow should be same. Since you are using ArcGIS Enterprise 10.6, you can use PublishRoutingServices tool that now ships with ArcGIS Enterprise 10.6 and does not need ArcMap at all.

I would suggest you try the 10.6 version of the publishing tool with your network dataset. I still have a feeling that you are going to run into the same failure. If you do, can you send me the full copy of the PublishRoutingServices.log file and if possible, the network dataset you are using?

[cashewbeep]

Wow, I'm having all sorts of headaches with this. So, with -o it keeps on trying to read the service definition folder as the network dataset and therefore not run, and then when I omit it, it still insists that the dataset does not exist. This also really needs a headless option btw, I don't have X11 forwarding set up on this server so I have no idea if there are popups I should be seeing :)

[deelesh]

The tool does work in a complete headless mode on linux and werites all messages either to standard output and/or to the log file. The service definition folder (specified as -o) cannot be in the folder that also contains your network dataset (specified as -n).

I do not run into any issues running this tool on ArcGIS Enterprise 10.6 on linux. I am logged into my linux box in a headless mode. So I would need the exact steps to reproduce this issue you are facing (and preferably the log file if one is created.)

[cashewbeep]

Here's where I'm at,

Is there anyway I can just generate a service definition, then publish it straight to manager...?

[deelesh]

Is there anyway I can just generate a service definition, then publish it straight to manager...?

No. As the tool is not including the data in the service definitions, it needs to create the appropriate data store entry in ArcGIS Server. So it needs to connect to the server. Also after the services are published from the service defintions, the tool configures the services as utility services in the portal. So it needs to connect to the portal that the server is federated with.

The error in the above screenshot is a bug in the exception handler. If this bug was fixed, you would see a message

Failed to connect to the portal at {portalURL}. Check if Portal for ArcGIS is running.

So we need to figure out why is the tool unable to get a portal token? When calling the tool, what value did you specify for the -P option? Did you provide the fully qualified domain name for the portal machine, like machine.domain.com? or you specified the URL for the portal machine? If latter, the URL needs to be the private URL to the portal such as https://machine.domain.com:7443/arcgis and this URL should be reachable from the server machine.

[cashewbeep]

The only ports that are open for each server are those explicitly laid out in the installation steps (as our environment is pretty locked down). I've run into this before [token issues], and it's sometimes hard for me to remember how best to diagnose it...

-P is set to 'https://[domain]/portal(the web app)

Under /rest/info on the GIS Server it says:

SOAP URL: [machine name]:6443/arcgis/services

https://[domain name,not machine name]/portal/sharing/rest/generateToken

[cashewbeep]

Ok, checking the log it does indeed say that it's trying that... It says, (as the last step before running into an error) "Getting a portal token from https://[domain name]/ portal/sharing/rest/generateToken

[deelesh]

If -P is a URL, then it should be https://machinename:7443/arcgis. It cannot be https://domainname/portal. Can you just specify the fully qualified machine name for -P ? In that case, the tool will actually use https://machinename:7443/arcgis as the portal URL. This should be working as port 7443 has to be open between federated server and portal for things to work in general.

[cashewbeep]

Good news: That got me past the ERR_PORTAL issue

Bad news: Gave me this, Saving travel modes to Z:\home\arcgisuser\data\routing-services\prs2\data\DefaultTravelModes.json Saving tool info to Z:\home\arcgisuser\data\routing-services\prs2\data\ToolInfo.json Creating map document used to publish network analysis map service at Z:\home\arcgisuser\data\routing-services\NetworkAnalysis.mxd X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 149 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 179 Current serial number in output stream: 183

[deelesh]

This error is coming from calls to the underlying ArcGIS Runtime and nothing to do with access to ArcGIS Server or portal. It is hard to pin point the exact call raising this failure. It could be anywhere between lines 942 and 996 in ut.py

Can you verify if you have all the required packages for your OS as listed in http://enterprise.arcgis.com/en/system-requirements/latest/linux/arcgis-server-system-requirements.htm

If you have the required packages and still get this error, I recommend you should contact Esri Technical Support who can troubleshoot this further as this specific failure is something beyond my expertise.

[cashewbeep]

The only one listed is gettext and I have that installed. Thanks for your help though.

[cashewbeep]

Ok, so that error turned out to be linked to indirect X11 forwarding issues. Switching to Windows allowed me to bypass that and for it to continue running the script.

However... it now says this python error....

"File "Z:\home\arcgisuser\data\routing-services\prs10\ut.py", line 1060, in ex$ street_points = [cursor.next()[0], cursor.next()[0]] StopIteration"

Sure enough, that's the same issue I was running into on Desktop :)

In case you've got some time to take a look later, I'm leaving the GDB here as a download:

[deelesh]

There are a few different issues with the network dataset that I got from the above GDB. When I run the publishroutingservices utility using the Chicago_ND network dataset, the tool fails with these validation errors

The following errors were returned when analyzing the input network dataset:
The network dataset does not have at least one time based cost attribute.
The network dataset does not support generating directions.

These are all valid errors as the tool requires these capabilities on the input network dataset. I am not sure why you were not getting these errors and instead ran into the failure that you mentioned which should happen only after the network dataset has been successfully validated.

As for the failure you encountered, it is because the Chicago_ND_Junctions feature class for the network dataset is empty. This feature class is auto-managed by the network dataset and is used to store junctions (i.e. nodes) for every edge in your network dataset. I am not sure why you have a specific user defined junction feature class called "Chicago_Nodes" that essentially is functioning like the system junction source. While there is nothing wrong is having user defined junctions for every system junction, the user defined junctions should really be used for junctions that have some meaning in your network dataset. For example, you might want to model a traffic light as a user defined junction to assign delays in travel time when crossing that junction.

So to fix the error you encountered, there are few things you can do

1. Convert the user defined junctions into system defined junctions. To do this, remove the Chicago_Nodes source from your network dataset. This can be done by navigating to your network dataset using the Catalog Window in ArcMap and acceesing the sources tab on the network dataset property pages. Once you have made the changes to the network dataset, you need to rebuild the network dataset.

2. If you need to keep all the user defined junctions, create a new edge in your network dataset and rebuild the network. This will create at least two system junctions (for this new edge) and the publishroutingservices utility can use these two junctions.

3. If you can not modify the network dataset for some reason, I would have to code a fix to handle a network dataset with no system junctions.

Option 3 would be ideal but would require patching the publishroutingservices utility. Since this tool is part of core ArcGIS Software, you will need to request a patch by contacting Esri Technical Support. I will ensure this bug will get fixed with the next release of ArcGIS Enterprise (10.6.1) that is expected to be released around July 2018.

[cashewbeep]

I really appreciate you taking time to take a look at this. So, I may have uploaded the wrong dataset to you. The dataset I had been testing had directions generated for it, for example, and does have a time based cost attribute. But the 'right' dataset that I was using, did also have the Chicago_ND_Junctions, so based on this I'm hoping that will fix the issue preventing publishing.

Maybe relevant is that I initially found this data from the CSUN Urban Road Network Data page (http://csun.uic.edu/datasets.html). These datasets are made using the GISF2E tool if you've ever heard of it, using open street map data. I think, after reading this tool more carefully, that your suggestion to remove the Nodes and then rebuild the network dataset would solve some issues would probably help (as the nodes/edges shapefiles seem to be intended for programs outside of ArcMap such as R)