Sharing ArcGIS Pro Python Script as Web Tool gives Analyze error 00068 Script ... contains broken project data source

Question

I am using this test script as the source for a Python Script Tool that works in ArcGIS Pro 3.0.2 and that I wish to share as a Web Tool to ArcGIS Enterprise 11.

import arcpy

arcpy.env.overwriteOutput = True

csvFile = arcpy.GetParameterAsText(0)
test_data_name = arcpy.GetParameterAsText(1)

gdb = r"C:\Users\my_username\AppData\Roaming\Esri\ArcGISPro\Favorites\my_sde.sde"
csv_table_name = "{0}_CSV".format(test_data_name)
csv_table = r"{0}\{1}".format(gdb,csv_table_name)
srGDA2020 = arcpy.SpatialReference("GDA2020")
pointFC =  r"{0}\{1}_Points".format(gdb,test_data_name)

arcpy.conversion.TableToTable(csvFile,gdb,csv_table_name)
arcpy.management.XYTableToPoint(csv_table,pointFC,"Longitude","Latitude",None,srGDA2020)

The two parameters on my tool named Test Tool are configured like this:

If I comment out the last line of my Python script (the one that uses XYTableToPoint) then the tool can be run in ArcGIS Pro, shared as a web tool and run successfully on the portal to upload a CSV file and create a copy of it as an Enterprise Geodatabase table.

However, if I leave the XYTableToPoint line uncommented, then trying to Analyze for sharing is blocked by an error:

00068 Script Test Tool contains broken project data source {0}{1}:

---

---

---

The error is described at 00068: Result contains broken project data source: .

Why is the web tool, and the Analyze that shares it, able to successfully write a table to the workspace, and then not be able to create a feature class from it in the same workspace?

Answer 1

The analyzer is getting tripped up on finding your data, as you know. The best thing you can do when writing a script to be published as a GP Service is to be explicit, meaning write out full paths to your data. If you can't write out a full path, then make use of proper path construction techniques like os.path.join. There are probably a dozen ways to construct paths to data in Python and they all work, but when it comes to publishing a GP Service, the data needs to be identified and found for publishing to work correctly. Generally, taking a "nice, portable tool" that you'd share with others doesn't usually follow code patterns that lend themselves to making a service.

I'd re-write your code like:

csvFile = arcpy.GetParameterAsText(0)
test_data_name = arcpy.GetParameterAsText(1)

gdb = r"C:\Users\my_username\AppData\Roaming\Esri\ArcGISPro\Favorites\my_sde.sde"
csv_table_name = "{0}_CSV".format(test_data_name)
srGDA2020 = arcpy.SpatialReference("GDA2020")
pointFC =  os.path.join(gdb, test_data_name)

t2t = arcpy.conversion.TableToTable(csvFile, arcpy.env.scratchGDB, csv_table_name)
arcpy.management.XYTableToPoint(t2t, pointFC,"Longitude","Latitude",None,srGDA2020)

You'll note 2 things where I used os.path.join -- first, the output of TableToTable will be written to the scratchGDB, and NOT your eGDB. I'm making assumptions this is temporary data and you don't actually need to save it in your eGDB. Second, I'm writing the final output of your script (XYTablePoint) to the eGDB.

Writing outputs from a GP Service to your eGDB must be done intelligently. For example, in your code, what happens if two people run the tool at the same time, providing the same name? Or even if they don't run it at the same time, but use the same output name. Best case, it successfully overwrites, worst case, they collide and neither user understands why the GP task failed. Personally, I always challenge why someone needs their GP Service to write back into an eGDB. There are valid business cases, and the task can be handled in a few different ways. Without a good reason, always write outputs to arcpy.env.scratchGDB or arcpy.env.scratchFolder: it's quicker and safer.