Page tree
Skip to end of metadata
Go to start of metadata

This BOpedia page is provided by the RIG team. Don't hesitate to put comments.

Product versions:
BusinessObjects Enterprise XI R2
BusinessObjects Enterprise XI 3.0
BusinessObjects Enterprise XI 3.1




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.

  • 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.
    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.

Virtual tables

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

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

Folder 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.

Root folders

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.


  1. Unknown User (10310a58n)

    What is the "repository master" CMS browsing tool you have (in a screenshot) above?  Does it come with BOE?

  2. Unknown User (1024a4afp)


    Where are user rights set. I want to retrieve user groups with view rights over 1 report and a group of reports?. 

  3. Hi Hansen. 

    Thx. Nice detailed info. How about the behaviour in BI 4.0 ?

    Hope it is the same. 



  4. Unknown User (it60ub5)

    Hi Hansen

    It is a nice article!

    How can we fetch Report Tab Columns of a Web intelligence document?


  5. Unknown User (it60ub5)

    Hi Hansen

    It is a nice article!

    How can we fetch Report Tab Columns of a Web intelligence document?


  6. Former Member

    I am seeing duplicate copy of the CMS tables discussed aforesaid under Master database and they seem to be growing like the original CMS tables.

    I tried to delete these tables manually and they re-appear. I also found that the tables are created by sa account under Master DB.

    Any suggestions to remove this duplicate copy of tables under Master database will be greatly appreciated.

  7. Former Member

    What is the Repository Browser in the image above ?

  8. Repository Master / Browser screenshot removed as this is a DEV solution and SAP Internal only.. In the roadmap of BI4.2 there is the plan to deliver a ODBC driver against the CMS database to further enhance the capabilities for retrieving information stored in the CMS database.

  9. Thanks! Nice article to understand the CMS repository.

  10. Former Member

    Hi Everyone,

    Recently i am facing one issue and need all your help and suggestion on this.I have around 1000 reports and I need to get all the tables which are used by this 1000 reports. I don’t want to go each and every report to get the table details but want to prepare on query and execute it in query builder to get the details.Is there any way to make this query and execute the same in Query builder to retrieve all the tables at one go.

  11. Hi Souma,


    there is no option within the CMS to gain this insight.. the CMS it self does't record the objects used within a report (nor the SQL).. unless you have enabled Audit with the setting to record the universes/objects/SQL you can use the Audit database to gain this insights..

    without Auditor, you will have to consider 3rd party solutions like 360Eyes from GB&SMITH :

    hope this helps



  12. additionally, for all whom want to get insights, check out the blog post series on the Query Builder by Manikandan Elumalai

  13. Former Member

    Hi Souma Muk,


    We need to use RESTFULL WebServices to get the table level details for all the reports.