Task operation overview

Geoprocessing server 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. Therefore, there are two ways that geoprocessing tasks can run on the 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 ExecuteAysnc methods of the Geoprocessor object.

Submit Job (asynchronous)

Asynchronous services are best suited for long running jobs. In asynchronous tasks, the server returns a job ID which the client uses to poll for the task status. When the status is completed, the results can be requested from the server using the job ID. Developers must use the SubmitJob and SubmitJobAsnyc 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 geodataset 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 at the time of publishing. 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 developer must start up the local geoprocessing service themselves. Unlike online geoprocessing service tasks, where all the service parameters are predefined by the service author, developers must specify some of the parameters themselves based on how they want to interact with the service. These parameters include the execution type, whether they want to work with a results map server, and the maximum number of records that the service can return.

Execute

Starting a local geoprocessing service with the execution type set to Execute will result in a single RuntimeLocalServer process and is designed for working with quick executing geoprocessing tasks. This geoprocessing service type will not provide any 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 ExecuteAsync methods on the Geoprocessor task class to work with local geoprocessing services which have been started as type Execute. Once the service is running, it is not possible to change the execution type.

SubmitJob

The SubmitJob mode will start two RuntimeLocalServer processes: one to do the processing and the other to monitor the processing. This allows the monitoring process to be polled by the application to get back execution messages and the 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, SubmitJobAsync or SubmitJobAndGetResultsAsync methods.

SubmitJobWithMapServerResult

The third type of execution is treated the same as the SumbitJob except that 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 shared in ArcMap.

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. The reason for this 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, it is recommended that you always check the result and job messages to determine whether the maximum records limit was reached. This value is specified when creating the local geoprocessing service and cannot be changed once the local service is running.