All successful tools have input and output parameters. Without input parameters, the tool would always do the same processing every time it is run. Changing the value of an input parameter will produce a different result. Output parameters allow a tool to return the result. The geoprocessing service that powers a web tool has well-defined rules on both input and output parameters. These rules, explained below, ensure tools suitable for the web can be published where clients will interact with them in an expected way.
When creating a geoprocessing tool, there are many parameter data types that can be used to provide inputs to a tool. Choosing one data type over another can help those using the tool provide the expected inputs to your tool. Some data types are specialized and are not supported within a geoprocessing service. When constructing a tool to be used as a geoprocessing service, it is best if the tool is constructed using supported data types. A tool you create and distribute to colleagues may be set up slightly differently than a tool you create that will ultimately be published as a web tool.
Supported input data types in ArcGIS Pro can be any of the following data types in the left column of the table below. Once published, they will be converted to the corresponding data types in ArcGIS Enterprise.
|Data type in ArcGIS Pro||Data type in ArcGIS Enterprise|
Feature Set, Feature Layer
Raster Dataset, Raster Layer
Record Set, Table View
Boolean, Double, Long, String (text)
With the exception of Value Table, all of the data types in the previous table support multivalues. See GPMultivalue for that data type in ArcGIS Enterprise.
With the exception of Value Table, all of the types in the previous table can be part of a composite parameter. A composite parameter can support multiple values. See GPComposite for that data type in ArcGIS Enterprise.
Field data type
To use the Field data type, you need ArcGIS Pro 2.3 or later and ArcGIS Enterprise 10.7 or later.
For tools with an input field parameter, ensure that the field parameter has a dependency to a parameter, such as a feature layer or a table.
If you are using ArcGIS Pro 2.3 to ArcGIS Pro 2.9, only feature set and feature layer input are supported as a dependency. If you are publishing from ArcGIS Pro 3.0 or later to ArcGIS Enterprise 11.0 or later, the field data type can depend on all supported feature and table input data types.
Running the tool
When you run the tool before publishing between ArcGIS Pro 2.3 and ArcGIS Pro 2.9, for the feature layers on which those field parameters depend, choose a feature class from disk. Do not use a feature layer as input.
At ArcGIS Pro 3.0 or later and publishing to ArcGIS Enterprise 11.0 or later, there are no restrictions on how you choose your input data. You can use a feature layer, a feature class on disk, a table, or a table view for layers on which a field parameter depends.
When you configure the tool properties, the input mode of a field parameter will be the default Choice list option. Ensure that the input mode of the field parameter is set to the User defined value option. To learn more about input modes when sharing a web tool, see Content.
When consuming the web tool in ArcGIS Pro, all applicable fields will automatically be populated in the drop-down list after you select an input.
The field data type is not supported in apps created in ArcGIS Web AppBuilder or Map Viewer Classic in Portal for ArcGIS.
Value Table data type
A value table is a flexible table-like object, made up of rows and columns containing various values. To use the Value Table data type, you need ArcGIS Pro 3.0 or later and ArcGIS Enterprise 11.0 or later. To learn more about value table, see ValueTable. A multivalue of a valuetable is not supported.
Although the column names of a value table parameter can be empty or duplicated, unique and non-empty column names are recommended when you design tool parameters. Unique and non-empty column names allow your web tool users to distinguish different columns when they use the web tool, especially when there are multiple columns with the same data types.
You can publish a web tool with an input or output value table parameter directly using ArcGIS Pro 3.1 or later to ArcGIS Enterprise 11.0 or later. If you publish to ArcGIS Enterprise 10.9.1 or earlier, the input mode of the value table parameter is changed to constant during publishing. If publishing with Python script, you can use ArcGIS Pro 3.0 or later. If a column in the value table parameter has a filter, the publishing process will include the filter.
You can consume web tools with a value table parameter using ArcGIS Pro or with Python if the version is ArcGIS Pro 3.0 or later. The value table data type is not supported in apps created in ArcGIS Web AppBuilder or Map Viewer Classic in Portal for ArcGIS.
Composite data type
In ArcGIS Pro, there is no true composite data type; a composite data type is simply a name for a parameter with multiple data types. After publishing as a web tool, the data type can be converted to GPComposite, which is a real data type on the server. To convert a parameter data type to composite, you need ArcGIS Pro 3.2 or later and ArcGIS Enterprise 11.2.
Although there can be different data types in the parameter before publishing, ensure that each data type can be converted and what data type it will be converted to after publishing based on the input parameters table. You can use the Composite filter for composite to set the values for each subtype. The filter will be honored during publishing as a web tool. You can define a multivalue of a composite, but you cannot have a composite containing another multivalue, composite, or ValueTable data type if you want to publish as a composite later.
When publishing with ArcGIS Pro 3.2, use the Keep data type as Composite check box on the Content tab of the sharing pane. Use this option to determine whether the published web tool parameter data type is composite. The check box is only active when publishing to ArcGIS Enterprise 11.2 or later.
If publishing with an unchecked or inactive check box, or with a Python script, the web tool data type of the parameter is not composite. It is a single converted data type based on the value provided when running the tool before publishing. If publishing with a checked check box, the web tool data type of the parameter is composite. All the available input mode options for the composite data types are displayed. One of the options is mix-mode in which you can select a different input mode for each data type of the parameter. Mix-mode is not available if the data type is multivalue composite or if there is a top-level filter that applies to all the data types for the parameter.
Not all composite data types can be converted to the supported data types on the server during publishing. If a data type cannot be converted to a server-side supported data type, that data type will be dropped or become a GPString data type. If multiple data types in the composite have the same corresponding converted data types, each of them are converted to that data type individually. For example, if you have an input parameter with the LAS Dataset, Feature Set, and Feature Layer data type, it will become a composite of GPFeatureRecordSetLayer and another GPFeatureRecordSetLayer once published, given that LAS Dataset is not a supported data type, and both Feature Set and Feature Layer data types are converted to the same type on the server.
You can use web tools with a composite parameter using ArcGIS Pro 3.2 or a Python script. If using an earlier version of ArcGIS Pro, only the data type of the provided value for the parameter before publishing can be used. The composite data type is not supported in apps created in ArcGIS Web AppBuilder or Map Viewer Classic in Portal for ArcGIS.
If using ArcGIS Pro 3.2, you can use a web tool with all the supported data types of the composite parameter. Since there are some unsupported types on the server, the data types you can use may be fewer than those before publishing. To check the supported data types of the parameter, choose the web tool from the Content pane of Catalog, right-click the task and select Task Information to open the REST end point. The supported data types of a GPComposite parameter are under the attribute of parameter infos.
If the filters are set for each data type before publishing, they will be honored when running the web tool. If there are multiple converted data types with the same name and each has its own filter, consuming the web tool will match the first available value with each filter.
If the parameter you are using to construct your tool is not listed above, it is not supported for a geoprocessing service. When sharing your web tool, an unsupported parameter will be either hard-coded in the service or converted to a supported type. Understanding these two points will allow you to create a tool and still allow your tool consumers the interaction you desire. How an unsupported parameter type is transformed depends on the parameter. When sharing your web tool, the parameter transformation can be examined using Configuring the tool properties in the Content section. The following examples include some of the more common parameters and how they can be modified to work in a geoprocessing service.
For example, the feature class parameter supports both shapefiles and feature classes on disk. However, your tool may use the feature layer or feature set parameter. The feature layer parameter supports selection from a list of layers. This list of layers would be the same as the layers in your map at the time you published. Alternatively, you could use the feature set parameter. This parameter allows the interactive input of features. A web app consuming a geoprocessing service with an input feature set would allow the user to create features with which the service will interact. These concepts also apply to tables and record sets. These methods all allow a user to supply a feature input; however, they make very different services when published. Your workflow will help you decide which data type is most appropriate.
Two widely used parameter types that become hard-coded when you publish are the workspace and folder types. A workflow may take an .sde connection file or a folder and perform an operation on the items in the folder. A workspace cannot be transported to the geoprocessing service from the client. Rather, it becomes hard-coded in the published service. This hard-coded reference points to a location with these items either referenced or copied, depending on the data store setup. The published service will continue to use the workspace and its contents in the same way as before it was published. The only difference is the user of the service cannot change the workspace.
In a typical workflow, your web tool will have at least one output parameter. It is through an output parameter that a web tool will return a result to the client. Without this parameter, the service cannot return anything. Much like input parameters, geoprocessing services support some data types for output parameters.
Tip:If the tool you are creating does not need an output parameter because the purpose of the tool is to perform an update or action at a prescribed time, you may not need a geoprocessing service. In this case, a scheduled task may be a more appropriate workflow.
Supported output data types can have a parameter type of derived or required and can be any of the following data types in the left column of the table below in ArcGIS Pro. Once published, they will become corresponding data types in the right column in ArcGIS Enterprise.
Value Table data type
|Data type in ArcGIS Pro||Data type in ArcGIS Enterprise|
Boolean, Double, Long, String (text)
All of the output data types above other than ValueTable support multivalues. See GPMultiValue for that data type in ArcGIS Enterprise.
With the exception of Value Table, all of the above types in the table can be part of a composite parameter. There can be a composite parameter that supports multivalues. See GPComposite for that data type in ArcGIS Enterprise.
Composite data type
When publishing with ArcGIS Pro 3.2, use the Keep data type as Composite check box on the Content tab of the sharing pane. The check box is only active if publishing to ArcGIS Enterprise 11.2 or later.
If publishing with an unchecked or inactive check box, or with a Python script, the web tool data type of the parameter is not composite. It is the single converted data type based on the value provided when running the tool before publishing. If publishing with a checked check box, the web tool data type of the parameter is composite.
Not all the composite data types of the parameter can be converted to the supported data types on the server during publishing. If a data type cannot be converted to a server-side supported data type, that data type will be dropped or become a GPString. If multiple data types in the parameter have the same corresponding converted data types, each of them are converted to that data type individually.
All outputs become static to the consumer of the service. When a geoprocessing service is consumed in a desktop or web app, no value is ever supplied for the output parameter. This may be surprising the first time you try to run the service, as you are not presented with the chance to set the output name of a feature class. When sharing a web tool, the process that publishes the geoprocessing service handles the output. The output name when you ran the tool in ArcGIS Pro becomes the name of the output result from the service. The service handles writing the output to either memory or a scratch location such as Scratch Folder, Scratch GDB, or Scratch Workspace environments. The service will return the output to the client after the service has successfully run.
Some parameter types are not supported in a geoprocessing service, as they cannot be returned to the client. Workspaces and complex types such as network datasets and geometric networks are examples. A workspace, for instance, could be a folder, a feature dataset, or an .sde connection file. The service cannot send back a folder or a container of items. If your workflow requires that you send back multiple items or complex items composed of several items, you may need to change the output parameter type to file, and zip these items and return the .zip file. Alternatively, if your workflow allows, you may be able to use the Copy Features tool and return a simplified feature class result.