The Server library contains objects that allow you to connect and work with ArcGIS Servers. Developers gain access to an ArcGIS Server using the ServerConnection object. The ServerConnection object gives access to the ServerObjectManager. Using this object, a developer works with ServerContext objects to manipulate ArcObjects running on the server.
The API in the Server library can be used in any Java SE or Java EE container. Developers can build thin-client web applications or Swing-based applications to invoke ArcObjects functionality on remote servers.
The Server library is not extended by developers.
To make use of the GIS server to host ArcObjects by your application, the first thing that application must do is connect to the GIS server, i.e. connect to the SOM. Connections to the GIS server are made through the ServerConnection object. The ServerConnection object supports a single interface: IServerConnection. IServerConnection has a Connect method that connects the application to the GIS server. You call the Connect method and provide the name or IP address of the machine on which the server object manager is running.
Once connected to the GIS Server, IServerConnection has properties that hand out references to the ServerObjectManager and the ServerObjectAdmin for making use of server objects and administering server objects, respectively.
In order to successfully connect to the GIS server using ServerConnection, the user account running the application must be a member of the agsusers group on the GIS server. If the account running the application is not a member of this group, the Connect method on IServerConnection will throw an IOException. If the user account running the application is a member of the agsadmin user group on the GIS server, the ServerObjectAdmin property on IServerConnection can be used to get a reference on the ServerObjectAdmin. If the user account running the application is not in the agsadmin user group, the ServerObjectAdmin property will throw an IOException.
The following code is an example of how to use the ServerConnection to connect to a GIS server running on a machine "husker" and print out the names and types of the server object configurations configured on the server:
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
IEnumServerObjectConfigurationInfo servObjConfInfoEnum = null;
IServerObjectConfigurationInfo configurationInfo = null;
// Initialize server with impersonation information.
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
// Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectManager class.
IServerObjectManager som = connection.getServerObjectManager();
IServerContext context = som.createServerContext("USA", "MapServer");
MapServer ms = (MapServer)context.getServerObject();
System.out.println(ms.getDefaultMapName());
context.releaseContext();
System.out.println("done");
} catch (AutomationException ae) {
System.err.println("Caught J-Integra AutomationException: "
+ ae.getMessage() + "\n");
ae.printStackTrace();
} catch (IOException e){
System.err.println("Caught IOException: " + e.getMessage()
+ "\n");
e.printStackTrace();
}
Server Consumer Objects
When developing applications that connect to a GIS server, you need to be able to access objects running in the server and create objects in the server for your application’s use. If the user your application runs as is a member of the agsusers user group on the GIS server, then that application will be able to connect to the GIS server using the ServerConnection object and can get a reference to the set of objects that provide the ability for the application to make use of ArcObjects running in the server.
The ServerObjectManager class provides access to information about the GIS server to nonadministrators, and creates ServerContexts for use by applications. Any application that runs as a user account in the agsusers user group on the GIS server can connect to the GIS server and get a reference to the ServerObjectManager.
The ServerObjectManager is used for gaining access to and working with server objects. Each server object has a server object configuration. The IServerObjectManager interface has the necessary methods for an application to get the collection of server object configurations, server object types, and server directories configured in the server as ServerObjectConfigurationInfo, ServerObjectTypeInfo, and ServerDirectoryInfo objects, respectively.
The createServerContext method on IServerObjectManager is used to get a reference to a context on the server. A context is a process managed by the server within which a server object runs. You can use createServerContext to create a context based on a server object configuration, or you can create empty contexts solely for the purpose of creating ArcObjects on the fly within the server.
When using createServerContext to create a context based on a server object configuration, if the server object configuration is pooled, you may get a reference to a context that is already created and running in the server. When you have completed using that context, it is important to release it explicitly by calling the releaseContext method on IServerContext to return it to the pool. When using createServerContext to create a context based on a non-pooled server object configuration, or when creating an empty context, a new context is created on the server. You still need to call releaseContext when you are finished using it, and the context is destroyed on the server.
The following code is an example of how to connect to the GIS server "husker", create a server context based on the RedlandsMap server object configuration, get a reference to the USA MapServer object running in the context, and print its DefaultMapName property. Note the call to releaseContext when the use of the context is complete:
//Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
//Get reference to ServerObjectManager class.
IServerObjectManager som = connection.getServerObjectManager();
IServerContext context = som.createServerContext("USA", "MapServer");
MapServer ms = (MapServer)context.getServerObject();
System.out.println(ms.getDefaultMapName());
context.releaseContext();
The following code is an example of how to create an empty server context and, within that context create a new polygon and print its area. Note the call to releaseContext when the use of the context is complete:
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
// Initialize server with impersonation information.
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
// Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectManager class.
IServerObjectManager som = connection.getServerObjectManager();
IServerContext context = som.createServerContext("", "");
// Create a new Polygon in the server context
Polygon ptCol = (Polygon)context.createObject("esrigeometry.Polygon");
// Create the points in the server context
Point pt0 = (Point)context.createObject("esrigeometry.Point");
Point pt1 = (Point)context.createObject("esrigeometry.Point");
Point pt2 = (Point)context.createObject("esrigeometry.Point");
Point pt3 = (Point)context.createObject("esrigeometry.Point");
pt0.putCoords(0.0,0.0);
pt1.putCoords(10.0,0.0);
pt2.putCoords(10.0,10.0);
pt3.putCoords(0.0,10.0);
// Add the points to the polygon
ptCol.addPoint(pt0,null,null);
ptCol.addPoint(pt1,null,null);
ptCol.addPoint(pt2,null,null);
ptCol.addPoint(pt3,null,null);
IArea area = (IArea)ptCol;
System.out.println(area.getArea());
context.releaseContext();
System.out.println("done");
} catch (AutomationException ae) {
System.err.println("Caught J-Integra AutomationException: "
+ ae.getMessage() + "\n");
ae.printStackTrace();
} catch (IOException e){
System.err.println("Caught IOException: " + e.getMessage()
+ "\n");
e.printStackTrace();
}
A server context is a reserved space within the server dedicated to a set of running objects. GIS server objects also reside in a server context. When developing applications with ArcGIS Server, all ArcObjects that your application creates and uses reside within a server context. To obtain a server object, you actually get a reference to its context, then get the server object from the context.
You get a server context by calling the createServerContext method on IServerObjectManager.
IServerContext contains methods for creating and managing objects running within the ServerContext. You can get at the server object running within a server context by calling getServerObject on IServerContext. The following code is an example of creating a server context and getting a reference to the MapServer server object running in the server context.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectManager class.
IServerObjectManager som = connection.getServerObjectManager();
IServerContext context = som.createServerContext("USA", "MapServer")
MapServer ms = (MapServer)context.getServerObject();
As was described in a previous example, you can also create empty server contexts. You can use an empty context to create ArcObjects on the fly within the server to do add hoc GIS processing.
All ArcObjects that your application uses should be created within a server context using the createObject method on IServerContext. Also, objects that are used together should be in the same context. For example, if you create a Point object to use in a spatial selection to query features in a feature class, the point should be in the same context as the feature class.
ArcGIS Server applications should not use New to create ArcObjects but should always create objects by calling createObject on IServerContext. For example:
Incorrect:
Point pt = new Point();
Correct:
Point pt0 = (Point)context.createObject("esrigeometry.Point");
When your application is finished working with a server context, it must release it back to the server by calling the releaseContext method. If you allow the context to go out of scope without explicitly releasing it, it will remain in use and be unavailable to other applications until it is garbage collected. Once a context is released, the application can no longer make use of any objects in that context. This includes both objects that you may have obtained from the context or objects that you created in the context.
// Get reference to ServerObjectManager class.
IServerObjectManager som = connection.getServerObjectManager();
IServerContext context = som.createServerContext("USA", "MapServer");
// Do something with the object
doSomething();
// Release the context when finished doing something
context.releaseContext();
IServerContext provides some useful methods that allow you to create and manage GIS objects within the context that can be used in your applications
IServerContext context = som.createServerContext("", "");
// Create a new Polygon in the server context
Polygon ptCol = (Polygon)context.createObject("esrigeometry.Polygon");
The createObject method will return a proxy to the object that is in the server context. Your application can make use of the proxy as if the object were created locally within its process. If you call a method on the proxy that hands back another object, that object will actually be in the server context and your application will be handed back a proxy to that object. In the above example, if you get a SpatialReference object from the Polygon using getSpatialReference() , the object returned will be in the same context as the Polygon.
If you add some points to a Polygon using insertPoints() , the MultiPoint, in this case, must be created and used in the same context as the Polygon.
Polygon poly = (Polygon)sc.createObject("esriGeometry.Polygon");Point pts = (Point)sc.createObject("esriGeometry.Point");pts.setX(-118.556);pts.setY(35.044);poly.insertPoints(0,0,pts);
Also, you should not directly use objects in a server context with local objects in your application and vice versa. You can indirectly use objects or make copies of them. For example, if you have a Point object in a server context, you can get its X, Y properties and use them with local objects or use them to create a new local point. Don’t directly use the point in the server context as, for example, the geometry of a local graphic element object.
Consider the following examples. In each example, assume that objects with Remote in their names are objects in a server context as in:
Point remotePoint = new Point(context.createObject("esriGeometry.Point"));
while objects with Local in their name are objects created locally as in:
Point localPoint = new Point();
You can’t set a local object to a remote object:
// this is incorrect
localPoint = remotePoint;
// this is also incorrect
Point localPoint = new Point(remotePoint);
Do not set a local object, or a property of a local object, to be an object obtained from a remote object:
// this is incorrect
Point localPoint = (Point)remotePointCollection.getPoint(2);
When calling a method on a remote object, don’t pass in local objects as parameters:
// this is incorrect
sde4Workspace = remoteWorkspaceFactory.open(localPropertySet,0);
You can get simple data types (double, long, string, etc.) that are passed by value from a remote object and use them as properties of a local object as in:
//this is OK
localPoint.setX(remotePoint.getX());
setObject and getObject allow you to store references to objects in the server context. A context contains a dictionary that you can use as a convenient place to store objects that you create within the context. Note that this dictionary is itself valid only as long as you hold on to the server context, and it is emptied when you release the context. You can use this dictionary to share objects created within a context between different parts of your application that have access to the context.
setObject adds objects to the dictionary, and getObject retrieves them. An object that is set in the context will be available until it is removed (by calling remove or removeAll ) or until the context is released.
Polygon polygon = (Polygon)context.createObject("esriGeometry.Polygon");
context.setObject("myPolygon",polygon);
Polygon p = (Polygon)context.getObject("myPolygon");
Use the remove and removeAll methods to remove objects from a context that have been set using setObject. Once an object is removed, a reference can no longer be made to it using getObject. Note that if you do not explicitly call remove or removeAll , you can still not get references to objects set in the context after the context has been released.
context.remove("myPolygon");
The saveObject and loadObject methods allow you to serialize objects in the server context to strings, then deserialize them back into objects. Any object that supports IPersistStream can be saved and loaded using these methods. These methods allow you to copy objects between contexts. For example, if you use a GeocodeServer object to locate an address, then you want to draw the point that geocodeAddress returns on your map, you need to copy the point into your MapServer's context.
new ServerInitializer().initializeServer(domain, user, password);
ServerConnection connection = new ServerConnection();
connection.connect(host);
IServerObjectManager som = connection.getServerObjectManager();
IServerContext scGC = som.createServerContext("PortlandGC", "GeocodeServer");
IServerContext scMap = som.createServerContext("PortlandMap","MapServer");
GeocodeServer geocodeServer = (GeocodeServer)scGC.getServerObject();
MapServer mapServer = (MapServer)scMap.getServerObject();
PropertySet propSet = (PropertySet)scGC.createObject("esriSystem.PropertySet");
propSet.setProperty("Street", "2111 Division St");
PropertySet results = (PropertySet)geocodeServer.geocodeAddress(propSet,null);
Object[] names = new Object[5];
Object[] values = new Object[5];
results.getAllProperties(names,values);
for(int i = 0;i<names.length;i++){
if(names[i] != null){
System.out.println(names[i]);
}
}
Object pt = results.getProperty("Shape");
// Save and Load...
String pointString = scGC.saveObject(pt);
Point pointCopy = (Point)scMap.loadObject(pointString);
System.out.println(pointCopy.getX());
This diagram illustrates the use of saveObject and loadObject to copy objects between server contexts:
Another important use of these methods is to manage state in your application while making stateless use of a pooled server object. A good example of this is in a mapping application. The initial session state for all users is the same and is equal to the map description for the map server object. Each user can then change map description properties such as the extent and layer visibility, which need to be maintained in the user’s session state. The application does this by saving a serialized map description as part of each user’s session state. Using the serialized string representation allows the application to take advantage of the standard session state management facilities of the Web server. The application uses the loadObject and saveObject methods to reconstitute the session’s map description whenever it needs to make edits to it in response to user changes or whenever it needs to pass the map descriptor to the map server object for drawing the map according to the user’s specifications.
A ServerObject is a coarse-grained ArcObjects component, that is a high-level object that simplifies the programming model for doing certain operations and hides the fine-grained ArcObjects that do the work. Server objects support coarse-grained interfaces that support methods that do large units of work, such as “draw a map”, or “geocode a set of addresses”. ServerObjects also have SOAP interfaces, which makes it possible to expose server objects as Web services that can be consumed by clients across the Internet.
ArcGIS Server has five types of ServerObjects:
The MapServer object is a coarse-grained server object that provides access to the contents of a map document and methods for querying and drawing the map.
The GeocodeServer object is a coarse-grained server object that provides access to an address locator and methods for single address and batch geocoding.
The GeocodeServer object is a coarse-grained server object that provides access to an address locator and methods for single address and batch geocoding.
The GeodataServer object is a coarse-grained server object that provides access to a geodatabase and methods for data management.
The GlobeServer object is a coarse-grained server object that provides access to a globe document and methods for displaying the globe.
The GPServer object is a coarse-grained server object that provides access to one or more geoprocessing tools and methods for executing those tools in the GIS server.
Server objects and their extensions can be used in ArcGIS Server applications, in which case the server object manager creates and manages instances of the server object and its extensions in process running within the server. You get a reference to a server object running in the GIS server from its ServerContext (see above).
IServerObject is an interface implemented by all server objects such as the MapServer and GeocodeServer. The IServerObject is returned by the getServerObject() method on IServerContext. The IServerObject interface has properties to indicate the name and type of the server object configuration that created the server object. You can cast the ServerObject to IMapServer for a MapServer object, or IGeocodeServer for a GeocodeServer object.
The following code shows how to connect to a GIS server, create a server context based on a server object configuration, and use the ServerObject property to get the IServerObject interface on the server context's server object:
new ServerInitializer().initializeServer(domain, user, password);
ServerConnection connection = new ServerConnection();
connection.connect(host);
IServerObjectManager som = connection.getServerObjectManager();
IServerContext scGC = som.createServerContext("PortlandGC", "GeocodeServer");
GeocodeServer geocodeServer = (GeocodeServer)scGC.getServerObject();
// Do something with the GeocodeServer object...
scGC.releaseContext();
Server objects may also have extensions that extend their base functionality for more specialized uses. Each type of server object may have a set of extensions that can be enabled or disabled based on its configuration. For example, the MapServer server object includes a network analysis server object extension that can be enabled for map server’s that include network analysis layers and are inteded for use in applications that include routing, service area or some other network analysis type of functionality. ArcGIS Server includes a number of server object extensions out of the box, and developers can extend ArcGIS Server by writing their own server object extensions.
Server objects extensions also have SOAP interfaces for handling SOAP requests to execute methods and returning results as SOAP responses. This support for SOAP request handling makes it possible to expose server object extensions as Web services that can be consumed by clients across the Internet.
ArcGIS Server includes the following server object extensions to the MapServer:
· NAServer extension which extends the MapServer server object to include network analysis functions for operations such as routing and service area analysis
· Mobile server extension which extends the MapServer server object to allows mobile devices to extract data from a map on the server.
· WMS extension which extends the MapServer server object to provide the capabilies required for publishing the MapServer as an OGC WMS web service
· KML extension which extends the MapServer server object to return a stream of vector and/or raster layers to any client capable of reading KMZ (compressed KML) documents.
IServerObjectExtensionManager is an interface supported by all server objects. Once you have a reference to a server object, you can use the methods on IServerObjectExtensionManager to find enabled extensions either by name (findExtensionByName) or by CLSID (findExtensionByCLSID). Once you have a reference to the server object extension, you can QI for any of its interfaces.
The following code shows how to get the nework analysis extension to a MapServer and find the network analysis layers in the map:
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
//Open connection to the server.
connection = new ServerConnection();
connection.connect("mercy");
// Get referenceto ServerObjectManager and the MapServer context
IServerObjectManager som = connection.getServerObjectManager();
IServerContext context = som.createServerContext("SanFran_NA", "MapServer");
// Get the MapServer Server Object and the Server Object Extension
MapServer ms = (MapServer)context.getServerObject();
IServerObjectExtensionManager soeManager = new IServerObjectExtensionManagerProxy(ms);
IServerObjectExtension soe = soeManager.findExtensionByTypeName("NAServer");
INAServer naServer = (INAServer)soe;
// Get the NALayerNames
String[] layers = naServer.getNALayerNames(esriNAServerLayerType.esriNAServerClosestFacilityLayer);
context.releaseContext();
} catch (Exception ae) {
ae.printStackTrace();
}
The Server object library’s Info classes provide read-only access to users and developers who are not administrators to the properties of server directories, server types, and server object configurations. These properties are those that are necessary for developing applications using the GIS server.
Each Info class has a corresponding class that is only accessible to administrators (users in the agsadmin user group), which exposes the properties of the Info object with read/write access as well as additional properties.
The ServerObjectConfigurationInfo class provides read-only access to some of the properties of a server object configuration.
The ServerObjectTypeInfo class provides read-only access to some of the properties of a server object type.
A ServerDirectoryInfo object is an Info object that describes the properties of a server directory.
The GIS server manages a set of server directories. A server directory is a location on a file system that the GIS server is configured to clean up files it writes. The ServerDirectoryInfo class gives users and developers who are not administrators access to the list of server directories and the set of their properties that are necessary for programming applications that use them as locations to write output. You can get information about server directories using the getServerDirectoryInfos method on IServerObjectManager to get the IServerDirectoryInfo interface.
Files in a server directory can be cleaned based on file age, or based on when the file was last accessed. The maximum file age or time since last accessed is a property of a server directory. If the CleaningMode is esriDCAbsolute, then all files created by the GIS server that are older than the maximum age are automatically cleaned up by the GIS server. If the CleaningMode is esriDCSliding , then all files created by the GIS server that have not been accessed for a duration defined by maximum age are automatically cleaned up by the GIS server.
Note that when creating files in a server directory, they must be prefixed with "_ags_" to be cleaned up by the GIS server. Any files in a server directory not prefixed with "_ags_" will not be cleaned up. IServerDirectoryInfo provides read–only access to a subset of the server directory's properties. These properties include:
Path: the physical path of the directory in disk
URL: the URL of the virtual directory corresponding to the physical directory
Description: the description of the server directory
CleaningMode: indicates whether the directory is cleaned by file age, by last accessed, or if its contents are not cleaned up
MaxFileAge: indicates the maximum age or the maximum time since last accessed that files can be in the server directory before they are cleaned up
The properties listed above are those necessary for developers of server applications to make use of the various GIS servers’ server directories.
The following code shows how to list the server directories of a GIS server using the ServerDirectoryInfo class:
public static void main(String[] args) {
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
IEnumServerDirectoryInfo servDirInfoEnum = null;
IServerDirectoryInfo serverDirInfo = null;
// Initialize server with impersonation information.
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
// Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectManager class.
IServerObjectManager som = connection.getServerObjectManager();
servDirInfoEnum = som.getServerDirectoryInfos();
serverDirInfo = servDirInfoEnum.next();
while(serverDirInfo != null){
System.out.println(serverDirInfo.getPath());
serverDirInfo = servDirInfoEnum.next();
}
} catch (AutomationException ae) {
System.err.println("Caught J-Integra AutomationException: "
+ ae.getMessage() + "\n");
ae.printStackTrace();
} catch (IOException e){
System.err.println("Caught IOException: " + e.getMessage()
+ "\n");
e.printStackTrace();
}
}
A ServerObjectConfigurationInfo object is an Info object that describes the properties of a server object configuration.
The GIS server manages a set of server objects running across one or more host (container) machines. How those server objects are configured and run is defined by a set of server object configurations. The ServerObjectConfigurationInfo class gives users and developers who are not administrators access to the list of server object configurations and the set of their properties that are necessary for programming applications with them. You can get information about server object configurations using the getConfigurationInfos method on IServerObjectManager to get the IServerObjectConfigurationInfo interface. Note that the getConfigurationInfos method returns only server object configurations that are started.
IServerObjectConfigurationInfo provides read–only access to a subset of the server object configuration's properties. These properties include:
Name: the name of the server object configuration
TypeName: the type of server object configuration (for example, MapServer, GeocodeServer)
Description: the description of the server object configuration
IsPooled: indicates whether the server objects described by this configuration are pooled or non-pooled
The properties listed above are those necessary for developers of server applications to make use of the various server objects configured on the GIS server.
The following example shows how to connect to a GIS server and use the IServerObjectConfigurationInfo interface to print out the name and type of all the server object configurations:
public static void main(String[] args) {
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
IEnumServerObjectConfigurationInfo servObjConfInfoEnum = null;
IServerObjectConfigurationInfo serverObjectConfInfo = null;
// Initialize server with impersonation information.
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
// Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectManager class.
IServerObjectManager som = connection.getServerObjectManager();
servObjConfInfoEnum = som.getConfigurationInfos();
serverObjectConfInfo = servObjConfInfoEnum.next();
while(serverObjectConfInfo != null){
System.out.println(serverObjectConfInfo.getName() + " : " + serverObjectConfInfo.getTypeName());
serverObjectConfInfo = servObjConfInfoEnum.next();
}
} catch (Exception ae) {
ae.printStackTrace();
}
}
A ServerObjectTypeInfo object is an Info object that describes the properties of a server object type.
The ServerObjectTypeInfo class gives users and developers who are not administrators access to the list of server object types and the set of their properties that are necessary for programming applications with them. You can get information about server object types using the getTypeInfos method on IServerObjectManager to get the IServerObjectTypeInfo interface.
IServerObjectTypeInfo provides read–only access to a subset of the server object type's properties. These properties include:
Name: the name of the server object type (e.g., MapServer, GeocodeServer)
Description: the description of the server object type
Server Administration Objects
When developing applications that connect to a GIS server for the purposes of administering the GIS server and its server objects, you need to have access to the objects for administering these aspects of the GIS server. If the user your application runs as is a member of the agsadmin user group on the GIS server, then that application will be able to connect to the GIS server using the GISServerConnection object and can get a reference to the set of objects that provide the ability for the application to administrate the GIS server and its server objects.
Applications that make use of ArcObjects running in the server do not require access to the administration objects.
The ServerObjectAdmin class administrates a GIS server. Any application that runs as a user account in the agsadmin user group on the GIS server can use the IGISServerConnection interface to connect to the GIS server and to get a reference to the ServerObjectAdmin. If the user account is not part of the agsadmin user group, the ServerObjectAdmin property on IGISServerConnection will return an error. Applications that are running as accounts that can connect to the server but are not part of the agsadmin user group can use the ServerObjectManager property on IGISServerConnection to get a reference on the ServerObjectManager .
Use ServerObjectAdmin to administrate both the set of server object configurations and types associated with the server as well as to administer aspects of the server itself. The following administration functionality of the GIS Server is provided by ServerObjectAdmin :
Administer server object configurations:
Administer aspects of the server itself:
You can use IServerObjectAdmin to administrate either the server’s set of server object configurations and server object types and to administrate aspects of the server itself, such as the list of machines that may host server objects. If your application is connecting to the server to make use of objects in the server, use the IServerObjectManager interface.
The addConfiguration method will add a ServerObjectConfiguration to your GIS server. A new ServerObjectConfiguration can be created using the createConfiguration method. Use the IServerObjectConfiguration interface to set the various properties of the configuration, then use the addConfiguration method on IServerObjectAdmin to add the new configuration to the GIS server. Once a configuration is added to the server, you can use startConfiguration to make it available for applications to use.
The following code shows how to connect to the GIS server called "husker" and use the createConfiguration, addConfiguration, and startConfiguration methods to create a new geocode server object configuration, add it to the server, and make it available for use:
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
IServerObjectConfiguration serverObjectConf = null;
// Initialize server with impersonation information.
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
// Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectAdmin
IServerObjectAdmin soa = connection.getServerObjectAdmin();
serverObjectConf = soa.createConfiguration();
serverObjectConf.setName("PortlandGC");
serverObjectConf.setTypeName("GeocodeServer");
IPropertySet props = serverObjectConf.getProperties();
props.setProperty("LocatorWorkspacePath", "C:\\Program Files\\ArcGIS\\java\\samples\\data\\serverdata\\toxic");
props.setProperty("Locator","portland.loc");
props.setProperty("SuggestedBatchSize", "500");
serverObjectConf.setIsPooled(true);
serverObjectConf.setMaxInstances(1);
serverObjectConf.setMinInstances(1);
serverObjectConf.setWaitTimeout(10);
serverObjectConf.setUsageTimeout(120);
// Add the configuration to the server
soa.addConfiguration(serverObjectConf);
} catch (Exception ae) {
ae.printStackTrace();
}
The updateConfiguration method will update the ServerObjectConfiguration that is specified when the method is called. You can use the getConfiguration or getConfigurations methods on IServerObjectAdmin to get a reference to the ServerObjectConfiguration you want to update.
Note that the server object configuration must be stopped before you call updateConfiguration. You can use stopConfiguration to stop the server object configuration.
The following code shows how to connect to the GIS server called “husker” and use getConfiguration to get a ServerObjectConfiguration, change its MaxInstances property, then update the configuration using the updateConfiguration method:
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
IServerObjectConfiguration serverObjectConf = null;
// Initialize server with impersonation information.
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
// Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectAdmin
IServerObjectAdmin soa = connection.getServerObjectAdmin();
serverObjectConf = soa.getConfiguration("PortlandMap","MapServer");
serverObjectConf.setMaxInstances(3);
soa.updateConfiguration(serverObjectConf);
} catch (Exception ae) {
ae.printStackTrace();
}
Use deleteConfiguration to delete a server object configuration from your GIS Server. Note, in order to call deleteConfiguration, the server object configuration must be stopped. If it is not stopped, then deleteConfiguration will return an error.
The following code shows how to stop, then delete a server object configuration called PortlandMap:
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
// Initialize server with impersonation information.
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
// Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectAdmin
IServerObjectAdmin soa = connection.getServerObjectAdmin();
soa.stopConfiguration("PortlandMap","MapServer");
soa.deleteConfiguration("PortlandMap","MapServer");
} catch (Exception ae) {
ae.printStackTrace();
}
The ServerObjectConfiguration class describes the configuration for a server object that is managed by the GIS server. ServerObjectConfigurations can be added, removed and modified by users or developers who are members of the agsadmin users group and, therefore, have administrator privileges on the GIS server.
The administrator-level properties of ServerObjectConfiguration are:
A read-only subset of properties of a ServerObjectConfiguration are available to nonadministrators via the GISServerConnectionInfo object. These nonadministrator level properties are:
The IServerObjectConfiguration interface is a read/write interface on a server object configuration that allows administrators to configure new server object configurations to add to the server, update existing server object configurations, and view the configuration properties of a server object configuration.
If you use IServerObjectConfiguration to modify any of a configuration’s
properties, you must call updateConfiguration on IServerObjectAdmin for those changes to be reflected in the server.
Use the IsolationLevel property to get the server object isolation, or set it for a new configuration or to update an existing configuration.
Server objects can have either high isolation (esriServerIsolationLevelHigh) or low isolation (esriIsolationLevelLow). Each instance of a server object with high isolation runs in a dedicated process on the server that it does not share with other server objects. Instances of server objects with low isolation may share the same process with other server object instances of the same configuration. Use the isPooled property to indicate if the server objects created by this server object configuration are pooled or non-pooled.
Server objects can be either pooled or non-pooled. Pooled server objects can be shared across multiple sessions and applications and are held on to by an application for the duration of a single request. Pooled server objects are meant for applications that make stateless use of those objects.
Non-pooled server objects are dedicated to a single application session and are held on to for the duration of an application session. Non-pooled server objects are not shared between application sessions and are meant for applications that make stateful use of those objects.
When startConfiguration is called on a server object configuration whose isPooled property is true a set of server objects will be preloaded based on the MinInstances property of the server object configuration. When startConfiguration is called on a server object configuration whose isPooled property is false, no server objects are pre-loaded. Server objects are loaded and initialized when an application gets one from the server using CreateServerContext .
The MaxInstances property indicates the maximum number of server objects that can be running and handle requests at any one time. If the maximum number of server objects are running and busy, additional requests will be queued until a server object becomes free.
For a pooled server object, the MaxInstances represents the maximum simultaneous requests that can be processed by the server object configuration. For a non-pooled server object, the MaxInstances represents the maximum number of simultaneous application users of that particular server object configuration. The MaxInstances property must be greater than 0 and must be greater than the MinInstances property. The MinInstances property applies to only pooled server object configurations. It represents the number of server object instances that are preloaded when the server object configuration is started. The GIS server will ensure that the minimum number of instances are always running within the server for a given configuration. When there are more simultaneous requests than server object instances running, additional server object instances will be started until MaxInstances is reached.
Non-pooled server object configurations always have a MinInstances property of 0. The MinInstances property must be less than the MaxInstances property. The Name property in combination with the TypeName property is used to identify a server object configuration in methods such as getConfiguration, updateConfiguration, startConfiguration , etc.
Name is case sensitive and can have a maximum of 120 characters. Names can contain only the following characters:
A–Z
a–z
0–9
_ (underscore)
- (minus)
The TypeName property indicates the type of server object that this configuration creates and runs. Examples are MapServer and GeocodeServer.
Server objects that are defined by server object configurations have a collection of initialization parameters and properties associated with them. An example of an initialization parameter is the map document associated with a MapServer object. An example of a property is the batch geocode size for a GeocodeServer object. You can get these properties and change them using the Properties property on the server object configuration. The Properties property returns an IPropertySet. Use getProperty and setProperty on IPropertySet to get and set these properties. If you change these properties, you must call updateConfiguration to change them in the server object configuration.
You also use the Properties property to get a reference on the PropertySet for a new server object configuration to set its properties before adding it to the server by calling addConfiguration .
Recycling allows for server objects that have become unusable to be destroyed and replaced with fresh server objects and to reclaim resources taken up by stale server objects.
Pooled server objects are typically shared between multiple applications and users of those applications. Through reuse, a number of things can happen to a server object to make them unavailable for use by applications. For example, an application may incorrectly modify a server object’s state, or an application may incorrectly hold a reference to a server object, making it unavailable to other applications or sessions. In some cases, a server object may become corrupted and unusable.
Recycling allows you to keep the pool of server objects fresh and cycle out stale or unusable server objects. You can get the recycling properties and change them using the RecyclingProperties property on the server object configuration. The RecyclingProperties property returns an IPropertySet. Use getProperty and setProperty on IPropertySet to get and set these properties. If you change these properties, you must call updateConfiguration to change them in the server object configuration.
The properties associated with recycling are:
The StartupType indicates if the configuration is automatically started (esriSTAutomatic) when the server object manager windows service is started. Server object configurations that are not configured to start up automatically (esriSTManual) must be started manually using ArcCatalog or by calling the startConfiguration method on IServerObjectAdmin .
The amount of time it takes between a client requesting a server object (using the createServerContext method on IServerObjectManager) and getting a server object is called the wait time. A server object can be configured to have a maximum wait time by specifying the WaitTimeout property on IServerObjectConfiguration . If a client’s wait time exceeds the maximum wait time for a server object, then the request will time out.
The WaitTimeout property is in seconds.
Once a client gets a reference to a server object, it can hold on to that server object as long as desired before releasing it. The amount of time between when a client gets a reference to a server object and when it is released is the usage time. To ensure that clients don’t hold references to server object’s for too long (e.g., they don’t correctly release server objects), a server object can be configured to have a maximum usage time by specifying the UsageTimeout property on IServerObjectConfiguration . If a client holds onto a server object longer than the maximum usage time, then the server object is automatically released and the client will lose the reference to the server object.
The UsageTimeout is in seconds.
ArcGIS Server is a distributed system. Server objects managed by the GIS server can run on one or more host machines. A machine that can host server objects must have the Server Object Container installed on it, and the machine must be added to the list of host machines managed by the Server Object Manager.
Use the addMachine method to add new host machines to your GIS server. Once a machine has been added to the GIS server, as new server object instances are created, the server object manager will make use of the new machine. Use the createMachine method to create a new server machine that you can pass as an argument to the addMachine method to add new host machines to your GIS server.
Use the getMachines method to get the names of the machines that have been added to the server to host server objects.
The deleteMachine method removes a machine from the machines that can host server objects for the GIS server. When you delete a machine, any instances of server objects that are running on that machine will be shut down and replaced with instances running on the GIS server’s other host machines.
The ServerMachine class is used to define a machine that can host server objects managed by the GIS server.
ArcGIS Server is a distributed system. Server objects managed by the GIS server can run on one or more host machines. A machine that can host server objects must have the Server Object Container installed on it, and the machine must be added to the list of host machines managed by the Server Object Manager.
IServerMachine allows you to configure the properties of a machine to add it to the GIS server. You must set the Name property for the machine, which will be the name of the machine on the network. The description is optional.
Use the addMachine method to add new machines to your GIS server. All server objects configured in the GIS server can run on any of the host machines, so all host machines must have access to the necessary data and output directories used by all the server objects.
The following code shows how to use the IServerMachine interface and addMachine method to add a machine to your GIS server:
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
IServerMachine machine = null;
// Initialize server with impersonation information.
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
// Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectAdmin
IServerObjectAdmin soa = connection.getServerObjectAdmin();
// Create and add a new machine to the ServerObjectAdmin
machine = soa.createMachine();
machine.setName("herbie");
soa.addMachine(machine);
} catch (Exception ae) {
ae.printStackTrace();
}
You can use IServerObjectAdmin to add and remove server directories from the GIS server. Both server objects and server applications typically need to write either temporary data or result data to some location for it to be delivered, or presented to the end user. For example, a map server object’s exportMapImage method can create an image file that is then displayed on a Web application. These files are typically transient and temporary by nature. For example, when a map server writes an image to satisfy a request from a Web application, that image is needed only for the time it takes to display it on the Web application. An application that creates check-out personal geodatabases for download would provide a finite amount of time during which that geodatabase is created and when it can be downloaded.
Because server applications support many user sessions, these output files can accumulate and need to be periodically cleaned up. The server provides the capability to automatically cleanup these output files if they are written to one of the server's output directories.
Use the createServerDirectory method to create a new server directory that you can pass as an argument to the addServerDirectory method to add new server directories to your GIS server. Once you have added the server directory, you can configure your server objects and server applications to make use of the server directory.
Note: Server directories must be accessible by all host machines configured in the GIS server.
The following code shows how to use the createServerDirectory and addServerDirectory methods to add a directory to your GIS server:
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
IServerDirectory dir = null;
// Initialize server with impersonation information.
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
// Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectAdmin
IServerObjectAdmin soa = connection.getServerObjectAdmin();
// Create and add a new directory to the Server
dir = soa.createServerDirectory();
dir.setCleaningMode(esriServerDirectoryCleaningMode.esriSDCSliding);
dir.setDescription("Default output directory");
dir.setPath("C:\\Inetpub\\wwwroot\\ArcGIS");
dir.setURL("http://husker/ArcGIS");
dir.setMaxFileAge(100);
soa.addServerDirectory(dir);
} catch (Exception ae) {
ae.printStackTrace();
}
The updateServerDirectory method will update the ServerDirectory that is specified when the method is called. You can use the getServerDirectory or getServerDirectories methods on IServerObjectAdmin to get a reference to the ServerDirectory you want to update.
The updateServerDirectory is useful for modifying the cleanup mode (CleaningMode) and cleanup schedule.
The following code shows how to connect to the GIS server called “husker” and use the getServerDirectory method to get a ServerDirectory, change its MaxFileAge property, then update the directory using the updateServerDirectory method:
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
IServerDirectory dir = null;
// Initialize server with impersonation information.
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
// Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectAdmin
IServerObjectAdmin soa = connection.getServerObjectAdmin();
// Get a server directory and change it's MaxFileAge
dir = soa.getServerDirectory("C:\\Inetpub\\wwwroot\\ArcGIS");
dir.setMaxFileAge(500);
soa.updateServerDirectory(dir);
} catch (Exception ae) {
ae.printStackTrace();
}
The deleteServerDirectory method removes a directory from the set of directories managed by the GIS server. The deleteServerDirectory method will not affect the physical directory.
When a server directory is removed with this method, the GIS server will no longer manage the cleanup of output files written to that directory. Applications or server objects that are configured to write their output to the physical directory that is referenced by the server directory will continue to work, but the files they write will not be cleaned up by the server.
The ServerDirectory class defines the properties of a server directory. A server directory is a location on a file system that the GIS server is configured to clean up files that it writes. By definition, a server directory can be written to by all container machines.
The GIS server hosts and manages server objects and other ArcObjects for use in applications. In many cases, the use of those objects requires writing output to files. For example, when a map server object draws a map, it writes images to disk on the server machine. Other applications may write their own data; for example an application that checks out data from a geodatabase may write the check-out personal geodatabase to disk on the server.
Typically, these files are transient and need only be available to the application for a short time, for example, the time for the application to draw the map or the time required to download the check-out database. As applications do their work and write out data, these files can accumulate quickly. The GIS server will automatically clean up its output if that output is written to a server directory.
Files in a server directory can be cleaned based on file age or based on when the file was last accessed. The maximum file age or time since last accessed is a property of a server directory. If the CleaningMode is esriDCAbsolute, then all files created by the GIS server that are older than the maximum age are automatically cleaned up by the GIS server. If the CleaningMode is esriDCSliding , then all files created by the GIS server that have not been accessed for a duration defined by maximum age are automatically cleaned up by the GIS server.
Note that when creating files in a server directory, they must be prefixed with "_ags_" in order to be cleaned up by the GIS server. Any files in a server directory not prefixed with "_ags_" will not be cleaned up.
The IServerDirectory interface allows you to configure the properties of a server directory to add it to the GIS server. You must set the Path, CleaningMode, and MaxFileAge (if cleaning mode is absolute or sliding) properties for the server directory, which will be the directories’ path on disk. The Description and URL properties are optional.
The URL property is the virtual directory that corresponds to the physical directory specified by the Name property. Server objects, such as a map server object, can use the Name property to write their output files to a directory where they will be cleaned up and can pass back to clients the URL for the location of the files they write. Clients (for example, Web applications) will then not require direct access to the physical directory.
Use the addServerDirectory method on IServerObjectAdmin to add the new server directory to your GIS server.
The Properties property on IServerObjectAdmin returns the properties for the GIS server. The properties are for the GIS server’s logging and for server object creation timeout.
The GIS server logs its activity, including server object configuration startup, shutdown, server context creation and shutdown, and errors generated through any failed operation or request in the GIS server.
You can control the logging properties through the PropertySet returned by Properties. The following is a description of the logging properties:
0 (None): No logging
1 (Error): Serious problems that require immediate attention
2 (Warning): Problems that require attention
3 (Normal): Common administrative messages of the server
4 (Detailed): Common messages from user use of the server, including server objects
5 (Debug): verbose messages to aid in troubleshooting
All aspects of logging can be changed when the GIS server is running. When they are changed, the server will immediately use the new logging settings.
The following example shows how to use the Properties property on IServerObjectAdmin to modify the logging properties of the GIS server:
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
// Initialize server with impersonation information.
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
// Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectAdmin
IServerObjectAdmin soa = connection.getServerObjectAdmin();
IPropertySet props = soa.getProperties();
props.setProperty("LogPath", "c:/ServerLogs");
props.setProperty("LogLevel",new Integer(5));
soa.setProperties(props);
} catch (Exception ae) {
ae.printStackTrace();
}
Server object creation may hang for a variety of reasons. To prevent this from adversely affecting the GIS server, it has a ConfigurationStartTimeout property that defines the maximum time in seconds a server object instance has to initialize itself before its creation is cancelled.
As the GIS server creates and destroys server objects, handles client requests and so on, statistics about these events are logged in the GIS server’s logs. In addition to the log, statistics are also kept in memory and can be queried using the IServerStatistcs interface.
ArcCatalog provides administrators with a user interface for querying the GIS server’s statistics.
You can query the GIS server for statistics on the following events described by esriServerStatEvent:
| Value | Description |
|---|---|
| esriSSEContextCreated | A client made a call to CreateServerContext on IServerObjectManager and got a reference to a server context. |
| esriSSEContextCreationFailed | CreateServerContext failed due to an error. Errors will be logged in the GIS server's log files. |
| esriSSEContextCreationTimeout | CreateServerContext timed out because there we no available server objects for the requested configuration for a duration longer than the server object configuration's WaitTimeout. |
| esriSSEContextReleased | A client released the server context by calling ReleaseServerContext. The time measured is the time the client held onto the context (the time between when they called CreateServerContext and receives a reference to the server context, and the time they release the server context). |
| esriSSEContextUsageTimeout | A client did not release the server context by calling ReleaseServerContext before the context's server object configuration's UsageTimeout was reached. |
| esriSSEServerObjectCreated | A new server object was created. This can happen when a pooled configuration is started and the object pool is populated, when a server object is recycled, or in response to a call to CreateServerContext. The time measured is the time to create the server object. |
| esriSSEServerObjectCreationFailed | The creation of a new server object instance failed due to an error. Errors will be logged in the GIS server's log files. |
You can query these events using the statistical functions described by esriServerStatFunction:
Note: For esriSSEContextCreationFailed, esriSSEContextCreationTimeout, esriSSEContextUsageTimeout, and esriSSEServerObjectCreationFailed, the only relevant statistical function is esriSSFCount , as these events do not have time associated with them. The other functions reflect the statistics of the elapsed time associated with the event.
While the GIS server’s logs maintain a record of all events in the server, the set of statistics that are in memory and that can be queried are accumulated summaries of time slices since the GIS server was started. The granularity of these time slices is more coarse the further back in time you go. These statistics can be queried for the following time intervals:
Each time period is an accumulated total of the statistics for that time period. For example, if you query the total number of requests to create server contexts for the last 30 days, you would get statistics from now to the beginning of the day 30 days ago (not to the current time on that day). This is because the in-memory statistics have been combined for that entire day.
This means that you may actually get statistics for a longer period that you specified in your query. When you query the GIS server for statistics, you can use the IServerTimeRange interface to get a report of the actual time period that your queries results reflect.
The IServerStatistics interface has methods for querying a specific statistical function for an event or for querying all statistical functions for an event.
Use the getSpecificStatisticForTimeIntervals method to query the GIS server for a specific statistic for an event at discrete time intervals. For example, you can use this method to get the count of all server contexts that were created for each minute of the last hour.
Use the getAllStatisticsForTimeInterval to query the GIS server for all statistics for an event. For example you can use this method to get the sum, mean, etc., of server contexts usage time for the last two days.
These methods can be used to query based on the events occurring in the server as a whole (i.e., across all machines) or for those occurring on a specific machine. In addition, these methods can be used to query based on the events using all server objects or for events on a particular server object.
You specify the time interval for which you want to query using an index of time periods relative to the current time based on the time period described by esriServerTimePeriod. The index argument to the getSpecificStatisticForTimeIntervals and getAllStatisticsForTimeInterval methods describe the index of the time period to start from, and the length argument describes the number of time periods to query.
For example, to query for all statistics in the last two hours, specify a time period of esriSTPHour , an index of 0, and a length of 2.
To query for all statistics since the server started, specify a time period of esriSTPNone , an index of 0, and a length of 1.
If you are unsure of the actual time period that the results of your query reflect, use the IServerTimeRange interface to get a report of the actual time period that your query results reflect.
Use the Reset method to clear the statistics in memory.
The following code shows how to query the GIS server for statistics on the create context event for all host machines all configurations since the GIS server was started. It also demonstrates the usage of the IServerTimeRange interface to report the actual time the statistics represent:
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
// Initialize server with impersonation information.
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
// Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectAdmin
ServerObjectAdmin soa = (ServerObjectAdmin)connection.getServerObjectAdmin();
// Get the statistics
ServerStatisticsResults stats = (ServerStatisticsResults)soa.getAllStatisticsForTimeInterval(esriServerStatEvent.esriSSEContextCreated,esriServerTimePeriod.esriSTPNone,0,1,"","", "");
System.out.println(stats.getCount() + " : " + stats.getStartTime() + " to " + stats.getEndTime() );
} catch (Exception ae) {
ae.printStackTrace();
}
The following code shows the same query but for statistics for only the last two hours:
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
// Initialize server with impersonation information.
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
// Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectAdmin
ServerObjectAdmin soa = (ServerObjectAdmin) connection.getServerObjectAdmin();
// Get the statistics
ServerStatisticsResults stats = (ServerStatisticsResults)soa.getAllStatisticsForTimeInterval(esriServerStatEvent.esriSSEContextCreated,esriServerTimePeriod.esriSTPHour,0,2,"","", "");
System.out.println(stats.getCount() + " : " + stats.getStartTime() + " to " + stats.getEndTime() );
} catch (Exception ae) {
ae.printStackTrace();
}
The following code shows the query for statistics since the server started for only the USA map server object:
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
// Initialize server with impersonation information.
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
// Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectAdmin
ServerObjectAdmin soa = (ServerObjectAdmin)connection.getServerObjectAdmin();
// Get the statistics
ServerStatisticsResults stats = (ServerStatisticsResults)soa.getAllStatisticsForTimeInterval(esriServerStatEvent.esriSSEContextCreated,esriServerTimePeriod.esriSTPNone,0,1,"USA","MapServer", "");
System.out.println(stats.getCount() + " : " + stats.getStartTime() + " to " + stats.getEndTime() );
} catch (Exception ae) {
ae.printStackTrace();
}
The following code shows the query for the count of server contexts created for each minute in the last 60 minutes for all host machines and all server objects:
ServerInitializer serverInitializer = null;
ServerConnection connection = null;
// Initialize server with impersonation information.
serverInitializer = new ServerInitializer();
serverInitializer.initializeServer();
try {
// Open connection to server.
connection = new ServerConnection();
connection.connect("husker");
// Get reference to ServerObjectAdmin
ServerObjectAdmin soa = (ServerObjectAdmin) connection.getServerObjectAdmin();
// Get the statistics
IDoubleArray dar = soa.getSpecificStatisticForTimeIntervals(esriServerStatEvent.esriSSEContextCreated,esriServerStatFunction.esriSSFCount,esriServerTimePeriod.esriSTPMinute,0,60,"","", "");
for(int i = 0;i<dar.getCount();i++){
System.out.println(dar.getElement(i));
}
} catch (Exception ae) {
ae.printStackTrace();
}