Preparing resources for publishing as services

Before publishing a service, you need to create the GIS resource that the service will reference. For a full list of GIS resources that can be published as services, see What types of services can you publish? Most GIS resources require that you use ArcGIS Desktop to create them.

When you first create a GIS resource, you'll save it on your local file system. Client applications will not be able to view the resource until you publish it as a service.

In many ways, creating a resource that will be used in a service is no different than creating an ordinary resource; you use the appropriate application, such as ArcMap, to select data for the resource and set your preferred properties. However, if you know that a resource will be published as a service, you'll want to follow these extra guidelines:

Store your data in a way that all SOC machines can access it

Each server object container (SOC) machine in your ArcGIS Server deployment needs to be able to access your GIS resource and all the data it contains. For example, when you publish a map document as a service, the map document and all the data for its layers must be accessible to all SOC machines.

When you save your data to a local path, for example, C:\data or /opt/local/data on Linux/Solaris, and create a service from it, other SOC machines will not be able to work with the service unless they have their own copies of the data residing at C:\data or /opt/local/data on Linux/Solaris. Loading an identical copy of your data into an identical path on each SOC machine can be beneficial for performance, but it may not be a practical solution for large or frequently changing datasets. If you're able to reference data in a common repository using ArcSDE, you can solve the problem of duplicating large file-based datasets.

Another way to make your data available to all SOC machines is to use the operating system tools to share the directory in which the data is stored. Shared directories are commonly referred to with Universal Naming Convention (UNC) paths or NFS mounted folders on Linux/Solaris, which contain the name of the server (for example, \\myServer\data or /net/myserver/opt/local/data). When you use UNC paths or NFS paths to reference your data, all SOC machines will look to the correct machine for the data.

If you store your GIS resources in shared directories, remember that all data source paths within the resource must also use UNC paths, NFS paths, or relative paths. For example, if your map document contains layers from three feature classes, the paths to those feature classes must be UNC paths, NFS paths, or relative paths.

Give the SOC account permissions to your data

When you log in to your own computer, the account name you use gives you access to all your files and folders on the computer. No one else can access your data unless you allow them to. The same holds true for your GIS data. For the GIS server—or more specifically, the SOC machines—to access your data, you must grant permissions to the SOC user account you specified during the GIS Server Post Install. (On Linux/Solaris, the SOC account is the same as the GIS server installation owner account). Most likely, if you work for a large organization, your GIS data won't be stored on your local computer but instead will be stored on a shared network drive or in a geodatabase. However, the same principles of granting the SOC account access to the data apply.

Setting up access to file-based data

If your data is file based, such as shapefiles and coverages, you'll need to work with the operating system to set access to the folders that contain your data. The SOC account must have at least read access to the data and write access if the data will be edited. Here are some scenarios:

• If your data resides on the same machine as the SOC machine (or one of the SOC machines in the event you have more than one), grant the SOC account (or installation owner account on Linux/Solaris) read (and optionally write) access to the folders containing your data.
• If the data doesn't reside on the SOC machine and you specified a local account during the postinstallation, you will first need to create an identical local account (same user name and password) on the machine that hosts your data. Then grant that local account read (and optionally write) access to the folders containing your data. As long as the local accounts on the machine with data and the SOC machine are identical, the SOC machine will be able to access the data.
• If the data doesn't reside on the SOC machine, do the following:

  On Linux/Solaris

  1. Grant permissions to the SOC account for the data files.
  2. Grant permissions to the SOC account for the data folder. You need to grant permissions to every directory down to this folder. For the example above, you need to grant permissions to all the folders below:
     • /opt
     • /opt/local/
     • /opt/local/data

  On Windows

  If you specified a local account during the postinstallation, you will first need to create an identical local account (same user name and password) on the machine that hosts your data. Then, grant that local account read (and optionally write) access to the folders containing your data. As long as the local accounts on the machine with data and the SOC machine are identical, the SOC machine will be able to access the data.

  If you specified a domain account, the domain account will already exist. Simply grant the domain account read access to the folders containing your data.

  You should be aware of your operating system's security mechanisms and hierarchies. For example, if you are working from a shared directory in Windows XP, you will have to give the container account share permissions for the folder, then you will have to grant NTFS (file) permissions to the container account for the folder. If you do not grant both types of permissions (share and file), you will not be able to access the resource, since the operating system gives precedence to the more restrictive of the two.

Setting up access to data in a geodatabase

When you create a service that references data in a geodatabase, you need to ensure that the server has the appropriate permissions to access the geodatabase. The type of permissions you need to grant depends on what type of geodatabase you are using and, in the case of ArcSDE, what type of authentication you are using to connect.

If your service accesses data from a file geodatabase or personal geodatabase, you should use the operating system to give the SOC account read permissions to the folder containing the geodatabase.

Note:

A personal geodatabase is not a supported data source on ArcGIS Server on Linux/Solaris.

The way you grant access to an ArcSDE geodatabase depends on whether your GIS resource uses database authentication or operating system (OS) authentication to connect to ArcSDE. How can you tell which type of authentication is being used? If the geodatabase is in SQL Server Express, it uses OS authentication. If the geodatabase is in an enterprise RDBMS (Oracle, SQL Server, DB2, Informix), you can view the connection properties in ArcCatalog to find out whether it uses database authentication or OS authentication.

Note:

Joins that use ODBC connections on Windows are not supported by ArcGIS Server on Linux/Solaris

Using database authentication

When using database authentication, check your spatial database connection properties in ArcCatalog and make sure you've checked the option to save the user name and password. If you create a map or globe document that uses data through that connection, the name and password will be saved in the map or globe document, and your service should be able to get the data successfully.

If you are publishing something as a service directly from the geodatabase, such as a toolbox, locator, or raster dataset, copy the database connection file to a location accessible to all SOC machines.

Using OS authentication

If your ArcSDE data will be accessed through OS authentication, you'll need to add the SOC account to the geodatabase, then grant it permissions to the resource that it needs to access. When the service runs, it will log in to the DBMS as the SOC account. The way that you add the SOC account and grant it permissions varies depending on what type of ArcSDE geodatabase you are using:

• If you're working with an ArcSDE geodatabase at the Enterprise level, the way that you add the SOC account as a valid user of the database varies depending on the DBMS that you are using. You may find it helpful to consult your DBMS documentation to learn how to grant access to an operating system account. Once you've added the SOC account, you need to grant it SELECT permissions to the resource that you are going to publish. Additional permissions may be necessary if you will be editing data.

• It's important to copy the database connection file to a location accessible to all SOC machines.

• If you're working with an ArcSDE for SQL Server Express geodatabase (not supported by ArcGIS Server on Linux/Solaris), you need to perform the following steps in ArcCatalog to give the SOC account the necessary permissions:

  1. Double-click Database Servers in the Catalog tree.
  2. Right-click the database server containing the geodatabase and click Permissions.
  3. Click Add User and add the SOC account. Click OK.
  4. Double-click the same database server.
  5. Right-click the geodatabase, click Administration, then click Permissions.
  6. Click the SOC account to select it and choose the level of permissions you would like it to have. You'll need at least Read permissions to see the data and Write permissions for editing. See A quick tour of permissions for database servers in the ArcGIS Desktop Help if you need further help deciding which permissions would be necessary for your SOC account.

Note about connections to Oracle

If you have a map service that uses ArcSDE to connect to an Oracle database, you need to have the Oracle client software installed on each SOC machine. Additionally, if your map service makes a direct connection to Oracle9 or later, you need to grant the SOC account read permissions to the folder <Oracle installation location>\products\<version>\client on each SOC machine.

Follow best practices specific to the resource you're creating

Most types of resources have a list of best practices you can follow when preparing the resource for publishing as a service. For example, creating a cache, using scale-dependent renderers, or simplifying label placement preferences are things you can do to help your map services run faster. This help system contains a dedicated topic for each type of service you can create. See these topics for additional best practices.