publishing a geoprocessing service that references in_memory data to AGS 10.1 fails

[TomTyndall]

Hoping to repeat the lightening fast resolution to an earlier question I posted, I'd like to ask for help with this follow on to my original issue. The solution to my first post involved using an in_memory workspace to build feature classes. My current issue is that I need to publish that geo proc to ArcGIS Server 10.1, but the publish fails with a consolidating data failure error.

The following code focuses the core issue:

import arcpy         if __name__ == '__main__':     fc = arcpy.CreateFeatureclass_management("in_memory", "fc1", "POINT", "", "DISABLED", "DISABLED", "", "", "0", "0", "0")     arcpy.Delete_management(fc)

If you create a script tool around this code, run it and try and publish the result to AGS you are alerted that the in_memory workspace has been identified as needing to be copied to AGS.
[ATTACH=CONFIG]17644[/ATTACH]

Continuing with the publish fails.
[ATTACH=CONFIG]17645[/ATTACH]

I've tried adding "in_memory" as a registered folder in AGS Data Store but that doesn't work. Any ideas?

[KevinHibma · Accepted solution]

My apologies, based on my testing, this appears to be a bug in 10.1 final.
That said, it doesn't reproduce on 10.1 SP1 (which is currently undergoing final testing and will hopefully be available for release within the next 2 months).

At this time I can provide you with 2 workarounds to the issue:

1) Modify your code to something like this:

import arcpy        if __name__ == '__main__':     fc = arcpy.CreateFeatureclass_management(arcpy.env.scratchFolder, "fc1", "POINT", "", "DISABLED", "DISABLED", "", "", "0", "0", "0")     arcpy.Delete_management(fc)

This no longer puts the output to the in_memory workspace, it now puts it to disk (a folder) - but will publish successfully. This is the easiest most straight forward workaround.

2) If you want to continue to write to in_memory, you'll have to modify your script and parameters a little bit.

import arcpy        if __name__ == '__main__':     inWorkspace = arcpy.GetParameterAsText(0)     fc = arcpy.CreateFeatureclass_management(inWorkspace , "fc1", "POINT", "", "DISABLED", "DISABLED", "", "", "0", "0", "0")     arcpy.Delete_management(fc)

>> new parameter in the first position (0-indexed) of type string, with input value of "in_memory"

Then.... you run this, get your result and publish. When inside the Service Editor (publishing your service), go to that parameter (in this case, the first one), and change the Input Mode to "constant". This hardcodes it and the user of your service doesnt set it and your tool will continue to use in_memory.

I understand neither are ideal, but they'll move you forward till SP1 is available.

edit: The bug information is:  NIM084303 - When publishing a simple script that references the "in-memory" workspace, the analyzer says the "Data source used by Script is not registered with the server and will be copied to the server: in_memory."  Then the publish will fail to create a service definition.

[Anonymous User]

Original User: tyndallt_esri

I got the second scenario to work. I'm kind of forced to use an in_memory workspace because of this problem I'm also having. There is some suspicion that my problem there might be with my antivirus software and so be a local problem, yet, the same script runs on 10.0 with the same AV so I'm not sure what's going on.

One of the things I've found myself doing with the new Result deployment model is wrapping the my scripts with an if statement that is controlled by a script parameter so I can control whether the code executes when the tool is invoked.

if onServer:
    #do the stuff

I do this if the script is failing on my workstation (in this situation maybe because of my AV), I want to test it on the server to see if it fails there but I need to get a result in order to deploy.

Thanks for the work around, it gets me up and running which is the most important thing.

Tom
AzDOT