Managing input and output

Geoprocessing tools create new (output) data by performing operations on existing (input) data. This aspect of geoprocessing introduces a number of considerations that you need to take into account when creating a server application that requires geoprocessing.

As with any server application, the processing of a server application that incorporates geoprocessing can run on a number of container machines in a distributed server configuration. Any input data required for geoprocessing tools must be stored in a location that is accessible by all the geographic information system (GIS) server's container machines.

If the input data is stored in a geodatabase, all container machines must be able to connect to that geodatabase. If the input data is file-based data (shapefiles, computer-aided design [CAD] files, and so forth), that data must be located on a network drive and referenced via Universal Naming Convention (UNC) paths, or mounted as the same drive on each container machine. The server container account must have at least read-access to the input data.

Because geoprocessing tools typically create output data of some kind, you need to  manage this data—by anticipating things like name collisions, data cleanup and so forth—as part of designing your application. Typically, you'll write this output to a server directory so that it can be automatically cleaned up by the server after a fixed period of time. When generating either temporary or final results of a geoprocessing operation, those results need to be persistent while the application makes use of them (for example, to download to the client, draw on a map, and so forth). To keep one user's results from being overwritten by another user's results before they have finished using the data, each user's version of the data must be uniquely named. 

In the case of a model where a number of tools are sequenced together, the temporary or intermediate data that is generated by processes in the model that feeds into subsequent processes also needs to be managed and cannot collide with the intermediate data from other user sessions running the same model. To account for this, a scratch workspace should be referenced using the geoprocessing environment variable. In your model, all intermediate data paths should be specified using a reference to the environment variable. If the scratch workspace is created in a server directory, it will be automatically cleaned up by the server. Using this pattern will ensure that each user session has its own scratch workspace, and there will be no name collisions in intermediate data.

If your application requires specific geoprocessor environment settings, its the responsibility of the application to establish those environment properties before executing tools, and it should anticipate that other applications or sessions could be setting the environment for their use.