1

I've developed a geoprocessing service that accepts a personal geodatabase as an attachment. After this MDB is copied to the server, I'd like to use ArcPy to open it, edit some feature classes, then append the data to an existing SDE dataset.

Given that ArcGIS Server GP Services are running 64 bit python, I tried using a subprocess to call 32 bit python:

try:
     arcpy.AddMessage(subprocess.check_output(["C:\Python27\ArcGIS10.3\python", \
                      "D:\Data\GISData\Scripts\CheckFCExists.py", newSourceData]))

except subprocess.CalledProcessError, e:
    arcpy.AddMessage('It failed!')
    arcpy.AddMessage("Subprocess output: {0}".format(e.output))

When running as a script tool in ArcGIS Desktop, the subprocess completes successfully with the STDOUT printed via arcpy.AddMessage.

When published as a GP service, it fails. The code enters the except block, prints 'it fails!' and then "Subprocess output", indicating that e.output is empty.

  • 1
    Without testing, I'd guess that yes it would be possible IF you have a 32bit Arc* application installed on the same machine. Say Desktop or Engine. And of course that application would need to be fully licensed. – KHibma Dec 16 '15 at 16:27
  • Yep, I have properly licensed Desktop installed on the server. I can call the 32 bit subprocess successfully when I run the script in Desktop as a tool, but it fails when its packaged up and called as a GP Service. Seems strange that the server environment prevents me from calling the 32 bit version of python. – Charlie Hofmann Dec 16 '15 at 16:33
  • 1
    Mmm, check stackoverflow.com/questions/7575284/… ? – KHibma Dec 16 '15 at 16:38
  • 1
    I just tested this. In desktop it pops up a command window on the call. This isn't going to work in Server. Server is "headless", running on another user account. It can't pop open that window. The only way that it may work is if you can find a way to execute the 32bit python without it having to open the window. – KHibma Dec 16 '15 at 17:39
  • 1
    I just tried that one as well with no luck. The GP task returns successful, but I can tell it never spawned the python process. I'm now doubting the ability to have GPService call another executable as its in a different process. I'll try to find more concrete info one way or another and post back if I find it. – KHibma Dec 16 '15 at 18:25
1

Based on some research, heres a half answer on the problem with some general thoughts.

  • I'm almost positive you need to make a Python call that doesn't open a new window. As indicated in my previous comments, I'm pretty sure a new window opening on an account that isn't actively logged in will not work. The following code seems to launch the other python process without opening a new active window:

    command2 = ["c:/python27/arcgis10.3/python.exe", 'C:/gpServices/CallSubProcess/calledCode.py']

    start = subprocess.STARTUPINFO()

    start.wShowWindow = 0

    start.dwFlags |= subprocess.STARTF_USESHOWWINDOW

    callReturn = subprocess.Popen(command2, startupinfo=start).wait()

  • In a plain install, the GP Service will raise a security error in the windows event logs when it tries to call the 32bit Python. By default, the user account created for ArcGIS Server is assigned only the permissions it absolutely requires to run, nothing more. So it makes sense that Server can't access executable/files outside its installation directory.

  • Elevating the ArcGIS Server user account from a basic "user" to "administrator" and re-starting Server gets passed the security error, but still fails in the service.
    • Interestingly enough, I could open a command window as the Server user and run Python. So the account seems to have at least basic permissions...
  • It seems most likely a security setting on the machine itself, but I dont see anything in the event viewer. I'm not an expert in user permissions, but to me, this is probably the area to investigate as the block.
  • 1
    Wow-- thanks so much for continuing to look into this. I ultimately ended up going the file geodatabase route-- I copy all tables and FCs to a FGDB locally, then push this up to the server and work with it from there. Good to know there might be a way around it though if necessary. Thank again! – Charlie Hofmann Dec 29 '15 at 13:43

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.