Skip To Content ArcGIS for Developers Sign In Dashboard

Task operation overview

Online geoprocessing service execution types

When working with online geoprocessing services, developers must be aware of the execution mode that the service was published with. Geoprocessing tasks can be straightforward and take a few seconds to execute or can support advanced functionality or process very large datasets which may take longer to execute. There are three execution types for geoprocessing tasks on a server.

Execute (synchronous)
Services can be published to support synchronous execution, which is designed for fast running tasks where the client sends the request and then waits for the response. This means these types of service use less resources on the server. When developers interact with these services, they must use the execute or executeAndWait methods of the Geoprocessor class.
Submit Job (asynchronous)
Asynchronous services are best suited for long running tasks. The client submits a task as a job to the server, and immediately the server returns a job ID which the client uses to poll for the job status. When the job status is completed, the results can be requested from the server using the job ID. Developers must use the submitJob or submitJobAndGetResults methods to work with these services.
Submit Job with Map Server Result
The results map server is a dynamic map service that accompanies a geoprocessing service to visualize the geoprocessing results. Each GPRecordSetLayer output parameter of a geoprocessing task will be added as a layer to the map service. The visualization of the layers is determined by the symbology defined when the geoprocessing service is published. Since it is a dynamic map service, clients can add the map service or the map service layers to their runtime applications.

Local geoprocessing service execution types

For local geoprocessing services, the application code starts up the local geoprocessing service. Unlike online geoprocessing service tasks, where all the service parameters are predefined by the service author, developers must specify some of the local service parameters themselves based on how they want to interact with the service. These parameters include the execution type, whether the service will work with a results map server, and the maximum number of records that the service can return. Once the service is running, it's not possible to change the execution type.

Starting a local geoprocessing service with the execution type set to Execute is designed for working with geoprocessing tasks that run very quickly. This execution type uses a single RuntimeLocalServer process. It does not provide any immediate feedback on the execution of the tool. It will execute and either return a success or failure when the task has finished. Just as with the online geoprocessing service, the developer must use the execute or executeAndWait methods on the Geoprocessor class to work with local geoprocessing services which have been started as type Execute.
The SubmitJob execution mode starts two RuntimeLocalServer processes: one to do the processing and the other to monitor the processing. This allows the application to poll the monitoring process for execution messages and the current status of the task. Additionally, the task can be cancelled if necessary. Once the task completes, the data can be requested from the service. To run tasks on this service, the developer must use the submitJob or submitJobAndGetResults methods.
The third type of execution is similar to the SumbitJob. An additional RuntimeLocalServer process is started which is used to host the result of the geoprocessing task in a LocalMapService. This is particularly useful if your task outputs a large number of features that the client application has to symbolize and draw or if your task outputs a data type that is not supported for adding directly to the map control via the API, such as raster data. The default symbology of this map service is determined when the geoprocessing package is published.

Maximum number of records

By default, the maximum number of records a local geoprocessing service will return is 1000. If the service exceeds this number, no records will be returned. This value is specified when creating the local geoprocessing service and cannot be changed once the local service is running. The purpose of this limit is to protect the server from large requests which could take a long time to process. If 0 results are returned but the job completes successfully, always check the result and job messages to determine whether the maximum records limit was reached.