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. As well I will introduce some tools which may help you to browse the repository and troubleshoot related issues.
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.
The table contains the current version of BOE.
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.
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.
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.
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.
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.
The metadata is stored in the form of InfoObject, and the CMS server reads the InfoObjects from the virtual tables. There are three virtual tables:
• InfoObjects table (CI_InfoObjectS)
• App Objects table (CI_APPOBJECTS)
• System Objects table (CI_SYSTEMOBJECTS)
Virtual tables are typically just called "Tables". Below is the decription of these tables:
- InfoObjects table
Contains InfoObjects that are viewed by the end user. Including: report documents, programs, shortcuts, folders, categories, inboxes.
- App Objects table
Contains InfoObjects that are not documents but are used by documents. For example: universes, connections, and overloads.
- System Objects table
Contains InfoObjects that the BI Platform uses in order to function. For example: users, groups, and license keys.
Tools to browse CMS repository
There is tools to view the virtual tables called Query builder
Query Builder is a UI that lets you enter queries and send to the CMS. It returns the results in a UI table format. To use the feature, run "http://localhost:8080/AdminTools/" on a web browser.
The query is like ordinary sql query, see the following example:
Select SI_ID, SI_NAME from CI_INFOOBJECTS where SI_KIND='Webi'
The queries which users input can be flexible, with given the columns for the search, it is very efficient to search and navigate.
Below are screenshots of Query Builder:
The query input page
The query output page
Relationship of InfoObjects
There are some terms which you need to understand when you view the CMS repostory with the tools mentioned above.
Based on the relationships, the InfoObjects are organized into hierarchies. There are three hierarchies:
- folder hierarchy
- usergroup hierarchy
- server/servergroup hierarchy
The folder hierarchy is one of the primary ways that the CMS and client applications navigate through InfoObjects. Folder hierarchies are flat lists constructed using an InfoObject's parent. All InfoObjects have one, and only one, parent as defined in the property SI_PARENTID. For example, if there is a document with SI_PARENTID 134, you should be able to find a folder with SI_ID 134, and the folder with SI_ID 134 is the parent of the document with SI_PARENTID 134.
The folder hierarchy is virtual. It is constructed by the CMS using the parent ID property. The hierarchy does not correspond to how InfoObject records are stored in the repository.
The top folder in the CMS Repository hierarchy is the CMS Cluster InfoObject (Object 4). Root folders are folder InfoObjects that live directly under the CMS Cluster folder.
Root Folders are virtual and do not correspond to anything on the file system.
Here we have some examples of root folders:
• Root folder(Folder 23) is the top-level folder for all the documents
• Plugins (Folder 25) Contains subfolders for each plugin type. All plugins must live under the appropriate child folder under this root folder.
• Users (Folder 18) Contains the Favorites folder for each user. A user's favorites folder contains objects placed there by the user, such as copies of reports or shortcuts.
• Temporary Storage (Folder 49) Stores copies of objects such as reports and files that are cleaned up automatically when the user's session terminates.
InfoObjects are organized into root folders to make it easier for the CMS and client applications to find them. Client applications can navigate through the collection of InfoObjects by starting with an InfoObject's root folder, then using the parent ID property and children ID properties. Similar types of InfoObjects are typically places under the same root folder. With Query Builder, we can use SI_ParentID as keyword to search the InfoObjects when we want to find the objects which are in the given folder.
With the relationship knowledge, we can understand problem if inconsistency occurs. For example, if a document's SI_ParentID is 2333, but there is not a folder with SI_ID 2333, then the document is orphaned. There is a tool call Repository Diagnostic tool (RDT) which can be used to identify and fix some of inconsistencies.
For each document, as the actual file is stored in FRS, the link information is in the InfoObject. We can view it from the properties SI_FILE1 and SI_PATH. For example, if the SI_FILE1 value is ab435.vkn.jiraqxwyoqrte.wid, and the SI_PATH value is frs://Input/s_084/005/000/1354, then we will find the .wid file at the corresponding position on the FRS. If there is inconsistency(i.e. there is not file at the given path), then we can use RDT to detect it.
Below are some other important properties for each InfoObject:
- SI_NAME: the name of the object,
- SI_KIND: the kind of object, e.g. Folder, Webi
- SI_OWNER: the user name of the owner
- SI_OWNERID: the user ID of the owner
- SI_CHILDREN: the number of children
- SI_CUID: CUIDs are Cluster Unique Identifiers that uniquely identify an InfoObject, within a given cluster and also identify replicas or copies of an object across multiple CMS clusters. Because CUIDs are moderately lengthy strings they are less efficient to use and slower to query for.
- SI_UNIVERSE: the universes used by the document, there might be multiple universes used in one document, you may see a list of universes' SI_ID attached to the property.
From above diagram, we may see the InfoObjects relate to each other not only by folder hierarchy, they may have other relationships. For example, the SI_OWNERID is the property to identify the ownership from the user to the document.
Root folders and rights
An InfoObject inherits rights from the folder under which it lives. Also, rights that apply to "sibling" InfoObjects may apply to an InfoObject. Sibling InfoObjects are InfoObjects that live under the same root folder.
The root folder under which an InfoObject live will affect the rights that can be set on that InfoObject.
With a clear understanding on how the InfoObjects are organized in the CSM repository. Users should be able to use tools to browse the repository, and to troubleshoot inconsistencies related to CMS repositoy.