Other Administration

Demantra provides a Web-based interface to perform other, less common administrative tasks, described here.

This chapter covers the following topics:

• Other Web-based Administration Tools
• Logging Messages of the Application Server
• Managing Level Caching
• Viewing and Modifying Cache Properties
• Changing the Default User Interface Settings

Other Web-based Administration Tools

Browse to the following case-sensitive URL:

http://server name/virtual directory/admin

For example:

http://frodo/demantra/admin

The Login Page will prompt for a user name and password. After submitting the correct information, the following page will appear:

Ignore options 1, 2, and 3, which are currently non functional.

Logging Messages of the Application Server

By default, the Application Server writes logs into the directory Demantra_root/Collaborator/virtual_directory/portal/logs. These logs record activity of the server and clients.

To change the behavior of this logging, edit the file Demantra_root/Collaborator/virtual_directory/portal/conf/logconf.lcf. In this file, you can specify items such as the following:

• Name and location of the log file

• Maximum size of the log file

• Number of log files to keep

• Information on user login/logout events

For details, see the comments in Demantra_root/Collaborator/virtual_directory/portal/conf/logconf.lcf.

Important: If the default language uses a non-ASCII character set (such as Korean, Japanese, Chinese, Russian) then the text editor for viewing server log files must support the UTF-8 character set. Otherwise the text may not display correctly.

collaborator.login.user

This parameter is set in the logconf.lcf file. Users can turn on this log category and the following information will print out to the collaborator.log file:

• date/time : User “username” logged in, “number” users online."

• date/time : User “username” has been brutally logged out, “number” users online.

• date/time : User “username” logged out, “number” users online.

Managing Level Caching

Because caching is a trade-off between memory and speed, a new caching mechanism allows you to specify the needed caching policy on a level-by-level basis, depending on the size and usage patterns of your levels.

Specifying Level Caching Policies

To specify how to cache a given level, edit the group_tables_cache table, as follows:

Field	Purpose
GROUP_TABLE_ID	Specifies the ID of the level, as given in the group_tables table.
CACHE_CAPACITY	If CACHE_TYPE is LRU, CACHE_CAPACITY specifies the maximum number of members of this level that will be cached at any time. This field is ignored when CACHE_TYPE is set to SIMPLE.
CACHE_IS_LAZY	Setting to control member auto load at server startup time or on demand. Default value is "0" "0" = at startup, cache is loaded on startup "1" = on demand, cache is not loaded on startup CACHE_TYPE and CACHE_CAPACITY work with CACHE_IS_LAZY to specify whether the cache for this level is completely loaded upon server startup: CACHE_TYPE = SIMPLE will hold all members CACHE_TYPE = LRU will load up to CACHE_CAPACITY members
CACHE_TYPE	Specifies the caching policy for this level. Use one of the following values: SIMPLE - The cache is unlimited for this level. Simple will hold all members in memory as long as the server is running. LRU - LRU will hold members in memory up to the limit set in CACHE_CAPACITY. Whenever the server loads a member beyond this limit of CACHE_CAPACITY, the least recently used member is flushed from memory.) The default value is SIMPLE.
CHE_LOAD_EXTRA_FROM	Used to filter startup initialization. See CACHE_LOAD_EXTRA_WHERE.
CACHE_LOAD_EXTRA_WHERE	Used to filter startup initialization. This field and CACHE_LOAD_EXTRA_FROM allow you to define SQL criteria for loading the cache. For example, if the implementation works mostly on current year promotions, then you can add the From part “promotion_dates” and to the Where part “promotion_dates.from_date > '1/1/2006'”. In this way, the cache will be initially loaded with promotions from 2006. This does not mean that the cache will be in any way limited to 2006 after its initial load.
ENABLE_STATISTICS	* Specifies whether the server should collect statistics on use of this cache. "0" = false; "1" = true
ENABLE_DEBUG	* Specifies whether the server should record information for possible use in debugging issues related to this cache. "0" = false; "1" = true
* Can be changed later through a Web-based interface.

By default, Demantra uses the following caching policy for each level:

• CACHE_TYPE is SIMPLE (meaning that CACHE_CAPACITY is ignored)

• CACHE_IS_LAZY is "0" = false

• ENABLE_STATISTICS is "0" = false

• ENABLE_DEBUG is "0" = false

Recommended Settings

Any level with more than 10,000 members should be cached. When levels contain 10,000 or more members, system memory may be consumed rapidly and performance significantly affected, especially when retrieving worksheets and data. Therefore, it is recommended that implementations with 10,000 or more members do the following:

• Set CACHE_IS_LAZY to '0'.

• Set CACHE_TYPE to 'LRU'.

• Set CACHE_CAPACITY to the desired number of members to cache per level (i.e. the count of rows returned by CACHE_LOAD_EXTRA_WHERE + delta, where delta is the number of expected future members that will be loaded).

• If it is not possible to predefine the range of level members using CACHE_LOAD_EXTRA_WHERE, then set CACHE_CAPACITY to a value less than 10,000.

• Define CACHE_LOAD_EXTRA_WHERE and CACHE_LOAD_EXTRA_FROM. This will enable level members to be cached in memory when the application server starts up, rather than retrieving them from the database.

Refreshing the Cache for Specific Levels

It is possible to update a level member definition and not immediately see the changes. For example, if a user modifies a level member's description, and saves the changes, the old description could still display with the updated member in the worksheet.

The following procedure causes the level member cache to automatically refresh.

1. Manually add the REFRESH_FLAG column to a level table. For example, to update the level cache for the "settlement" table, enter the following command:

   ALTER TABLE SETTLEMENT ADD REFRESH_FLAG NUMBER(10) DEFAULT 0 NOT NULL;

   Note: The REFRESH_FLAG determines whether the level cache will be refreshed or not.

   • Value 0 - the data was not modified and cache refresh is not needed.

   • Value 1 - the data was modified and cache refresh is needed.

2. Create a workflow that runs CustomLevelMemberRefreshStep, or add a Custom Step to an existing workflow that runs CustomLevelMemberRefreshStep. This custom process must set the REFRESH_FLAG column to 1. When executed, this step will then refresh the specified level cache.

3. In the Class Name field for the Custom Step enter the following: com.demantra.workflow.step.CustomLevelMemberRefreshStep

4. In the Parameters section, enter the following:

   Name	Value
   user_id	The user's ID. For example, the user ID for the user 'dm' is 387.
   level_id	The level's ID. This the value of GROUP_TABLE_ID from GROUP_TABLES.
   reset_flag	Enter 'true' to reset the REFRESH_FLAG column (i.e. set it back to 0) in the level's table. Otherwise, set it to 'false'. (If the value remains at 1, then a refresh cache is performed when the workflow step is called).

Note: In the screenshot below, "566" is the GROUP_TABLE_ID value for the SETTLEMENT table

Viewing and Modifying Cache Properties

1. Browse to the following case-sensitive URL:

   http://server name/virtual directory/admin

   For example:

   http://frodo/demantra/admin

2. Click Cache Manager.

   A page like the following appears.

   

   This page lists each level in your system, along with the CACHE_TYPE setting for that level.

3. Click a level.

   A page like the following appears.

   

   This screen shows the following details:

   Level ID	Internal Demantra identifier for the level.
   Lazy	Indicates whether the cache for this level is completely loaded upon server startup. If true, the cache is not loaded on startup.
   Size	Indicates the maximum number of members in the cache.
   Statistics	Specifies whether the server should collect statistics on use of this cache. Click the true/false link to change this setting.
   Debug	Specifies whether the server should record information for possible use in debugging issues related to this cache. Click the true/false link to change this setting.
   Capacity	Specifies the maximum number of members of this level that the cache can include. You can enter a new value and click Update to save the new value. This option is shown only if the CACHE_TYPE is LRU.
   Memory Size	Click the Calculate button to see how much memory this cache is currently using.

Changing the Default User Interface Settings

The UI_Definitions.properties file contains the user interface settings that are used by default in Oracle Demantra 12.2 and later. The Classic_UI_Definitions.properties file contains the user interface settings for previous versions of Oracle Demantra.

These files are located in Install_Dir\Collaborator\demantra\conf and control:

• Background and foreground colors

• Text fonts

• Font sizes

To revert to the look and feel of previous versions of Demantra

1. Backup the UI_Definitions.properties file.

2. Rename the Classic_UI_Definitions.properties file to UI_Definitions.properties.

3. Restart the server.