Customization of the censhare system is mostly accomplished in the censhare Admin Client. Find access to the database tables of the master data and to the XML configuration files. Make use of a rich set of monitoring tools and a frontend for the customization of software distribution.

Starting the censhare Admin-Client

After launching the application, the login procedure to the censhare server is the same as for the censhare Client. It is possible to log into the offline mode, but there is no use for this mode of operation, except to edit the host settings. It is necessary to have administrative permissions to log in with the Admin-Client. The main customization groups of the Admin-client can individually be assigned with readonly- and/or write-permissions. Domain-specific configurations are taken into account to allow the definition of client-based sub-administrators.

Introduction

Most of the customization information of the censhare system is stored in XML configuration files on the Application Server(s). There are literally several hundreds of those files, some containing a single parameter, others having the complexity of programming languages (for example, widget-based user interface design or XSL-FO-automization). The configuration files control, among many other tasks, the activation of system modules, the configuration of interfaces, the design of the user interface, the behaviour of special features and language localization.

The configuration files are kept in a folder hierarchy that groups the files in logical context. The files are (with few exceptions) not accessed directly on the file system, but in the Modules section of the censhare Admin client. This client will make sure, that each modification to one of the configuration files will produce a customized copy of that file in a dedicated environment. This procedure allows you to rollback to the original configuration in case of errors and provides a comfortable way to takeover customization efforts into upgraded system versions.

Whenever possible, the XML configuration file not only contains its customization parameters but also its own graphical user interface description. This user interface is defined in censhare’s own GUI language (the XML editor metalanguage), which can be parsed by the censhare Adminclient and allows the administrator to edit the configuration files in classical screen forms, rather than the XML source. Only very complex configuration files have to be edited in their XML source code.

Overview

  1. The toolbar contains buttons for the export of Master data, the Server Action popup menu, the configuration update buttons and a refresh button.

  2. The list of configurations groups gives access to all customization features.

  3. The status bar shows the connected censhare Application Server and user.

Configurations

Because of the large number of default configuration files (there are currently between 350 and 400), the files are organized in a hierarchical folder structure within the censhare Adminclient (and accordingly in the physical filesystem of the censhare ApplicationServer).

There are three folders on the top level of the hierarchy as follows:

  • Server: this folder contains only two default configuration files (which contain a customized version each). These two files contain basic parameters for the configuration of the ApplicationServer, like mandatory services, Java Virtual Machine properties, timeouts, supported system languages and the like. Changes in these two configuration files require a restart of the ApplicationServer to take effect. These two files should be handled with the utmost care, as misconfiguration can lead to performance loss or complete failure of the system. The server configuration is set up during the installation of the system and optimized for the server hardware. It is not required to change these settings in normal operation.

  • Services: each of the system services comes with its own configuration file. Changes in these configuration files usually require a restart of the ApplicationServer to take effect (unless stated otherwise in the internal documentation of the service). All services are configured in the course of the system installation and usually require no changes in normal operation.

  • Modules: this folder contains the bulk of the configuration files, arranged in a topical, hierarchical structure. Changes of configuration files in this tree can be activated during normal operations and do not require a restart of the ApplicationServer.

Configuration types

The censhare system distinguishes three major types of configuration files:

  • ServerActions: configuration files of this type activate and control censhare functionality that is triggered manually by users.

  • AutoExecute: configuration files of this type activate and control censhare functionality that is triggered automatically, either at certain times, in frequent intervals, by default system events or by customized system events. If such a functionality can run multiple instances, the configuration type is called AutoExecuteTemplate.

  • Preferences: configuration files of this type control censhare functionality that is continuously operated and not depending on any triggers.

Some functionality in the censhare system is implemented as ServerAction, as well as AutoExecute to allow manual and automatic triggering. In that case, both configuration files have the same name, but the AutoExecute version has an (automatic) suffix. Both versions can also be distinguished by their icons.

Built-in documentation

Due to the internal character of the configuration files and their large number, the documentation is included by the developers within the configuration files in two ways:

  • Each configuration file contains a description field in its header, that contains the filename and a brief description of its functionality (very old or obsolete customization files might be lacking a description). The description is also shown as a tooltip in the configuration file list.

  • The parameters within the customization file show tooltips with a short instruction and syntax hints.

Activation

Changes in the XML-based configuration files are not activated immediately. Instead, any modified configuration entry is marked with a red spot, that inherits up the folder hierarchy to the top level. Activation has to be triggered manually. On success, the red markers are removed. If more than one ApplicationServer is in use, it is also necessary to distribute the configuration to all of them in a second, separate step.