Global Attribute Configuration

In SuperMap iServer, the global variable information of the configuration system can be set through the "Global Settings" page. Such as service storage setting, map tile caches setting, repository setting.

Access the SuperMap iServer service manager WebManager and click on "Advanced-Global Settings", enter to the global settings page (http://localhost:8090/iserver/admin-ui/advanced/globalsettings) to configure the global variables used in iServer:

Map Tile Caches Setting

Table 1 Service Setting Parameter Description

The above properties can also be set through the system config file. Please refer to iServer Config File Description .

Service Storage Setting

In SuperMap iServer, it is supported to store the service configuration information in the database or config file by setting the service configuration information storage. After the configuration is modified, it needs to be restarted to take effect.

Service configuration information is stored in config file

• Service configuration storage type: If the service configuration information needs to be stored in the config file, select XML as the service configuration storage type. For details, see iServer Config File Description.

Service configuration information is stored in the database

Table 2 Service Configuration Storage Parameter Description

Notice

1. Due to partial versions of PostgreSQL The database service only listens on the Localhost address. When iServer and PostgreSQL are not on the same machine, iServer may connect to PostgreSQL. The condition of the service failure. You need to configure the config file PostgreSQL. Conf of PostgreSQL, setting:

listen_address='*'

Allows other machines to access PostgreSQL by IP or domain name Database service.

2. The security policy of PostgreSQL allows only local users to access by default. When iServer and PostgreSQL are not on the same machine, the system user of iServer using PostgreSQL may not be able to access The PostgreSQL service. You need to add an access policy in the PG _ hba. Conf file to allow hosts in the specified network segment to access. The settings are as follows:

host all all 192.168.112.0/24 md5

• host: Indicate the host where PostgreSQL is installed

• The first All: All database instances on the host

• The second All: All users

• 192.168.112.0/24 : Indicates a network segment that can be accessed using legitimate user information. You can replace '192.168.112.0' with the network segment you want.

• md5: Authentication method

3. If configuring a database of Oracle type, you need to manually place the relevant ojdbc driver package (recommended version is ojdbc14-10.2.0.4.0. jar) in the %SuperMap iServer_HOME%\webapps\iserver\WEB-INF\lib directory.

4. After the configuration information is stored in the database, it is recommended to switch the storage of its security information to the database to avoid other The iServer encountered a security permission conflict when sharing the service configuration. At the same time, if an iServer needs to share from other iServers (hereinafter referred to as iServer1), The configuration information stored in the database, except that the configuration information needs to be switched to the configuration information storage database of iServer1. You also need to switch security info storage to the database of iServer1 security info storage. For specific security information storage settings, please refer to Secure Information Storage

5. When you need to use the same service configuration information stored in the database to enable multiple iServer nodes or use the service configuration information of an old version of iServer to enable a new iServer, you need to ensure that the token shared key used by the new iServer is consistent with that of the old version of iServer. Log in to the Service Manager and access the "Security">"Security Config" page to view or modify the current Token shared key. You can also view and modify it in the system configuration file iserver-system.xml. For details, please refer to: Setting the Shared Key for Token.

Here, take PostgreSQL as an example to illustrate the meaning of storage information in the database:

1. Metadata table

Metadata tables manage the basic information of service storage tables in the form of key-value pairs.

Table name: iserver_v1_metainfos.

Field structure:

Table 3 Metadata Field Structure and Description

Field (key) Description:

service.table.name: The table name of the service storage table.

spaceversion: The version of the service storage table. Different versions of the service storage table have different table structures.

Primary key: None.

For example:

Table 4 Metadata Table Information Example

2. Service storage table

The service storage table is used to centrally manage configuration information such as service providers, components, provider sets, component sets, and interfaces.

Table name: defined by the user; the default is iserver_v1_services.

Field structure:

Table 5 Field Structure of Service Storage Table

Field description:

name: Name of service providers, component, interface, provider collection, component collection.

type: Type of service configuration. Provider, provider set, component, component set, and interface correspond to Provider, ProviderSet, Component, ComponentSet, and Interface respectively.

setting: Specific content of service configuration

timestamp: The time when the service configuration information was updated to the database.

enabled: The available relationship between the provider and the component. The remaining service configuration types are true by default.

extend: Extend content

Primary keys: name and type

For example:

Table 6 Example of Service Storage Table Information

Notice

All table names, field names, table structures, and examples in the previous text are based on PostgreSQL database, with slight differences in Oracle database. The differences are as follows:

1. All table names and field names in Oracle are capitalized. For example, the table name of the metadata table is ISERVER_V1_METAINFOS

2. The data types of fields in Oracle are different from those in PostgreSQL. PostgreSQL uses varchar and text data types corresponding to Oracle's varchar2 and clog.

3. Oracle configuration information does not need to set the schema name.

Message Middleware Setting (obsolete)

SuperMap iServer supports the integration of message middleware, enables shared service configuration and status among multiple machines, and can precisely control the number of service instances to achieve dynamic scaling of services across multiple machines. The currently supported message middleware is RabbitMQ. Before connecting to the message middleware, please ensure that you have installed RabbitMQ. If not, please refer to RabbitMQ Installation and Configuration. You can access message middleware through the old version iServer Service Manager in the "Global Settings" section, which requires a restart to take effect.

• Supported middleware types: 【Required】 The supported middleware type is RabbitMQ.
• Service address: 【Required】 Set the available RabbitMQ Server message server. The default is localhost:5672. If your RabbitMQ Server and GIS Server are deployed in different servers, you need to fill in the specific IP address or domain name, such as 192.168.17.2:5672.
• Username: 【Required】 Username of the owner of the messaging server expected to have remote access to RabbitMQ Server.
• Password: 【Required】 The password of the owner of the messaging server expected to have remote access to RabbitMQ Server.

Note

1. RabbitMQ Server defaults to creating a user named guest with the role of administrator, who has all the permissions of RabbitMQ. For security reasons, guest users can only log in and use through localhost. If you need to remotely connect to RabbitMQ Server, it is recommended that you create your own user, set a password, grant permissions, and set a role for them, such as administrator. For specific configuration, please refer to RabbitMQ Installation and Configuration.

2. When setting message-oriented middleware, please pay attention to the prompt information on the interface. For example, if the prompt "Message-oriented middleware connection failed, please check whether the connection info is abnormal", please check the connection info according to the prompt.

Repository Setting

SuperMap iServer supports storing temporary resources in local files, databases, and setting survival time thresholds. To set temporary file storage in the configuration file, please refer to the storage and lifecycle of temporary resources. For supported temporary resources, please refer to the list of temporary resources. Here we will introduce how to set up temporary resource storage configuration in the iServer global settings page. Storage and Life Cycle of Temporary Resources. For supported temporary resources, refer to the list of temporary resources. Here's how you can use the Set the temporary resource storage configuration in the iServer global settings page.

Table 7 Repository Storage Parameter Description

Dynamic Management of Service Instances Setting

SuperMap iServer Standard, Advanced, and Ultra provide dynamic management of service instances, so that when the stock of GIS services reaches thousands of orders of magnitude, iServer can still start quickly, service publishing, access and management are smooth, and the use of resources is more intensive.

• Enable the Dynamic Management of Service Instances: The default is off. When turned on, all GIS service instance is in dynamic management status, that is, the service is initialized with delay, destroyed actively when it is idle, and controlled by the maximum number of service instances. At this time, the newly published service will also be in the dynamic management state.

• Service Instances Status Patrol Interval: The interval between checking whether a service instance is idle, measured in milliseconds, with a default value of 30000 milliseconds. The smaller the value, the more frequent the inspections and the more precise the service's automatic destruction behavior, but at the same time, it also consumes more computer resources.

• Idle Services Actively Destroy Time: When a service instance is detected to be in an idle state and the idle time exceeds the threshold, it will be automatically destroyed. The unit of this parameter is millisecond, and the default value is 300000 milliseconds.

• The Maximum Number of Online Service Instances: The maximum number of simultaneous online service instances is allowed. The default value I 2000. When the number of simultaneous online services exceeds the threshold and a new GIS service is requested to be accessed, the service will not be started, and the iServer will report an error.

If you need to enable dynamic management of service instances through a configuration file, you need to add the <serviceInstanceManager> element configuration parameter in the 【SuperMap iServer installation directory】\webapps\iserver\WEB-INF\iserver-system.xml file. For specific methods, please refer to the Service Instance Dynamic Management Parameter Configuration for details.

Note: The dynamic management of service instances setting needs to be saved and restarted iServer before it takes effect.

After the enable the dynamic management of service instances function, except the iServer tool services, such as data catalog services, machine learning service, processing automation services, web printing service, etc. Certain service instances are individually set by the you can also to not delay initialization. That is, as iServer starts, these service instances will immediately initialize and start..

You can select services that do not require delayed initialization on the iServer service management page and click the "Close Dynamic Management" button to cancel the delayed initialization of the service. You can also configure the components corresponding to service instances that do not require delayed initialization in the 【SuperMap iServer installation directory】\webapps\iserver\WEB-INF\iserver-services.xml file. For specific instructions, please refer to the Enable Dynamic Management Service Component Configuration.

File Management Settings

SupeMap iServer provides the file management settings function, which is used to limit the file management root directory and support configuration, prevent the risk of exposing absolute paths and directory traversal, and improve system security. You can set the file management root directory on the service management Home Page‐>Advanced ‐> Global Settings ‐ > File Management Settings tab. That is, the file root directory where the system can browse and upload data. If you do not set it, the file browsing range is not limited by default.

 Note: This setting needs to be saved and restarted IServer before it takes effect.

If you need to set the file management root directory through a configuration file, you need to configure the <fileManagerWorkDir> parameter in the 【SuperMap iServer installation directory】\webapps\iserver\WEB-INF\iserver-system.xml file. For specific methods and precautions, please refer to: File Management Root Directory Configuration.