Use feature class with a GP service

2063
5
Jump to solution
02-10-2013 11:53 PM
by Anonymous User
Not applicable
Original User: tereshenkov

A model I built with ModelBuilder works as expected in Desktop yet generates numerous error messages when published as a geoprocessing (GP) service in ArcGIS Server 10.1 SP1. I've decided to start simple then and am trying to get just a single tool to work.

Here is my model. It has one parameter, a table or a feature class to truncate. When running in ArcGIS Desktop 10.1 SP1, user can specify what object should be truncated. When publishing as a model after getting a successful result, I use default settings for all settings (and Info for Message Level).

[ATTACH=CONFIG]21666[/ATTACH]

When running the GP service task in the same ArcGIS Desktop, I get this window in order to supply an object for truncating.

[ATTACH=CONFIG]21667[/ATTACH]

After pointing to a dataset (stored in a 10.1 file geodatabase on a local disk drive), the GP task gets running. The task does not truncate table and produces an error: 000187 : Only supports Geodatabase tables and feature classes.

My guess is that it has something to do with the Input mode of the task (User defined value) which makes it impossible to supply to my task a feature class from a file geodatabase in the file system. It seems as model uses the empty FeatureSet object instead of a feature class I supply when running the GP service task.

Is there a way to make the Truncate Table GP tool to use another feature class (not the same used when running the model first in Desktop before publishing) when published as a GP service?


EDIT: the model for truncating a table works fine when there are no parameters exposed and when running the GP task of a published service, it runs over the same feature class I've used when running the model first to generate a result. So, the GP service does work with feature classes yet only with the same one used when running the model before publishing.

Question: is it possible to supply a feature class to a GP task that differs from the feature class used to run the model and generate the result? NB: the feature class is not copied to the arcgisserver folder, it is being processed properly right in the geodatabase on the disk, so this part works properly.
0 Kudos
1 Solution

Accepted Solutions
KevinHibma-old
Regular Contributor III
Ok, I dont think I have a full understanding of your workflow.

Are you trying to create a service which the user will send data and have the rows removed? Or will be they using a service where the SERVER has the data, and they're simply tell the Server what FeatureClass to act against?

If its the first scenario (they send it) - then go with what I described in using copy features as the first part of the tool. However the service always creates new data and sends it back. It'd be on the consumer of the service to merge or figure out how to work with the new output data.

If its the 2nd scenario where the user of the service is basically trying to remotely administer a geodatabase and the featureclasses inside: you'll have to create a sort of look up and pass just simple names to the service. In this scenario I assume you'll be working against 1 to any number of featureclasses. Here you have 2 ways to do this:
1) Accept a NAME from the user, the service then uses the name to mash up paths, find the featureclass in a geodatabase, and perform the operation. (You can do this in a model, but a script might be easier)
2) Drag all the layers that a user may want to act upon into your MXD. Run your model against a layer. Publish. Inside the Service Editor, change the parameter to choice list. Finish publishing. When the user consumes the service they pick 1 or more layers from the parameter control.

Both of these methods would require registering the database as a datastore (which it sounds like you've already done)

Hopefully my guess at one of your scenario's is correct. If not, please explain what it is you want your users to do against what data.

View solution in original post

0 Kudos
5 Replies
KevinHibma-old
Regular Contributor III
FeatureClass is not a supported input type for GP Services - thus why you're seeing the parameter mapping to User Defined happen.
You have 3 options with FeatureClass - User Defined, which is a Feature Set, choice list (which is 1 or more feature layers to chose from) or constant (hardcoded - the featureclass is on the server, but cannot be modified as a parameter choice).

Using Feature Set you can pass features through (via the layer choice in the drop down) - if this doesnt work in your Service (based on the error you reference) then it might not like how its getting the features (they'll be coming in via in_memory).
Sooooo... if you did Copy Features first and persisted the output of copy features to disk, then pass that into your tool - it should serve your workflow.

EDIT:
Yeah, I just tested this and it works. The only thing I should have been clear on : the output of copy features has to be to a file geodatabase. You cant write to shapefile as the Truncate tool doesn't like that type either.
0 Kudos
by Anonymous User
Not applicable
Original User: tereshenkov

Thank you, Kevin.

So, your suggestion is: publish a model with the Copy Features tool > Truncate Table? The problem would be that I need to get rid of all the rows of the existing feature class yet Copy Features will create a new output in a geodatabase, right? And the Truncate Table tool will work on the newly created feature class, not the existing one.

Do you think there is a chance I could replace all the rows in the feature class I need with the rows I get written to the geodatabase with the model then (seems as I need again to make a feature class a parameter which is not currently supported)? Or maybe I just didn't get you right.
0 Kudos
KevinHibma-old
Regular Contributor III
Ok, I dont think I have a full understanding of your workflow.

Are you trying to create a service which the user will send data and have the rows removed? Or will be they using a service where the SERVER has the data, and they're simply tell the Server what FeatureClass to act against?

If its the first scenario (they send it) - then go with what I described in using copy features as the first part of the tool. However the service always creates new data and sends it back. It'd be on the consumer of the service to merge or figure out how to work with the new output data.

If its the 2nd scenario where the user of the service is basically trying to remotely administer a geodatabase and the featureclasses inside: you'll have to create a sort of look up and pass just simple names to the service. In this scenario I assume you'll be working against 1 to any number of featureclasses. Here you have 2 ways to do this:
1) Accept a NAME from the user, the service then uses the name to mash up paths, find the featureclass in a geodatabase, and perform the operation. (You can do this in a model, but a script might be easier)
2) Drag all the layers that a user may want to act upon into your MXD. Run your model against a layer. Publish. Inside the Service Editor, change the parameter to choice list. Finish publishing. When the user consumes the service they pick 1 or more layers from the parameter control.

Both of these methods would require registering the database as a datastore (which it sounds like you've already done)

Hopefully my guess at one of your scenario's is correct. If not, please explain what it is you want your users to do against what data.

View solution in original post

0 Kudos
by Anonymous User
Not applicable
Original User: tereshenkov

Kevin, thanks very much. It is the 2nd scenario, and your suggestion regarding parsing the path of FC was very helpful.

I can't seem to get the Truncate Table tool working with inline variable substitution in ModelBuilder (I thought to use this one first), so I switched completely to Python (much easier to get things done, I should say).

I use this workflow:

import arcpy
from arcpy import env
#Setting the env workspace to be an SDE geodatabase
#
env.workspace = r'C:\sde_at_DB101.sde'

#Getting the existing polygon feature class as input parameter
#
GetExistingPolyFC = arcpy.GetParameterAsText(0)
GetPolyFC = GetExistingPolyFC

# Truncate a feature class if it exists
#
if arcpy.Exists(GetPolyFC):
   arcpy.AddMessage("Polygon feature class exists, start working...")
   arcpy.TruncateTable_management(r'C:\sde_at_DB_101.sde\%s' %GetPolyFC)
   arcpy.AddMessage("Truncating table is complete")

else:
   arcpy.AddMessage("Polygon feature class does not exist")


I've used this logic for other bits of my bigger model and it works just fine as a GP service now. I've decided to rewrite the whole model as a Python script from scratch and it was much easier to implement and it performs much faster too when running the GP task. I should seriously consider using Python instead of ModelBuilder wherever it makes sense. 🙂
0 Kudos
KevinHibma-old
Regular Contributor III
Excellent, glad you got it. I really like modelling, but some situations, like this one, scripting proves to be more straight forward.

Cheers.
0 Kudos