Geoprocessing > Sharing tools and toolboxes > Sharing tools on an ArcGIS Server
Considerations for authoring and publishing models |
|
|
Release 9.2
Last modified November 9, 2007 |
Print all topics in : "Sharing tools on an ArcGIS Server" |
A model that works well on your computer will most likely need adjustments in order to publish to a server. The following subsections discuss adjustments you may need to make.
Map Symbology
The models and scripts you publish can be used on clients other than ArcGIS Desktop, such as in custom web applications developed with Java and .Net. These clients do not have access to all of the symbology options you find in ArcMap. This comes into consideration when:
- You are using a Feature Set data type for input.
- Your output is a Feature Class, and there is no associated map service.
Both of the above situations can be found in the example of publishing a geoprocessing service.
For input Feature Sets, you have to set a schema for the input features. This schema defines both the type of feature (point, line, polygon) and the symbology to display each feature added. The newly added feature will be drawn using the client's graphics library, which may only have basic capabilities, not the advanced drawing capabilities found in ArcMap.
For the output Feature Class, you can right-click the variable, click Properties, then click the Layer Symbology tab, and import symbology to apply to the features. If there is no associated map service, the output Feature Class will be drawn using the client's graphics library, which, as noted above, may only have basic capabilities.
In these situations (custom web application with Feature Set input or Feature Class output), you want to use simple symbology. Use the following symbol types only.
| Points | Lines | Polygons |
| Simple Marker Symbol | Simple Line Symbol | Simple Fill Symbol |
| Character Marker Symbol |
|
Picture Fill Symbol |
| Picture Marker Symbol |
|
|
|
|
|
|
NOTE: If you use a Character Marker Symbol, choose a common font—one that the client is likely to have installed.
You can determine the symbol type in the Symbol Property Editor, as illustrated below:
Learn more about the symbol properties editor
Data access
Any datasets, tools, and scripts that are used in your model must be accessible by the server. Giving ArcGIS Server access to folders describes how you can share folders so that the server can access their contents.
Data type support
Variables in your model have a data type. There are restrictions on which data types you can use as input and output parameters for published models and tools. For variables that are not parameters, there are no restrictions.
The types of data type support are as follows:
- Data type is fully supported for both input and output parameters.
- Data type is not supported for input parameters.
- Data type is not supported for output parameters.
- Data type will be converted to a String data type.
Learn more about support for input and output data types
There are ten data types that are fully supported as input and output parameters for your published models and scripts, as below:
| Feature Set |
| Record Set |
| Raster Dataset |
| String |
| Long |
| Double |
| Boolean |
| Date |
| Linear Unit |
| File |
Feature classes as input
Variables with the Feature Class data type are not allowed as input parameters. You can replace any input Feature Class variable with a Feature Set data type, which is fully supported for input. Right-click the Feature Class variable, click Properties, and change the data type from Feature Class to Feature Set in the Data Type tab.
Learn more about the Feature Set data type
Instead of using a Feature Class as input, consider using a layer from a map service. The two examples of authoring a publishing geoprocessing services show the basics of authoring models, and demonstrate how to use feature sets and map service layers instead of feature classes.
Example of geoprocessing service
Example of map service with geoprocessing service
Feature classes as output
A published model that has a Feature Class as an output variable will have the features returned as a Feature Set stored in a temporary location on the user's computer. The user can copy the feature set to a permanent location in the Results tab of the ArcToolbox window.
Learn more about geoprocessing service results
As a tool publisher, you are allowed to set limits on the number of records (features in the case of Feature Class) that can be transferred from the server back to the user's computer. Your server administrator should give you guidelines on the maximum number of records limit you should set. If your output feature class exceeds the limit you have set, the result will be <data exceeds transfer limit>. If you suspect that your result will exceed the transfer limit, you should publish your tools with a associated map service (a tool layer in the map document). With an associated map service, the result will display in ArcMap, so your user can view the results, but they still won't be able to transfer the feature class because it exceeds the limits.
Tables as input
A model with a Table data type as input will not publish. You can replace any input Table variable with a Record Set data type, which is fully supported for input. Right-click the Table variable, click Properties, and change the data type from Table to Record Set in the Data Type tab.
Learn more about the Record Set data type
As a tool publisher, you are allowed to set limits on the number of records (rows in a table) that can be transferred from the server back to the user's computer. Your server administrator should give you guidelines on the maximum number of records limit you should set. If your output table exceeds the limit you have set, the result will be <data exceeds transfer limit>.
Tables as output
A published model that has a Table as an output variable will have the rows returned as a Record Set stored in a temporary location on the user's computer. The user can copy the record set to a permanent location in the Results tab of the ArcToolbox window.
Learn more about geoprocessing service results
Using the file data type
Consider the following model that takes a coverage as input and outputs a new workspace—a file geodatabase containing a feature dataset with feature classes made from the coverage, and a validated topology. (All the work in this example model occurs in the hypothetical Convert Coverage script tool.)
This model will publish, but will not work. The Input Coverage and the Output Location data variables are converted to string data types. The Input Coverage will become a string containing the pathname to the coverage. The Output Location will become a string with the pathname to the folder to contain the file geodatabase. When the model is published, there will be a data type mismatch between what the Convert Coverage script expects (Coverage and Folder) and what it gets—strings.
This model needs to be re-thought if it is to become a geoprocessing service. This particular model could be recast as follows:
Instead of an input coverage, an Interchange file is input. The data type is File, which is one of the fully supported data types, and is created by the user with the Export To Interchange File tool. The model converts the interchange file back to a coverage using Import From Interchange File tool and inputs it to the Covert Coverage script, which would be modified to create and write to a scratch file geodatabase located on the server. This scratch file geodatabase can then be converted (within the script) to a .zip file (a File data type) for transport back across the internet to the client. Click here for more details about converting files and folders to .zip files.
Coverting strings to variables
Every data type has a string representation, which is documented in Data types for geoprocessing tool parameters.
(Click here to view a PDF of the Geoprocessing data types. If this link doesn't work, follow the instructions in Data types for geoprocessing tool parameters)
If an input to your model is one of the data types that is converted to a string when published to ArcGIS Server, you can write a script that takes the string representation and converts it into the data type you need. The script (Python) consists of two lines:
in_string = gp.GetParameterAsText(0)
gp.SetParameterAsText(1, in_string)
You define the output data type in the parameters properties of the script tool. Below is an example of converting a string to an Areal Unit, which will subsequently be used by the Simplify Polygon tool.
You can use this script to convert the input string to an areal unit, then connect the areal unit variable to Simplify Polygon (or any other tool that takes an Areal Unit as input), as shown below.
Since the user can input any string to the Convert string to Areal Unit script, the script should include some checking to determine if the string is a valid areal unit (for example, 1000 SQUARE FURLONGS is not a valid areal unit).
Multiple processes updating the same data
When a server tool is executing, there is said to be an instance of the tool. You can think of an instance as a session on your computer because multiple instances behave like multiple sessions on your computer. For example, suppose you have two ArcMap sessions open on your computer, and each is executing a tool that updates features in the same feature class. You can't have two sessions updating the same feature class at the same time, so one of the tool executions will fail due to a schema lock.
Learn more about working with schema locks
The same is true for two instances of the same service—if they update the same data, one of the instances will fail.
In this situation, you have a couple of strategies you can use. First, you can configure your service so that only one instance is allowed. Secondly, you might be able to modify your tool so that it logs the updated features in a temporary feature class, and then have another tool that merges the updates. You would run the merge updates tool periodically.
Documentation
When you publish a toolbox, all associated help is published along with it, just as you'd expect. Since you're publishing a geoprocessing service for a wide audience, good tool documentation is vital.
Learn more about documenting tools