When sharing a web tool, there are multiple properties that define how the users of the service interact with the web tool. Working through the options in the Share as a web tool pane allows you to set sharing permissions and how the service will return results and configure tool input parameters.
Sharing web tools requires administrative or web tool publisher permissions. Fine-grain publishing roles can also be configured so that anyone in a group can share a web tool to a specific federated server. Alternatively, the server allowGPAndExtensionPublishingToPublishers property can be set to allow publishers to share a web tool to the server.
One of the first steps before publishing is to analyze the web tool. The analyze process looks for issues that will prevent the tool from being published. Information on the data and tools that will make up the service and potential solutions will be offered. Some analyzer errors can only be resolved by modifying the tools or data that comprise your tool. Other messages and warnings provide guidance and best practices. After critical errors have been addressed and the settings of the service have been configured, the web tool can be published.
Add a tool
When sharing a web tool, the process starts with the result of a model or script tool. You can build a web tool using multiple results. Any successful geoprocessing history item can be included in a web tool to be published as a service. Adding multiple tools is a good technique when grouping similar tools or tools that are part of a workflow.
A new tool cannot be added to an existing web tool. You need to republish the existing tool and the tool to be added into a new, single geoprocessing service (web tool).
By default, a web tool is only accessible by the account from which is was created. The web tool can be shared within the organization, to specific groups, or to everyone.
When sharing a web tool to a local portal, the hosting server is the default server for the underlying geoprocessing service. Web tools and the geoprocessing services that power them are expected to be fast and responsive. Sharing many web tools to a hosting server where many feature services are also running may incur a performance penalty due to the lack of system resources. If you have multiple servers available and they are federated into your portal, it may be advantageous to separate the geoprocessing services from the default hosting server to their own federated server. Without having multiple federated servers, geoprocessing services can be shared to the hosting server without problem as long as good service and resource management by administrators and publishers is undertaken.