Multi-User Environment for Siebel Analytics/OBIEE by Alok Chowdhary on March 13, 2009 in Siebel Street

By default, only one user can edit the repository at a time, but a more efficient environment would allow developers to modify the repository simultaneously and then check in changes. Oracle BI allows multiple developers to work on objects from the same repository during group development of Oracle BI applications.

Steps for configuring Oracle BI multi-user development environment:

1)Create Project

In the Admin tool, open the Project Manager

Path:-Select Manage > Projects and then Action > New project for creating new project.

From the figure down below, you can notice two parts, in the left you can see objects that are available for the project and the right part consists of objects that can be added in projects. Select the objects from the left part that you want to add to the project and click the Add button. If you have selected the presentation catalog, all fact and dependent objects are selected in the project.

Besides the catalog, other objects such as USER, groups, Variables and initialization blocks can also be added in projects. Apart from this, you can also remove unwanted objects from project by clicking the Remove button.

2) Set up a shared network directory

Administrator needs to identify or create a shared network directory that can be accessible to developers to keep the repository file at that location. This repository is the master repository which is accessible to multiple developers to check in or check out the changes done. Developer has to point to this directory path when they use Admin tool at their machine.

Making changes in the Admin tool at the local machine to use as a multi-user development environment:

1)Point to multi-user directory:

Set up for Admin tool to point multi-user  development directory.

Path:-Select Tools > Options and then select Multiuser tab.

From the figure,  it can be seen that it is a two field, one multi-user development directory in which you have to browse the path of the shared directory where the original repository has been kept for development purposes. The other field full name  is optional,  but if the user mentions name in that field, it helps in tracking the changes made by each user and stored in the HKEY_CURRENT_USER part of registry and is therefore unique for each login on computer.

2. Check out project:-

After pointing to the multi-user development , the directory developer can check out desired projects.

To check out projects, go to path File > Multiuser > Checkout which will be only available when the multi-user environment is setup. After this, the developer is presented with a dialog box to select the master repository if one has more than one repository. Select the repository , then enter user name and password, it will navigate to select the project or projects to be imported. After selecting the projects,  user must enter the name of the new repository which will be stored in user’s local directory.

3.Admin tool task during checkout:-

During checkout , the admin tool performs the following task:-

• Makes a temporary copy of the master repository on the local machine.
• Saves local copy of projects in the new repository on the local machine.
• Saves second local copy of project in the new repository on the l
  local machine with prefix as “original”.
• Deletes temporary copy of the master repository from the local machine.

4. Changes done in metadata:-

Changes can be performed on logical tables, table definitions and logical table sources. Developers can work on the same project but if one developer deletes objects,  it will be migrated without any warning. So developers should keep in mind that modifications can affect others too.

5. Tasks done during check-in:-

The Admin tool perform the process of locking the master repository to prevent other developers from attempting to merge at the same time and copies the master repository to a local directory so that the developer will be merging with the latest or recent repository.

6. Check in changes:-

After performing modifications on the repository, the developer needs to check in changes and merge with the master repository in the shared path. Only one developer at a time can merge it. After selecting File > Multi-user >Merge local changes, the developer is shown a  dialog box having full name and the option to write comments if any and after clicking ok , the admin tool performs the process of copying master from shared and keeps it on the local machine.

After developers lock the master repository,  the merge process take place. After the merge process,  developers have to publish to the network.  Go to path File >Multi-user >Publish to Network to publish changes done in the repository.  This will finally merge local repository changes to the master repository and at the same time a local copy of the repository has been removed from the local machine.

Advantages:

• History menu option:-This option gives the detail of all the changes performed during the merge process. We can have the version history that tracks all the changes performed in the repository during the merge process.
• It helps to track the Project history.

Disadvantage:

• Multiuser develop environment is purely for repository development. Dashboards/Reports can be developed/managed by any no of users in the browser once the presentation server is up.

Tp know more about OBIEE 

Improvement in DAC 7.9 – Subject Area Assembly

One of the nice new features in DAC 7.9 is the facility to assemble all the ETLs required to populate a fact using the Assemble button

In the Pre DAC 7.9 days, the process for building a star schema was as below

1. Think up all the tasks required to populate a star schemas (Basically the Informatica workflows)
2. Create the tasks and Identify Dependent and Depending on tables manually when creating a task.
3. Construct a Table Group where one had to figure out all tables that belong to the star schema i.e. the fact and related dimensions
4. And then at last build the Subject Area
5. Run the subject area and then curse yourself for not remembering some tables.
6. Start all over again.

Now

1. You don’t have to identify Dependent and Depending on tables. There is a sync feature which automatically identifies all the sources and targets which are affected/dependent on a task
2. The concept of a Table Group is dead. You just have to name the fact to be populated and click on the Assemble button
3. Click option: selected task only (unless you want to assemble for all subject areas delivered out of the box. Trust me : you don’t want to do this)
4. The DAC assembles the selected subject area by determining what dimensions and other related tables are required, and what tasks are needed to load these tables.
5. You will receive an informational message when the assemble process is comp
6. Hey presto, the Subject Area is ready

But wait a minute,

1. You still have to do some cleanup and remove unwanted tasks
2. Click the Tasks tab to view which tasks the DAC has determined are required for this subject area
3. Tasks that are automatically assigned to the subject area by the DAC are indicated with the Auto generated check mark.
4. You can inactivate a task from participating in the subject area by selecting the Inactive check box.
5. When the Inactive check box is selected, the task remains inactive even if you reassemble the subject area.
6. You can also remove a task from the subject area using the Add/Remove command, but when you remove a task it is only removed from the subject area until you reassemble the subject area
7. You still have to put in the implicit dependencies i.e. dependencies on tables that are not featured in the select statements or the workflow
8. Upgrade does not work for custom workflows setup in DAC

There’s still more

1. Unless you have a lot of time on your hands, don’t try clicking on the Assemble tab when DAC server has been up for some time
2. Stop the server, restart the client and then click on Assemble
3. It is much quicker. But don’t know why it works this way

So in conclusion Oracle DAC 7.9 is great and has some nice new features. But upgrading is going to be no fun. More on this later.

–Posted by Raghunatha Yadav/Sanjay Rao

Read More about  DAC 7.9