When you publish a map service to your ArcGIS Server site, you can optionally choose to allow clients of the server to dynamically change layer appearance and behavior in your map service. Determining which layers will appear in a map, layer symbology, layer order and position, labeling, and more, can be achieved on the server through the use of dynamic layers. In this way, dynamic layers can increase the amount of interaction that users are able to have with your maps.
For example, let's say you created a map document with a U.S. states layer and applied a color classification based on each state's population in the year 2000. Then you published the map as a service to your site and referenced the service in an ArcGIS API for JavaScript web application. Now, let's say you want users of the web application to be able to display each state's 2000 population using a different color ramp. By activating dynamic layers in your map service, you give clients the freedom to change the symbols of the states in the web application. The server does the work of applying the modified color ramp and returns the resulting map image to the client application.
Note:
Although the process of enabling dynamic layers is achieved through ArcGIS Desktop, making use of dynamic layers to change symbology, adding layers, and so on, is typically done through code. The ArcGIS API for JavaScript contains documentation on how to consume map services with dynamic layers enabled.
Dynamic workspaces
If you want to dynamically add data—such as feature layers, feature classes, feature attribute tables, shapefiles, rasters, or stand-alone tables—to your map service, you'll need to set up a workspace to contain the data you want to add. Dynamic workspaces can be any enterprise database, enterprise geodatabase, file geodatabase, or file directory on disk that is accessible to the server.
When you choose a workspace, an ID is generated to uniquely identify the workspace within the pool of workspaces available to the map service. The map service uses this ID to connect to the data source specified in dynamic layer requests. You have the option to modify the ID when you configure the dynamic workspace for your map service.
Considerations when choosing a dynamic workspace
When choosing a dynamic workspace, it is recommended that the workspace only contain the layers and tables necessary to support the map service. If you're choosing an enterprise geodatabase as your dynamic workspace, the account connecting to the database should be granted minimum access privileges to the data. If possible, it is recommended that you have a separate production database to use as your dynamic workspace. To learn more about setting up data access privileges in a database, see the following topic specific to your database platform:
- User privileges in Db2
- User privileges in Informix
- User privileges in Netezza
- User privileges in Oracle
- User privileges in PostgreSQL
- User privileges in SQL Server
- User privileges in Teradata
If the above options are not possible in your environment, you should consider restricting access to your map services and web applications. You may also consider encrypting communication between the web application and your map service using HTTPS. This will encrypt service requests sent by the web application and help prevent a malicious party from obtaining the workspace ID. To learn more, see Control access to your services.
Requirements for dynamic layers
The ArcGIS Server account must have at least read access to the dynamic workspaces that contain the data you want to dynamically add to the map service. To learn more about setting share and file permissions on your workspaces when publishing, see Make your data accessible to ArcGIS Server.
For a full list of dynamic layer requirements and the functionality exposed by dynamic layers in a map service, see Supported functionality in map services.