0

I have written a script to create a smoke plume from user inputs (it draws a giant triangle) and then update a number of structure features that are touched by the smoke plume. It works in ArcMap, but when I import it into a Portal App it fails without much explanation.

Now the code succeeds in drawing the plume, but fails in performing the highlights. After running the tool in my app I get a simple message: Submitted. Executing... Failed.

I originally wrote it with Update Cursors, but it sometimes complained about the editing session, so I did away with cursors and pivoted to what's below:

for fc in fcList:

    building_fs = Bldgroot + fc
    try:
        arcpy.CalculateField_management(in_table=building_fs, field="Plume_Status", expression='"NA"', expression_type="VB", code_block="")        
        #arcpy.AddMessage("SUCCESS: Cleared Plume_Status from {}".format(fc))
    except:
        arcpy.AddMessage("...Failed clearing Plume_Status from {}".format(fc))

    # # Select buildings in plume and update in_plume field
    buildings = building_fs
    arcpy.MakeFeatureLayer_management(buildings, 'building_lyr')
    arcpy.SelectLayerByLocation_management('building_lyr', 'INTERSECT', plume_feature_class, '', 'NEW_SELECTION')
    
    try:
        arcpy.CalculateField_management(in_table='building_lyr', field="Plume_Status", expression='"PNC"', expression_type="VB", code_block="")  
        #arcpy.AddMessage("SUCCESS selecting {} in plume".format(building_fs))
    except:
        arcpy.AddMessage("... Failed selecting {} in plume".format(building_fs))

To make things more difficult, I have limited access to the server and database that it's running on and I have to go through IT in order to get a more in-depth error report from Portal. The errors change from time to time, but here is one:

"D:*\PlumeV2.py", line 115, in arcpy.MakeFeatureLayer_management(buildings, g_ESRI_variable_6)File "d:*\management.py", line 6986, in MakeFeatureLayerraise e ExecuteError: Failed to execute. Parameters are not valid. ERROR 000732: Input Features: Dataset c:***\Connection to gimmsdbd.sde\sde_arcgis.DBO.Structures\sde_arcgis.DBO.Buildings does not exist or is not supported Failed to execute (MakeFeatureLayer). Failed to execute (PlumeV2). Failed to execute (Plume Version 2).

It seems to be having trouble making a feature layer - I wonder if this is because the tool doesn't have the permissions to create a temporary feature in the SDE it's working out of.

I should also mention that when I was running this same loop with cursors with a single feature it worked, and that version is currently what is serving our needs. I find it weird that it would fail on a loop, but maybe that's a bug in GP Services?

An additional note - the first part of the script runs perfectly but it runs on features in a different feature dataset than the second part - during the second part it has trouble finding the correct features. Do I need to specify the FD as the workspace when I switch from working in one to the other? But even that wouldn't make sense, because it's failing at making a feature layer - before it accesses anything else inside that other feature dataset. Is there anything that has to be specified for workspaces when creating feature layers on a portal app? It didn't need it from me last time.

Update: I've since re-written the tool in a python toolbox, and it has the same problem. Again, the PYT works off Portal just fine, but once put on Portal it has this issue. This isn't just me having this issue; see here: https://community.esri.com/t5/geoprocessing-questions/custom-geoprocessing-tool-can-t-access-feature-layer-after/td-p/188366

5
  • Maybe a compatibility issue? Sometimes ArcGIS Desktop and Pro need you to save tools/projects specifically for one version or another. For example, you can't publish a service from Desktop and then push updates from Pro. Jun 22, 2021 at 17:23
  • That's a good idea, but I thought I already checked for that. I have to go through IT for publishing, and trust that they did it correctly - I thought they couldn't publish unless they got it running on their end. Security is a bit of a bear here, and thanks to that IT is all up in our business. But, as I understand it, once they get a tool to run they can publish it - and getting it to run on Pro or Map with the correct data links implies that isn't the issue - unless there's something else I'm missing.
    – Smasher
    Jun 22, 2021 at 20:28
  • Looking at the error it suggests it can't make the connection to your Buildings layer. Double check the connection? Jun 22, 2021 at 20:31
  • The exact same code works until we put it on Portal; only when put on Portal does it fail to find the served layer. All of our local runs find the buildings feature and make a layer without problem.
    – Smasher
    Jun 22, 2021 at 20:45
  • The only difference between this tool and the one before it that worked is that the old tool only updated fields in one feature layer, and that layer was in the same feature dataset as the plume polygon feature layer.
    – Smasher
    Jun 23, 2021 at 16:11

1 Answer 1

2

Based on this part of the error message:

Input Features: Dataset c:***\Connection to gimmsdbd.sde\sde_arcgis.DBO.Structures\sde_arcgis.DBO.Buildings does not exist or is not supported Failed to execute

My guess is the publishing process did not copy the .SDE file properly. It appears you may have hidden the path with *** -- however, if that path is NOT c:\arcgiserver\arcgisinput\toolname\p20\ (or something similar to that), then the service is looking for the .SDE file in the wrong spot, and thus the message about does not exist. If this is the case, go back and check you data store entries and what you have registered: have you registered the enterprise geodatabase with the server? Did you also register the folder the tool lives in? If you've registered the folder, but have not copied all the contents to the server folder, like the .sde file? the publishing process may not copy it, expecting it'll be there, when it is not.

If the above doesn't check out, your only real troubleshooting at this point is to get on the server and check:

  1. The directory the service is deployed too, making sure all the pieces, especially the .SDE file exist
  2. Check the script and ensure the pieces are pointing at the correct locations. You'll most likely see a g_esri_var which points to arcpy.env.PackageWorkspace that builds up a path to the .sde file. Make sure this is correct.
3
  • No, I truncated the filepaths shown here per requests, but the path seems legit because part of the tool runs correctly as mentioned above (I don't show code for that part); otherwise the entire tool would fail to run. It's only when the for-loop starts that it runs into trouble. I think it has something to do with the loop or the data being in a different feature dataset.
    – Smasher
    Jun 24, 2021 at 14:06
  • You're going to need to get on the server and see what your published tool looks like. building_fs points at the same thing buildings does. And if the _fs one works for CalcField, then the server can access the data. So that leaves the question on what happened to the buildings in MakeFeatureLayer? I suspect the publishing has messed up the reference, which again, can only be validated by going and looking at the code in your PYT on the server.
    – KHibma
    Jun 24, 2021 at 14:46
  • I'll submit that to my IT people and see if they can figure out what you're getting at. For security reasons I don't have access to the server. It makes life a bit painful at times.
    – Smasher
    Jul 1, 2021 at 15:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.