MUD:
Multi User Development (MUD) environment is a feature of OBIEE Administration tool which permits multiple users to modify a single repository simultaneously and then check in changes. The repository here refers as the master repository. This supports concurrent development.
The master repository is created in a shared directory. The concept of MUD is to create different projects and assigned them to different users. Each of these projects can contain multiple fact and dimension tables.
To work in a MUD, the Client machines (Users) should have access to the master repository. The steps for working in a MUD are illustrated in the above diagram. There are some tips and best practices which should be followed while working in a MUD.
Removing # Copies:
When a column is renamed or modified and then dragged into the presentation layer, a #1 copy of the column is created in the presentation layer. Because while merging into the master repository the merge process gets the older column and then appends #1 with the newer column in order to differentiate.
To avoid such issues, the following steps should be followed.
1.
Make changes in your local rpd and test whether changes are getting reflected in Answers
2.
Save the local rpd.
3.
Checkout the master rpd (Go to Administration -> File -> Multiuser -> Checkout).
4.
Select your project.
5.
Save the subset of master repository with some name.
6.
Remove all objects from Physical layer, BMM layer and Presentation layer.
7.
Go to Manage-> Variable; Remove all the initialization blocks, repository and session variables.
8.
Save the blank repository.
9.
Go to File-> Multiuser->Merge local changes->Merge.
10.
Go to File-> Multiuser->Publish to Network.
11.
Again checkout the master rpd (follow steps 3 to 5).
12.
Copy all the physical layer, BMM layer and Presentation layer objects, all the variables and initialization block from the local rpd to the blank rpd.
13.
Go to Manage-> Projects-> Add the catalogs.
14.
Go to File-> Multiuser->Merge local changes->Merge.
15.
Check all the changes in the master repository.
16.
Go to File-> Multiuser->Publish to Network.
Another way is to check for the # copies manually before publishing to network.
OBIEE Repository and Catalog Change Tracker:
While working in MUD, it is a best practice to update a tracker which keeps track of the rpd and catalog change details. While changing the rpd we should always take the back up of the previous rpd for our future use. For this, a tracker can be used to keep track of the updates which are being done on the rpd and catalog. If in the future we want to revert back to the previous design, then the task will be just to merge the backup copy.
So every time we deploy our rpd and catalog to another environment or we update anything on the current design, we should update the tracker.
Benefits:
1. Track the changes that we are doing on rpd and answers.
2. Locations of the back up rpd (old rpd), archived file for catalog (old catalog) can be
stored in a single document.
3. Track the status of changes in the new environment.
4. Track the dates on which rpd /catalogs are merged in different environments and many more.
Multi User Development (MUD) environment is a feature of OBIEE Administration tool which permits multiple users to modify a single repository simultaneously and then check in changes. The repository here refers as the master repository. This supports concurrent development.
The master repository is created in a shared directory. The concept of MUD is to create different projects and assigned them to different users. Each of these projects can contain multiple fact and dimension tables.
To work in a MUD, the Client machines (Users) should have access to the master repository. The steps for working in a MUD are illustrated in the above diagram. There are some tips and best practices which should be followed while working in a MUD.
Removing # Copies:
When a column is renamed or modified and then dragged into the presentation layer, a #1 copy of the column is created in the presentation layer. Because while merging into the master repository the merge process gets the older column and then appends #1 with the newer column in order to differentiate.
To avoid such issues, the following steps should be followed.
1.
Make changes in your local rpd and test whether changes are getting reflected in Answers
2.
Save the local rpd.
3.
Checkout the master rpd (Go to Administration -> File -> Multiuser -> Checkout).
4.
Select your project.
5.
Save the subset of master repository with some name.
6.
Remove all objects from Physical layer, BMM layer and Presentation layer.
7.
Go to Manage-> Variable; Remove all the initialization blocks, repository and session variables.
8.
Save the blank repository.
9.
Go to File-> Multiuser->Merge local changes->Merge.
10.
Go to File-> Multiuser->Publish to Network.
11.
Again checkout the master rpd (follow steps 3 to 5).
12.
Copy all the physical layer, BMM layer and Presentation layer objects, all the variables and initialization block from the local rpd to the blank rpd.
13.
Go to Manage-> Projects-> Add the catalogs.
14.
Go to File-> Multiuser->Merge local changes->Merge.
15.
Check all the changes in the master repository.
16.
Go to File-> Multiuser->Publish to Network.
Another way is to check for the # copies manually before publishing to network.
OBIEE Repository and Catalog Change Tracker:
While working in MUD, it is a best practice to update a tracker which keeps track of the rpd and catalog change details. While changing the rpd we should always take the back up of the previous rpd for our future use. For this, a tracker can be used to keep track of the updates which are being done on the rpd and catalog. If in the future we want to revert back to the previous design, then the task will be just to merge the backup copy.
So every time we deploy our rpd and catalog to another environment or we update anything on the current design, we should update the tracker.
Benefits:
1. Track the changes that we are doing on rpd and answers.
2. Locations of the back up rpd (old rpd), archived file for catalog (old catalog) can be
stored in a single document.
3. Track the status of changes in the new environment.
4. Track the dates on which rpd /catalogs are merged in different environments and many more.
