Cloud Software Group, Inc. EBX®
Documentation > Administration Guide
Navigation mode Documentation > Administration Guide

# Administration overview

The Administration section in TIBCO EBX® is the main point of entry for all administration tasks. In this overview are listed all the topics that an administrator needs to master. Click on your topic of interest in order to access the corresponding chapter or paragraph in the documentation.

## Repository management

For storage optimization, it is recommended to maintain a repository (persistence RDBMS) to the necessary minimum. To this end, it is recommended to regularly perform a purge of snapshots and obsolete dataspaces and to consider using a backup file system.

See also Cleaning up dataspaces, snapshots, and history and Deleting dataspaces, snapshots, and history.

It is also possible to archive files of the file system type in order to reduce the storage costs, see EBX® monitoring.

Administration tasks can be scheduled by means of the task scheduler, using built-in tasks, see Task scheduler.

### Object cache

EBX® maintains an object cache in memory. The object cache size should be managed on a case by case basis according to specific needs and requirements (pre-load option and pre-validate on the reference dataspaces, points of reference, and monitoring), while continuously monitoring the repository health report.

##### See also

- Memory management

### Limitations

The following limitations apply to EBX®:The value for the G_DSP table's dsp_id column is limited to 2,147,483,648. This value increments with each dataspace creation and only decreases if the application restarts after a purge that removes the last created dataspaces. Up to 2,147,483,648 HomeKey instances can be created in a single JVM run. The value for the G_DST table's dst_id column is limited to 65,536. This value increments each time a dataset is created and persisted with a new dataset reference. A dataspace can have up to 8,192 datasets. For performance considerations, it is recommended not to exceed 32 datasets. A datamodel can declare up to 65,535 tables. For performance considerations, it is recommended not to exceed 256 tables.

### Obsolete contents

Keeping obsolete contents in the repository can lead to a slow server startup and slow responsiveness of the interface. It is strongly recommended to delete obsolete content.

For example: datasets referring to deleted data models or undeployed add-on modules. See Managing TIBCO EBX® add-ons.

### Workflow

#### Cleanup

The workflow history and associated execution data have to be cleaned up on a regular basis.

The workflow history stores information on completed workflows, their respective steps and contexts. This leads to an ever-growing database containing obsolete history and can thus lead to poor performance of the database if not purged periodically. See Workflow history for more information.

#### Email configuration

It is required to configure workflow emails beforehand in order to be able to implement workflow email notifications. See Configuration for more information.

## Disk space management

### Purge of logs

The log file size will vary according to the log level (and to the selected severity level) thus disk space needs to be accordingly managed.

#### EBX® main configuration file mechanism

An automatic purge is provided with EBX®, allowing to define how many days should log files be stored. After the defined period, log files are deleted.

Any customized management of the purge of logs (backup, archiving, etc.) is the administrator's responsibility.

See Custom 'ebxFile' appender for more information.

### XML audit trail (deprecated)

EBX® is provided with an XML audit trail manager, now disabled by default. Any customized management (including purge, backups, etc.) is the administrator's responsibility.

See Activating the legacy XML audit trail (deprecated) and Legacy XML Audit trail (deprecated) for more information.

## Data model

### Publication management

The management of publications of embedded data models. See Data model administration for more information on the management of these publications and the administration tasks that can be performed (delete, import and export).

### Refresh data models

It is possible to update the data models that are using XML Schema documents not managed by EBX®. See Data model refresh tool for more information.

## Data validation

### Resetting validation reports

Validation reports can be reset from the administration menu. It is possible to reset the validation reports of all the datasets contained in the repository or only those of the datasets selected in the tabular view. Therefore, the related datasets will be fully validated at the next explicit validation request.

See `Adaptation.resetValidationReport` for more information.

## Perspectives

EBX® offers extensive UI customization options. Simplified interfaces (Recommended perspectives) dedicated to each profile accessing the system can be parameterized by the administrator. According to the profile of the user logging in, the interface will offer more or less options and menus. This allows for a streamlined work environment.

See Advanced perspective for more information.

## Home page

EBX® offers a customizable home page, which can be accessed through the 'Perspective' menu, or directly using the `/ebx-hub` URL.

In its current state, the links that are displayed in this page open their target in a new tab. This behavior may change in a future version of EBX®.

##### Note

The home page requires the `ebx-hub` war to be deployed. It won't be available if the latter is not deployed.

## Log configuration

You can configure EBX® logs using Apache Log4j™ 2, the `ebx.properties` main configuration file, or a combination thereof.

EBX® log management relies heavily on Apache Log4j™ 2, which means logs can take advantage of the Log4j automatic configuration on initialization and automatic reconfiguration mechanisms. See Apache Log4j™ 2 configuration documentation and Configuring the EBX® logs for more detailed information on these mechanisms.

The `ebx.properties` main configuration file centralizes EBX® configuration properties. However, Apache Log4j™ 2 automatic configuration on initialization has precedence over this mechanism. Additionally, the web application server start up process makes the application initialization order unpredictable. Due to these factors, log messages might not be generated according to the configuration specified in the `ebx.properties` file. See Configuring the EBX® logs for more information.

### Order and combination of log mechanisms

On web application server start up, the Apache Log4j™ 2 automatic configuration executes first. Then during the web application initialization phase, the `ebx.properties` main configuration file is processed and logs are reconfigured. Reconfiguration entails replacing the entire configuration.

If the Apache Log4j™ 2 automatic reconfiguration mechanism is used, then logs may be reconfigured based on the Log4j configuration context at any time after the first initialization (that is before, or after the EBX® main configuration file is processed). If the `ebx.properties` file is updated, then logs may be reconfigured based on the file content at any time after the first processing.

Since the mechanisms are not exclusive, you can set the initial configuration using the Apache Log4j™ 2 automatic configuration on initialization and then replace it with the one from the `ebx.properties` file.

##### Note

To bypass log reconfiguration, remove ebx.log4j.rootCategory and all ebx.log4j.category.* properties from the `ebx.properties` file.

Documentation > Administration Guide