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.
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.
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.
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.
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.
It is required to configure workflow emails beforehand in order to be able to implement workflow email notifications. See Configuration for more information.
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.
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.
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.
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).
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.
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.
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.
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®.
The home page requires the ebx-hub war to be deployed. It won't be available if the latter is not deployed.
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.
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.
To bypass log reconfiguration, remove ebx.log4j.rootCategory and all ebx.log4j.category.* properties from the ebx.properties file.