Reporting Server > Server Workspace Manager > Configuring Workspace Manager

Configuring Workspace Manager

Topics:

The Workspace Manager is the component of the Reporting Server that is responsible for managing all server administrative tasks. These tasks, generally performed by Server Administrators, include monitoring server activity, configuring and adjusting the server configuration profile, enabling and creating services, defining deferred execution characteristics, and enabling and disabling email alerts.

The Server Administrator responsible for the installation, configuration, security, and maintenance of the server uses the Web Console to manage and configure the Workspace Manager in order to keep the server available to clients and running at peak efficiency. To use the Web Console, open Internet Explorer and navigate to the HTTP port on the host machine where the Server is running, as in http://host:http_port.

Your Server must be running in order to use Web Console to access the Workspace Manager.

Tip: This chapter references a number of Workspace related keywords. Within the help system, you can access detailed information about these keywords by clicking the keyword links in this document. You can also click the question mark (?) icon next to parameters on the Workspace configuration panes.

Workspace Manager Configuration Privileges

How to:

x

Access to the administrative features of the Web Console can be restricted by defining a list of users with admin privileges and storing the list in a release-independent file called admin.cfg. This file is located, by default, in .../ibi/profiles.

The list of users and user roles defined in admin.cfg defines a list of administrators and users that can be used for authorization and/or authentication according to established security. Administrators are responsible for installing, configuring, and maintaining the Server with varying degrees of responsibility, depending on their administration levels (SRV, APP, OPR). At least one administrator must be defined in the list, although most sites identify other persons to act as backups.

For example, a Server Administrator (SRV) can perform all the administrative tasks available through Web Console operations. If more than one Server Administrator is defined, the first valid member on the list is used to impersonate FOCUS Database Server (FDS) and other special services. An Application Administrator (APP) is limited to the administrative tasks that do not require changing configuration or restarting the server. Both Server Administrators and Application Administrators can edit user profiles in the user.prf file. However, Server Administrators can edit all user.prf files, while Application Administrators can only edit their own profiles.

Any IDs (beyond the original ID used to configure the server) that are used for server or application administration require read/write privileges to the respective locations that the IDs are expected to manage. To assign these privileges, you must establish group rights for the locations at the operating system level.

Configuration actions depend on privileges. For example, Resource Management procedures are available to users with privilege RARGP.

The Server Actions menu on the Workspace Manager ribbon has options to stop the server, restart the server, and quiesce the server.

Stop Server

A server administrator can stop the server. Existing connections are terminated.

Restart Server

A server administrator can restart the server. Existing connections are terminated, and new connections will be rejected until the server restarts.

Quiesce/Enable Server

A server administrator can change the server state to quiesce to disable new connections. Existing connections are not terminated, but will finish processing and disconnect, while new connections will be rejected. A server administrator can still connect to the server. This is done to gradually move the server to the state where maintenance can be performed safely or to collect diagnostic information. It can also be used as the first step before stopping the server without terminating any connections.

A server administrator can enter a custom message that will be displayed for a new user connection when the server is in Quiesce mode.

Procedure: How to Quiesce the Server and Set a Custom Message

Only a server administrator can change the server state. To Quiesce the server, and define a custom message that will be delivered from the server:

  1. From the Server Actions menu on the ribbon, click Quiesce/Enable.

    The Quiesce Connections page opens.

  2. If you want to deliver a message for new user connections, enter it in the quiesce_msg field.
  3. Click Submit.

    You will be asked if you want to disable new connections.

  4. Click OK.

Note: To restore the server to normal operation, click Quiesce/Enable, and select Enable New Connections.

Configuring an Agent Service

How to:

Reference:

A server configuration requires at least one agent service with the name DEFAULT, defined by a SERVICE block. An agent service is an entity used to define the parameters for a group of data access agents, so that a configuration can manage different groups of data access agents for different purposes. Each data access agent runs for a specific Data Service, and each service may have different values for the settings defined on the services configuration panes. These settings include:

  • The maximum number of data access agents and the number of agents prestarted at server startup for a service, as defined by maximum and number ready.
  • The lifetime of the agents of a server, which can be limited through idle agent limit, CPU time limit, and/or memory limit.
  • Incoming connections for which there is no available data access agent. These can be put in a queue for the service (configured using maximum_q and queue limit), and after they are connected, their idle time can be limited using idle session limit.
  • The deployment mode of a service, which defines how data access agents are assigned to connections.

Procedure: How to View or Edit Data Service Properties

The service agents are available from the Workspace resources tree.

  1. From the sidebar, select Workspace.
  2. In the resources tree, open Data Services.
  3. Right-click a Data Service and select Properties.

The properties page for the particular Data Service opens.

Reference: Data Service Properties

The server includes four predefined Data Services:

  • DEFAULT
  • WC_DEFAULT
  • SCHED_DEFAULT
  • DFM_DEFAULT

The following image shows the parameters for the DEFAULT service.

Note: Changing values with an asterisk (*) requires restarting the server.

Data Services have the following parameters:

service

Defines the name of the service.

maximum

Defines the maximum number of data access agents that the Workspace Manager will allow to run simultaneously for a specific service.

number_ready

Defines the number of data access agents that the Workspace Manager will create at startup for a specific service.

deployment*

Controls resource sharing between users who are connecting to the same agent in this service. The values are:

  • private deployment. All users are completely independent of each other and have their unique operating system rights, database connections, and FOCUS language settings.
  • connection_pooling. All users are partially independent by having their own unique FOCUS language settings but sharing operating system rights and database connections.
Queuing*

Controls whether queuing is on or off.

maximum_q

Defines the maximum number of connections that could be queued for a specific service. Only available when queuing is set to on. Set to -1 for an unlimited queue size.

queue_limit

Defines the amount of time in seconds a queued connection will wait before being timed out if an agent is still unavailable. A setting of -1 mean unlimited.

idle_session_limit

Defines the time limit in seconds that connected agents will wait for client input before they are disconnected. A setting of -1 mean unlimited.

idle_agent_limit

Defines the time limit in seconds that disconnected agents in excess of number_ready can stay idle before they are killed. A setting of -1 mean unlimited.

profile*

Specifies a focexec file that will be executed during agent startup.

cpu_limit

Defines the amount of CPU time in seconds an agent is allowed to use before being killed by the Workspace Manager.

memory_limit

Defines the maximum amount of memory in kilobytes an agent is allowed to use. If an agent process grows above this limit, it will be killed by the Workspace Manager.

disk_limit

Defines the maximum amount of disk space in kilobytes an agent is allowed to use. This would add sizes of all files in agent edatemp directory, such as FOCSORT, HOLD files and other temporary files created by requests. If an agent process grows above this limit, it will be killed by the Workspace Manager.

connection_limit

Defines the time limit in seconds allowed for connection. When it is exceeded, the connection will be terminated, and the agent serving this connection will be stopped. The limit will be triggered after the current edachkup_interval expires.

The edachkup_interval is an internal parameter that defines the time interval for the Workspace Manager checkup cycle. Data service level limit parameters such as connection_limit, idle_agent_limit, cpu_limit, and disk_limit take effect the next time edachkup_interval wakes up (by default, every 60 seconds).

max_connections_per_user*

Restricts the number of concurrent connections for the same userid for a specific service. When a user exceeds the maximum number allowed, additional connections requested by that user are rejected, and the server displays the message 

Connection refused due to the max_connections_per_user (n) 
being exceeded

where n is the number of allowed connections.

You have the option to queue user connections that are refused by the server, using the queue_max_user_conns property on the Data Service Properties page. That option is available only if the Queuing property for the Data Service is On.

queue_max_user_conns

Enables queuing of concurrent connections for the same userid for a specific service in excess of max_connections_per_user. This setting allows new connections that would otherwise be rejected to be queued for later processing. Only available when queuing is set to on.

agent_refresh

Defines the maximum number of new connections which can be accepted during the life of each agent process. Beyond this limit, additional new connections will be assigned to a fresh agent. Agent processes which have reached the limit will be terminated when the last accepted session disconnects.

sched_priority

Defines the scheduling priority of each agent process running under the specified service entry. The scheduling priority of a process defines how the operating system scheduler treats the process after it gains control of the CPU, and should be set according to the relative importance of the work being done by the service. Values range from -20 (highest priority) to 20 (lowest priority).

Reference: How the Reporting Server Maintains the Number of Available Agents

The Reporting Server maintains the number of available agents using the number_ready parameter.

  • The number_ready parameter will determine how many agents are started when the Reporting Server starts. However, it does not guarantee that the number of active agents will not fall below that value. The number of agents may be lower if agents crash or are stopped unexpectedly. Even if the number of active agents is lower than the number_ready parameter, more will be started as needed, up to the number allowed by the Maximum parameter.
  • If there are active agents that are idle, and that number exceeds number_ready, agents will be stopped once they exceed the idle_agent_limit until the number of active agents equals the number_ready.

Configuring Deployment Modes

How to:

The deployment mode of a service defines how data access agents are assigned to connections:

  • In private deployment, a dedicated application agent is assigned for each connection request. Private deployment retains the behavior of all prior server releases. At connect time, global, as well as user and service level profiles, are executed. At disconnect time, all temporary files are removed and database connections are closed. The privileges of each application agent depend on the security mode of the server.

    With security set to a value other than OFF, authentication is processed for every client logging on to the server. With security OFF, user identification and authentication are not required. The effective user ID becomes the connecting user for the duration of the session.

  • In connection_pooled deployment, the global profile and service profiles are executed when an agent is started, and pooled user profiles are executed on each connection. The WebFOCUS context is cleared once the session is established for a new connection, and then the pooled user profile is executed.

    With security set to a value other than OFF, all users have the same rights because the effective pooled user is unique, regardless of the connecting user.

    Connection pooled deployment provides significant performance advantages and is recommended when a large number of users share the same operating system and DBMS credentials. It cannot be used when each connecting user has specific operating system and DBMS rights, nor can it be used for the service DEFAULT with the server security mode set to DBMS because, in this situation, the profile is disabled for connection authentication.

Procedure: How to Set the Server Deployment Parameter in a Server Profile

To set the server configuration parameter deployment:

  1. From the sidebar, click Workspace.
  2. In the resources tree, right-click the Data Services folder, and click New.

    The New Data Service page opens.

    Tip: For an existing service (for example, DEFAULT, WC_DEFAULT, DMC_DEFAULT, DEFAULT_CPOOL), right-click the service and click Properties to open the Services pane.

  3. In the deployment field, choose private or connection_pooling.
    • With private deployment, all profiles are executed on connection. On disconnect, all DBMS connections are dropped. This is the default value.

      With security set to a value other than OFF, the effective user ID is switched to the connecting user for the duration of the connection.

      Skip to step 6.

    • With connection-pooled deployment, the global profile and service profiles are executed when an agent is started, and pooled user profiles are executed on each connection. The WebFOCUS context is cleared once the session is established for a new connection, and then the pooled user profile is executed.

      When you select this option, pooled_user and pooled_password are displayed.

      With security set to a value other than OFF, all users have the same rights because the effective user is unique (configured using pooled_user and pooled_password) regardless of the connecting user.

      Continue with steps 4 and 5.

  4. Select pooled user from the drop-down list. (This list is populated from the admin.cfg file described in Configuring Workspace Manager.)

    This service level keyword is required for connection_pooling deployment with security mode OPSYS. It defines the user ID under which all agents will run. The DBMS user IDs are determined by the connection setting type.

  5. Enter the corresponding password. Note that pooled password is only required for connection_pooling deployment on Windows operating systems.
  6. Click Save.

WebFOCUS

Feedback