Business Objects Repository Basics

• One security domain
• Multiple document and universe domains allowed
• All domains may be located on a single database (monolithic)
• Document and universe domains may be located across different databases (distributed)

Key required to access the repository

• Can be located on the users workstation (LocData) or in ashared folder (ShData)
  

- Pdac.lsi or pdac.ssi defines personal connections to the database
- Sdac.lsi or Sdac.ssi defines shared connections to the database
- All other .lsi and .ssi files are user login files. These files contain the security
information needed to run Business Object when not connected to the repository

• Security domain maps actors to resources via resource links
  

-Actors can be a user or a group
-Resources include documents, universes and domains
- Access to a resource may be linked directly to the user or inherited from further up the security hierarchy

Read more »

Business Objects Repository Basics

• One security domain
• Multiple document and universe domains allowed
• All domains may be located on a single database (monolithic)
• Document and universe domains may be located across different databases (distributed)

Key required to access the repository

• Can be located on the users workstation (LocData) or in ashared folder (ShData)
  

- Pdac.lsi or pdac.ssi defines personal connections to the database
- Sdac.lsi or Sdac.ssi defines shared connections to the database
- All other .lsi and .ssi files are user login files. These files contain the security
information needed to run Business Object when not connected to the repository

• Security domain maps actors to resources via resource links
  

-Actors can be a user or a group
-Resources include documents, universes and domains
- Access to a resource may be linked directly to the user or inherited from further up the security hierarchy

Read more »

The Repository

The Default Repository Structure

The default Business Objects repository consists of three domains:

· Security Domain – Stores users, passwords, permissions, and connection information.
· Universe Domain– Stores universe structure (classes and objects)
· Document Domain– Stores documents and universe lists of values

There are several drawbacks to using the default repository structure provided by Business Objects:

· Universe lists of values and all document types share the same repository domain
· All three repository domains share the same database account
· There is no way to place two universes or documents with the same name in the repository for testing purposes

The Custom Repository

For the reasons listed in the previous section and for ease of maintenance, organization, and disaster recovery purposes, consider creating a custom repository with multiple domains.

The diagram below is a graphical representation of a sample new repository layout:

In the example, each Universe domain is in a separate schema with a separate default tablespace to eliminate the risk that an error will cascade and corrupt the entire repository. Universe domain schemas must also contain a Document domain. This Document domain is used to store custom lists of values.

There are four additional Document domains in four separate schemas with their own default tablespaces. These are used to store various types of documents.

The purpose of each repository domain is explained in detail below:

· BusinessObjects Security – This is the default security domain. For more information see above.
· Universe – This is the default universe domain. It is not currently being used in the example to store universes.
· Document – This is the default document domain. It is not currently being used in the example to store documents or lists of values.
· Production_Universe – Used to store Production universes.

· ProdLOV_DoNotUse – Used to store Production universe lists of values. It is named ‘_DoNotUse’ to discourage use for purposes other than the storage of universe lists of values. No user group has access to the domain and surprisingly enough, this does not prevent designers from being able to export custom lists of values nor does it prevent users from being able to import them.
· Test_Universe – Used to store Test universes or universes being staged from Test to Production. An additional Dev_Universe domain could be added.
· TestLOV_DoNotUse – Used to store Test universe lists of values. See above for a detailed explanation of the naming convention ‘_DoNotUse’. An additional DevLOV_DoNotUse could be added.
· Corporate Documents – Used to store Corporate Documents
· Secure_Documents – Used to store and separately secure documents accessed by selected customers (You many have as many document domains as necessary to secure or organize Business Objects reports).
· BO_User_Documents – Used to store documents mailed from one user to another via the Business Objects repository. It is possible for users to send documents using other domains they are allowed to access but since domains appear alphabetically and since users rarely notice the domain dropdown on the send to user screen, user-to-user documents will likely remain confined to this area.

· Scheduler_DoNotUse – Used to store documents being distributed by the Broadcast Agent. A second Broadcast Agent has been set up for Corporate Documents published on a schedule that uses the ‘Corporate_Documents’ document domain. See above for a detailed explanation of the naming convention ‘_DoNotUse’
The table below can be used to record pertinent database information pertinent to the repository. The sample is designed for Oracle

Read more »

The Repository

The Default Repository Structure

The default Business Objects repository consists of three domains:

· Security Domain – Stores users, passwords, permissions, and connection information.
· Universe Domain– Stores universe structure (classes and objects)
· Document Domain– Stores documents and universe lists of values

There are several drawbacks to using the default repository structure provided by Business Objects:

· Universe lists of values and all document types share the same repository domain
· All three repository domains share the same database account
· There is no way to place two universes or documents with the same name in the repository for testing purposes

The Custom Repository

For the reasons listed in the previous section and for ease of maintenance, organization, and disaster recovery purposes, consider creating a custom repository with multiple domains.

The diagram below is a graphical representation of a sample new repository layout:

In the example, each Universe domain is in a separate schema with a separate default tablespace to eliminate the risk that an error will cascade and corrupt the entire repository. Universe domain schemas must also contain a Document domain. This Document domain is used to store custom lists of values.

There are four additional Document domains in four separate schemas with their own default tablespaces. These are used to store various types of documents.

The purpose of each repository domain is explained in detail below:

· BusinessObjects Security – This is the default security domain. For more information see above.
· Universe – This is the default universe domain. It is not currently being used in the example to store universes.
· Document – This is the default document domain. It is not currently being used in the example to store documents or lists of values.
· Production_Universe – Used to store Production universes.

· ProdLOV_DoNotUse – Used to store Production universe lists of values. It is named ‘_DoNotUse’ to discourage use for purposes other than the storage of universe lists of values. No user group has access to the domain and surprisingly enough, this does not prevent designers from being able to export custom lists of values nor does it prevent users from being able to import them.
· Test_Universe – Used to store Test universes or universes being staged from Test to Production. An additional Dev_Universe domain could be added.
· TestLOV_DoNotUse – Used to store Test universe lists of values. See above for a detailed explanation of the naming convention ‘_DoNotUse’. An additional DevLOV_DoNotUse could be added.
· Corporate Documents – Used to store Corporate Documents
· Secure_Documents – Used to store and separately secure documents accessed by selected customers (You many have as many document domains as necessary to secure or organize Business Objects reports).
· BO_User_Documents – Used to store documents mailed from one user to another via the Business Objects repository. It is possible for users to send documents using other domains they are allowed to access but since domains appear alphabetically and since users rarely notice the domain dropdown on the send to user screen, user-to-user documents will likely remain confined to this area.

· Scheduler_DoNotUse – Used to store documents being distributed by the Broadcast Agent. A second Broadcast Agent has been set up for Corporate Documents published on a schedule that uses the ‘Corporate_Documents’ document domain. See above for a detailed explanation of the naming convention ‘_DoNotUse’
The table below can be used to record pertinent database information pertinent to the repository. The sample is designed for Oracle

Read more »