Preparar recursos para publicar como servicios

Antes de publicar un servicio, debe crear el recurso SIG al que el servicio hará referencia. Para obtener una lista completa de recursos SIG que se pueden publicar como servicios, consulte ¿Qué tipo de servicios puede publicar? La mayoría de los recursos SIG requieren que utilice ArcGIS Desktop para crearlos.

Cuando crea primero un recurso SIG, lo guardará en su sistema de archivos local. Las aplicaciones cliente no podrán ver el recurso hasta que lo publique como un servicio.

En varias formas, crear un recurso que se utilizará en un servicio no es distinto a crear un recurso común; utiliza la aplicación apropiada, como ArcMap para seleccionar datos para el recurso y establecer las propiedades preferidas. Sin embargo, si sabe que el recurso se publicará como un servicio, deseará seguir estas pautas extra:

Almacene sus datos de manera que todos los equipos SOC puedan acceder a ellos.

Cada equipo del contenedor de objetos del servidor (SOC) en su implementación de ArcGIS Server debe poder acceder a su recurso SIG y a todos los datos que contiene. Por ejemplo, cuando publica un documento de mapa como un servicio, el documento de mapa y todos los datos para sus capas deben ser accesibles para todos los equipos SOC.

Cuando guarda sus datos en una ruta local, por ejemplo, C:\data , y crea un servicio a partir de ellos, otros equipos SOC no podrán trabajar con el servicio a menos que tengan sus propias copias de los datos que residen en C:\data . Cargar una copia idéntica de sus datos en una ruta idéntica en cada equipo SOC puede ser beneficioso para el rendimiento, pero puede no ser una solución práctica para datasets grandes o que cambian con frecuencia. Si puede hacer referencia a los datos en un repositorio común mediante ArcSDE, puede resolver el problema de duplicar grandes datasets basados en archivos.

Otra forma de poner a disposición sus datos en todos los equipos SOC es utilizar las herramientas del sistema operativo para compartir el directorio en el que se almacenan los datos. Comúnmente, se hace referencia a los directorios compartidos con rutas de la Convención de nombre universal (UNC), que contienen el nombre del servidor (por ejemplo, \\myServer\data). Cuando utiliza rutas UNC para hacer referencia a sus datos, todos los equipos SOC buscarán los datos en el equipo correcto.

Si almacena sus recursos SIG en directorios compartidos, recuerde que todas las rutas de fuente de datos dentro del recurso también deben utilizar rutas UNC o rutas relativas. Por ejemplo, si su documento de mapa contiene capas de tres clases de entidades, las rutas para esas clases de entidades deben ser rutas UNC o rutas relativas.

Otorgar permisos a la cuenta SOC para sus datos

Cuando inicia sesión en su propio equipo, el nombre de cuenta que utiliza le brinda acceso a todos sus archivos y carpetas en el equipo. Nadie más puede acceder a sus datos a menos que se lo permita. Lo mismo se aplica a sus datos SIG. Para el servidor SIG, o más específicamente, los equipos SOC, para acceder a sus datos, debe otorgar permisos a la cuenta de usuario SOC que especificó durante la postinstalación del servidor SIG. Muy probablemente, si trabaja para una gran organización, sus datos SIG no se almacenarán en su equipo local, sino que se almacenarán en una unidad de red compartida o en una geodatabase. Sin embargo, se aplican los mismos principios de concesión de acceso a los datos a la cuenta SOC.

Configurar acceso a datos basados en archivo

Si sus datos están basados en archivo, como shapefiles y coberturas, debe trabajar con el sistema operativo para configurar el acceso a las carpetas que contienen sus datos. La cuenta SOC debe tener al menos acceso de lectura a los datos y acceso de escritura si se van a editar los datos. Aquí le presentamos algunos escenarios:

• Si sus datos residen en el mismo equipo que el equipo SOC (o en uno de los equipos SOC en caso que tenga más de uno), otorgue a la cuenta SOC acceso de lectura (y opcionalmente de escritura) a las carpetas que contienen sus datos.
• Si los datos no residen en el equipo SOC y especificó una cuenta local durante la postinstalación, primero deberá crear una cuenta local idéntica (con el mismo nombre de usuario y contraseña) en el equipo que aloja sus datos. A continuación, otorgue a esa cuenta local acceso de lectura (y opcionalmente de escritura) a las carpetas que contienen sus datos. Mientras las cuentas locales en el equipo con los datos y el equipo SOC sean idénticas, el equipo SOC podrá acceder a los datos.
• Si los datos no residen en el equipo SOC y especificó una cuenta de dominio, la cuenta de dominio ya existe. Simplemente otorgue a la cuenta de dominio acceso de lectura (y opcionalmente de escritura) a las carpetas que contienen sus datos.

Debe conocer los mecanismos de seguridad y las jerarquías de su sistema operativo. Por ejemplo, si está trabajando desde un directorio compartido en Windows XP, tendrá que otorgar permisos de recursos compartidos a la cuenta del contenedor para la carpeta, después tendrá que otorgar permisos de NTFS (archivo) a la cuenta del contenedor para la carpeta. Si no otorga los dos tipos de permisos (compartir y archivo), no podrá acceder al recurso, ya que el sistema operativo da prioridad al más restrictivo de los dos.

Configurar acceso a los datos en una geodatabase

Cuando cree un servicio que haga referencia a los datos en una geodatabase, debe asegurarse de que el servidor tenga los permisos apropiados para acceder a la geodatabase. El tipo de permisos que debe otorgar depende del tipo de geodatabase que utiliza y, en el caso de ArcSDE, del tipo de autenticación que utiliza para conectarse.

Si su servicio accede a los datos desde una geodatabase de archivos o geodatabase personal, debe utilizar el sistema operativo para otorgar a la cuenta SOC permisos de lectura a la capeta que contiene la geodatabase.

La forma en la que otorga acceso a una geodatabase de ArcSDE depende de si su recurso SIG utiliza autenticación de base de datos o autenticación de sistema operativo (SO) para conectarse a ArcSDE. ¿Cómo puede decir qué tipo de autenticación se utiliza? Si la geodatabase está en SQL Server Express, utiliza autenticación del SO. Si la geodatabase está en un RDBMS corporativo (Oracle, SQL Server, DB2, Informix), puede ver las propiedades de conexión en ArcCatalog para descubrir si utiliza autenticación de base de datos o autenticación del SO.

Utilizar autenticación de base de datos

Cuando utilice autenticación de base de datos, marque las propiedades de conexión de base de datos espaciales en ArcCatalog y asegúrese de haber marcado la opción para guardar el nombre de usuario y contraseña. Si crea un documento de mapa o globo que utiliza los datos a través de esa conexión, el nombre y contraseña se guardarán en el documento de mapa o globo, y su servicio deberá poder obtener los datos correctamente.

Si publica algo como un servicio directamente desde la geodatabase, como un caja de herramientas, localizador o dataset ráster, copie el archivo de conexión de base de datos en una ubicación accesible para todos los equipos SOC.

Utilizar autenticación del SO

Si se accederá a sus datos de ArcSDE a través de la autenticación del SO, deberá agregar la cuenta SOC a la geodatabase y otorgarle permisos para el recurso al que necesita acceder. Cuando se ejecuta el servicio, iniciará sesión en DBMS como la cuenta SOC. La forma en la que agrega la cuenta SOC y le otorga permisos varía según el tipo de geodatabase de ArcSDE que utiliza:

• Si trabaja con una geodatabase de ArcSDE a nivel Corporativo, la forma en la que agrega la cuenta SOC como un usuario válido de la base de datos varía según el DBMS que utiliza. Le puede resultar útil consultar su documentación de DBMS para saber cómo otorgar acceso a una cuenta del sistema operativo. Una vez que haya agregado la cuenta SOC, debe otorgarle DETERMINADOS permisos para el recurso que va a publicar. Es posible que se necesiten permisos adicionales si editará los datos.

• Es importante copiar el archivo de conexión de base de datos en una ubicación accesible para todos los equipos SOC.

• Si trabaja con una geodatabase de ArcSDE para SQL Server Express , debe realizar los siguientes pasos en ArcCatalog para otorgar a la cuenta SOC los permisos necesarios:

  1. Haga doble clic en Servidores de base de datos en el árbol de catálogo.
  2. Haga clic con el botón derecho en el servidor de base de datos que contiene la geodatabase y, a continuación, haga clic enPermisos.
  3. Haga clic en Agregar usuario y agregue la cuenta SOC. Haga clic en Aceptar.
  4. Haga doble clic en el mismo servidor de base de datos.
  5. Haga clic con el botón derecho en la geodatabase y, a continuación, haga clic en Administración, después haga clic en Permisos.
  6. Haga clic en la cuenta SOC para seleccionarla y elija el nivel de permisos que le gustaría tener. Necesitará al menos permisos de Lectura para ver los datos y permisos de Escritura para editar. Si necesita más ayuda sobre cómo decidir qué permisos serían necesarios para su cuenta SOC, consulte Un paseo introductorio de los permisos para los servidores de base de datos en la Ayuda del ArcGIS Desktop.

Nota acerca de las conexiones a Oracle

Si tiene un servicio de mapas que utiliza ArcSDE para conectarse a una base de datos de Oracle, debe tener instalado el software cliente de Oracle en cada equipo SOC. Además, si su servicio de mapas realiza una conexión directa a Oracle9 o superior, debe otorgar a la cuenta SOC permisos de lectura para la carpeta <ubicación de instalación de Oracle>\products\<versión>\client en cada equipo SOC.

Seguir las mejores prácticas específicas para el recurso que está creando

La mayoría de los tipos de recursos tienen una lista de mejores prácticas que puede seguir cuando prepara el recurso para publicarlo como un servicio. Por ejemplo, crear una memoria caché, utilizar renderizadores dependientes de la escala o simplificar las preferencias de ubicación de etiquetas son cosas que puede hacer para ayudar a que sus servicios de mapas se ejecuten a mayor velocidad. Este sistema de ayuda contiene un tema dedicado para cada tipo de servicio que puede crear. Para obtener mejores prácticas adicionales, consulte estos temas.