Approaches to Test and Production Universes

---

As business intelligence tools have matured, many companies are deploying them across the enterprise. However, all the version management that exists in a mainframe environment is still not quite as robust in the client/server environment. BusinessObjects offers two main approaches to separating development and production environments. The first is through the repository; the second is through domains.

Repository

The BusinessObjects General Supervisor has the capability to create two separate repositories, as shown in Figure 14-3. The benefit of this approach is that the environments are truly separate. Each repository can reside in a separate physical database. The connection string to each physical database is stored in a different key file, for example BOMain.key and Test.key. This can pose maintenance issues as users who need to access both repositories need to have both repository.key files installed locally or on a shared network drive. If you are using WebI, you are limited to one repository per cluster manager.

Figure 14-3: Two repositories allow designers to separate development and production environments.

Designers and full-client test users select the appropriate repository/Security Domain during login:

The main risk with the repository approach is that any work done on the PC is not clearly identified as test or production. Recall that all universe development is done via local files on the client PC (step 1, Build, in Figure 14-3). Let’s assume you have a test version of the universe Sales.unv. This is stored in the default directory C:\ProgramFiles\Business Objects\BusinessObjects 5.0\Universe\domain, where domain is the name of the universe domain (the default is Universe). You export this to the test repository so that users can test the changes in the universe (step 2). When the universe is ready to go into production, you export the universe definition to the production repository (step 3). You may need to manually synchronize the connection definition in the new repository. As time goes on, you may make more changes to the universe and export new versions to the test repository (step 2). However, while trying to solve a production problem, you stop working on the test universe and import the production universe (step 4). You forgot to export the revisions to the test universe to the test repository and just overwrote your test universe! The same thing happens with reports and lists of values. It’s very easy to unintentionally overwrite the wrong files, especially as an import can happen automatically when logging into the BusinessObjects user modules. The universe names are the same; the file directory is the same; and the repository name is clearly displayed only during initial login.

Security personnel may like this approach because from the database viewpoint, the security domains must reside in different databases; the environments are truly separate. However, it is a potential nightmare for designers.

Domains

Years ago, the BusinessObjects repository contained everything from documents to user definitions to universe definitions. The concept of domains was introduced in version 4, allowing an administrator to divide more effectively the storage of various components. Large documents could be stored in a separate document domain, while smaller universe components could be stored in a universe domain. The existence of domains also allows an administrator to create separate domains for test and production (Figure 14-4). Each domain has its own connection, thereby allowing test universe and document domains to be on one physical database while production universe and document domains can be on a separate database; however, the security domain is shared between the two, unlike in the repository approach. Alternatively, the test and production domains can also exist within the same database instance as long as the table owners are different.

Figure 14-4: Domains allow separation of test and production universes and documents.

The use of domains to separate test and production has some advantages over the use of repositories. First, domains do not require a separate .key file so this approach is also available for WebI users. Second, the domain name is appended to the default folders, minimizing the risk of unintentionally overwriting files. Each domain within a repository requires a unique name. Compare step 4 in Figures 14-3 and 14-4; the import from production goes to a separate folder with a unique domain name in the domain approach, whereas the same folder is used in the repository approach.

As an example, I have a test domain called the default, Universe, and a production domain called UniWeb. When I import the test Sales universe, the Sales.unv file gets stored in the following path:

C:\ProgramFiles\Business Objects\BusinessObjects5.0\Universe\Universe

The list of values files get stored in the following:

C:\Business Objects\BusinessObjects5.0\UserDocs\Universe\Sales

When I import the production Sales universe, the production domain name UniWeb gets included in the path:

C:\Business Objects\BusinessObjects5.0\Universe\UniWeb C:\Business Objects\BusinessObjects5.0\UserDocs\UniWeb\Sales

Note 

You can modify the default path by selecting Tools | Options and the Save tab; however, the domain name will still get appended to the default path.

When a designer is ready to export the test universe to production, you select the new domain name from the drop-down box while exporting (File | Export). It’s important to pay careful attention to the domain name in the drop-down box as well as the path in the filename. In the next example, I am exporting a universe from the test domain (Universe) to the production domain (UniWeb). During development, or in cases in which you have not separated test and production, the domain name and file pathname will be the same; here you are moving from a test environment to production, so they are different.

Note 

If you are working with linked universes, you must manually update the link to reflect the new path of the production universe. Select File | Parameters | Links. Then click Change Source to specify the new production path.

Documents in Test/Production Domains

When users create a report and there are two universes with the same name, the domain name gets reflected in [brackets]. In the next screen, there are test and production copies of the Kernel and Derived universes.

The actual document contains only the name of the universe and not the specific domain, making it easy to put reports into production. When a document finds only the production universe Sales.unv, it automatically uses this universe. There had been problems with earlier versions of WebI when the document still looked for the test universe file from the test domain. This problem existed only in derived universes and not in nonlinked universes; however, this bug was fixed in WebI version 2.6.

The slight exception is with a user or designer who continues to have access to both the test and production universe.unv files. These users must manually change the Universe Definition within the document Data Manager. From within the BusinessObjects user module, select Data | View Data and the Definition tab. Under the Definition setting, click the ellipsis button to modify which version of the universe the document should access:

---