1

The following code in arcpy is used to convert a dwg file into shapefile and it works perfectly when you run it within ArcMap:

import sys, zipfile, arcpy, os, traceback
from arcpy import env
# Set environment settings
env.workspace = "C:/GISApplication/GIS/Layer_Updated_Drawings"

# Set local variables
fileName = arcpy.GetParameterAsText(0)
featureType = arcpy.GetParameterAsText(1)
file = os.path.join(fileName, featureType)
inFeatures = [file]
outLocation = "C:/GISApplication/GIS/Layer_Updated_Drawings/Converted"

# Execute FeatureClassToGeodatabase
arcpy.FeatureClassToShapefile_conversion(inFeatures, outLocation)

However when I try to run this script using the following JavaScript code:

url = ARCGIS_SERVER + 'Toolbox/DwgToZippedShapefile/GPServer/LayerUpdate';
convParams = {
FileName: "MIPBoundary.dwg",  //Hardcoded for testing
FeatureType: "Polyline" //Hardcoded for testing
};
convExportToolName = "SHPFileResults";
convJobFolder = "DwgToZippedShapefile_GPServer";
var gpConversionProcess = new Geoprocessor(url);
gpConversionProcess.submitJob(convParams, gpConversionComplete, gpConversionStatus, gpConversionFailed);

it keeps failing and I keep getting the following error on arcgis server manager:

Error executing tool. LayerUpdate Job ID: j7af4b50ca616491eb13dce08dfe17b7f : Traceback (most recent call last): File "(PATH)\Toolbox\DwgToZippedShapefile.GPServer\extracted\v101\my_toolboxes\UpdateLayer.py", line 25, in arcpy.FeatureClassToShapefile_conversion(inFeatures, outLocation) File "(PATH)arcgis\server\arcpy\arcpy\conversion.py", line 2775, in FeatureClassToShapefile raise e ExecuteError: Failed to execute. Parameters are not valid. ERROR 000732: Input Features: Dataset Boundary.dwg\Polyline does not exist or is not supported Failed to execute (FeatureClassToShapefile). Failed to execute (LayerUpdate). Failed to execute (LayerUpdate).

However I don't know why it isn't working as I am passing all the parameters and when running the tool in ArcMap with the exact same parameters it works fine.

  • I just use DraftSight to convert DWG to DXF, then save the DXF to .shp format. DraftSight is a free bit of software and easy enough to do the conversion job. Afraid I can't help with the coding aspect. Just thought I'd share a potential temporary workaround whilst the answer you're looking for comes around! – James B May 10 '17 at 11:18
  • Running a local script and a remote service are intrinsically different tasks. The service requires a full path which is accessible from the server, or must be written in a way that it knows where to expect the data. – Vince May 10 '17 at 12:13
  • @JamesB yeah the thing is this is for the users who feel that using an external program is too time wasting and they want everything combined within the application itself. – Maeglin77 May 10 '17 at 12:59
  • @Vince The locations should be accessible though as I am uploading files using another process to the same folder that is being used within the script itself. I will try playing around with the location though as maybe uploading is one thing and accessing using arcpy is another – Maeglin77 May 10 '17 at 13:02
  • Upload is a client-side task. – Vince May 10 '17 at 13:18
1

The problem, as Vince as inferred in the comments is the service does not know where the input data is.

So to go through the checklist:

  • works in arcmap, great
  • publishes without error, great
  • can consume the service back in arcmap, great
  • fails from JS client: indicates JS is not passing/telling the service the right details to run the service.

It looks like your input parameter is of type FILE (that is good), but JS is passing it this:

convParams = {
FileName: "MIPBoundary.dwg",  //Hardcoded for testing
FeatureType: "Polyline" //Hardcoded for testing
};

Essentially you're passing the service a string that the service has no idea what it is. The JS client needs to pass the actual DWG file onto the service. (That is why ArcMap works when consuming the service, it passes the file to the service for you). In short, you need to write more code to upload the DWG file. First you need to enable the uploads capability which is a service level setting. After that you need to write a little bit of JavaScript to upload the file. See the example in the File Upload service. (Note, this server is slated for retirement, so this link will go dead, but I'm absolutely certain I've put this upload JS code here in another GIS.SE post, I just cant find it)

Alternatively for testing, you can tell the service where the file is on a webserver and it'll go get it. Place your DWG file on a webserver somewhere and use the following at the REST end point (services directory) {'URL':'http://myserver/MIPBoundary.dwg'} (I'm not sure how you'd write this notation into your JS client)

  • Input parameters are all strings not files. I'm strings that then are used to refer to the location of the actual file on the server, that is why I assumed that the process would work as the full path would be called from the scrip to locate the required file. FileUpload would have already been carried out. The issue is reading the link to the file. Is it possible that since I'm calling MIP.Boundary.dwg/Polyline to get the polyline feature class and the file is only called MIPBoundary.dwg there is an issue? However this works as is when running the script in arcmap in order to publish it – Maeglin77 May 11 '17 at 11:00
  • I wouldnt encourage this workflow - using strings as paths to items on the server. You'll need to build a really built proof client application unless you have some users who promise to follow the rules on providing inputs to the gp service. Anyways, if you're going to do this you need to 1) provide a full path like c:/temp/data.dwg and 2) make sure the account server is running under has read access to that data. – KHibma May 11 '17 at 13:25
  • Further - dont rely/depend on the env.workspace you've set in the script to work in the gp service the way you expect it to work on the server. – KHibma May 11 '17 at 13:27
  • the inputs would be selected from dropdown lists so that there would be no room for errors. And yeah all the access rights are correct since I am using a similar process in another script that uses selected templates from within a folder on the server and this works fine. I will keep looking at the urls as I believe the issue may be with on of them changing when the script is run via the application – Maeglin77 May 12 '17 at 6:21
  • It must be failing from with the urls as when running it within the catalog window the published service fails – Maeglin77 May 12 '17 at 6:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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