How to browse CMS repository

Overview

The CMS(Central Management Server) repository stores metatdata in the form of InfoObjects. As you know, all the contents of BOE(BusinessObjects Enterprise) system can be classified into two types: metadata and the actual file. For example, if there is a Crystal Report document in the BOE system, the metadata (including Report name, type, ID, CUID, path, etc.) is stored as an InfoObject in the CMS Repository. The Crystal Report document itself (i.e. the .rpt file) is stored as a file on the File Repositoy Server(FRS). In this article, I will describe the structure of CMS repository and how the metadata is organized.

CMS Repository Structure
The CMS metadata is physically stored on a database, but we browse the InfoObjects from virtual tables. To give a clear picture, let's begin with physical structure at the database level.

Physical Database Tables
There are 6 tables on the database level to store the metadata.
 CMS_VersionInfo
The table contains the current version of BOE.


 CMS_InfoObjects6
This is the main table in the repository. Each row in this table stores a single InfoObject. The table contains the following columns: ObjectID, ParentID, TypeID, OwnerID, Version, LastModifyTime, ScheduleStatus, NextRunTime, CRC, Properties, SI_GUID, SI_CUID, SIRUID, SI_INSTANCE_OBJECT, SI_PLUGIN_OBJECT, SI_TABLE, SI_HIDDEN_OBJECT, SI_NAMEDUSER, SI_RECURRING, SI_RUNNABLE_OBJECT, SI_PSS_SERVICE_ID, ObjName_TR, SI_KEYWORD, SI_KEYWORD_TR, LOV_KEY.


 CMS_Aliases6
This table maps the user alias(es) to the corresponding user ID. A user has an alias for each security domain in which they are members. For example, a user may have both a Win NT alias and an LDAP alias. Regardless of the number of aliases a user may have, in the BI Platform each user has only one user ID. The map is stored in a separate table to enable fast logins.


 CMS_IdNumbers6
The CMS uses this table to generate unique Object IDs and Type IDs. It has only two rows: an Object ID row and a Type ID row. The CMSs in a cluster use this table when generating unique ID numbers.
GUIDs, RUIDs and CUID are generated with an algorithm that does not use the database.


 CMS_Relationships6
Relationship tables are used to store the relations between InfoObjects. Each row in the table stores one edge in the relation. For example, the relation between a Web Intelligence document and a Universe would be stored in a row in the WebI - Universe Relation table. Each relationship table has these columns:
Parent Object ID,Child Object ID,Relationship InfoObject ID ( this Default InfoObject "DFO" describes the properties of the link between the two objects.), member, version, ordinal, data. Relationship tables are defined by default objects.


 CMS_LOCKS6
This is a auxiliary table of CMS_RELATIONS6

With above knowledge, we can answer some questions regarding the physical tables on database level:
• When doing a CMS database backup, which tables should be chosen on the database?
The answer is all the tables which we mentioned above. Besides the database, user should also make sure to backup the FRS.


• How to substitute the CMS database with another database?
As we know there are 6 tables storing the BOE metadata, we may create the same tables on the target database, and import data from the source CMS database. Besides, users should make sure that the CMS server point to the new target database when starting CMS server, to automate the process, use the CCM database copy function, below are the screenshots of the workflow:

Firtly, click the data source button;

Then choose to copy data.

................ next post,