The OBIEE 11g development has a special feature so before going new version , would like to take how to implement the general rpd development process.This processes also refers to MUD (Multi-User Environment) environment setup.
The MUD environment is done by creating Projects in the repository file in the BI Administration Tool and then copying this repository file to a shared network directory. Developers can check out projects, make changes, and then merge the changes into the master repository.
The entire concept of MUD (MutliUser Development) revolves around objects called as Projects. Projects are subsets of objects based on logical fact table that can be assigned to individual users. So, the idea is to assign different projects to different users. Also, each of these projects can contain one or more Logical Fact tables. As soon as a logical fact table is included all the other dependent objects would automatically be part of the project.
General RPD Development Process
In the Admintool, Go to File/Multiuser/Checkout, choose the project you want to work on for checkout.
AdminTool will then create a local copy of the extracted project in your local directory under (C:\Negril\orainst\bifoundation\OracleBIServerComponent\coreapplication_obis1\repository) with the name you provided during the extract (say localfile).
AdminTool will also create a new file called original.rpd
Work on your local copy(localfile.rpd), and make sure you save and run Global Consistency Check frequently.
Once you are satisfied with your work, and there are no Errors in the Global Consistency Check, go to File/Multiuser/ and choose the Merge Local Changes option.
This will start a Merge process which will merge your modifications into the main rpd file, taking into account changes other Engineers might have introduced to the same objects you have modified. This is a three-way merge process which will compare data from the master rpd, with data in your work rpd, and in the original file described in step 3.
This step will bring the full rpd locally in your screen, and give you a lock on that file. Only one person can check in at one time, so it is important you do this quickly and release the lock.
In the new screen that pops up, if the Merge option is greyed out, it means you need to make some Merge decisions. For all objects you have modified or your team owns and you are confident your changes should prevail, choose the Modified option. For all other objects, choose the Current option.
After all decisions have been specified, you should be able to click on the Merge button at the bottom of the screen.
Once the Merge is done, check all your changes in the full rpd. If you are satisfied, run a Global Consistency check one more time.
If everything is fine (no Errors), choose File\Multiuser\Publish to Network.
If there are any errors related to your own changes/metadata that you cannot fix, choose Discard local changes. This will release the main rpd without any changes. You then need to talk to your colleagues to see what is the problem with your metadata. You will need to redo your work after this step.
This is why it is better you checkin your work periodically, like once a day at least, so you don't loose much work if you have to discard any changes. We recommend developers should check in their work EVERYDAY.
No matter what happens, do not go home with the full rpd lock still maintained by you. Somebody will call you at any time of the day (or night) to release it . Or worse yet, The Administrator can remove your lock, and you will loose all your work.
MUD Best Practice process
The MUD utility allows us to support a large number of parallel users, but everybody needs to follow the same process when using this utility. Here are the general guidelines :
1. Every user should extract a project for himself to modify, and then check it in from the same environment directly in the master MUD env.
2. No user should overwrite the extracted copy with another one modified in a different machine or folder
3. Users should refresh their local copy frequently, to minimize the conflict decisions taken by the Merge engine during checkins. I suggest once every two to three days.
4. Every user should have one no more then one extracted project in his machine at any point of time. Please do not extract more then one project into the same environment. This can cause confusion.
5. If you find any object in your extracted project that you don't think should be part of the project, please do not delete it. It will get deleted from the main rpd in that case. You can simply log a bug against Admintool, and provide the master rpd, and the project name.
6. If you have any doubt about the changes you made to your local copy, please delete it and start over again, by taking a new extract. This is much cheaper for the team in the long run.
7. Run a Consistency Check on your local project before merging your changes. You should fix all Errors reported by the Consistency Check. If you cannot fix an error, please consult with your colleagues. In the past few weeks, a large number of the issues we had with checkin/checkout process have been due to bad code in the master rpd. We can avoid most of the downtime in our development if every team commits not to check in buggy code into the master repository
The MUD environment is done by creating Projects in the repository file in the BI Administration Tool and then copying this repository file to a shared network directory. Developers can check out projects, make changes, and then merge the changes into the master repository.
The entire concept of MUD (MutliUser Development) revolves around objects called as Projects. Projects are subsets of objects based on logical fact table that can be assigned to individual users. So, the idea is to assign different projects to different users. Also, each of these projects can contain one or more Logical Fact tables. As soon as a logical fact table is included all the other dependent objects would automatically be part of the project.
General RPD Development Process
In the Admintool, Go to File/Multiuser/Checkout, choose the project you want to work on for checkout.
AdminTool will then create a local copy of the extracted project in your local directory under (C:\Negril\orainst\bifoundation\OracleBIServerComponent\coreapplication_obis1\repository) with the name you provided during the extract (say localfile).
AdminTool will also create a new file called original
Work on your local copy(localfile.rpd), and make sure you save and run Global Consistency Check frequently.
Once you are satisfied with your work, and there are no Errors in the Global Consistency Check, go to File/Multiuser/ and choose the Merge Local Changes option.
This will start a Merge process which will merge your modifications into the main rpd file, taking into account changes other Engineers might have introduced to the same objects you have modified. This is a three-way merge process which will compare data from the master rpd, with data in your work rpd, and in the original file described in step 3.
This step will bring the full rpd locally in your screen, and give you a lock on that file. Only one person can check in at one time, so it is important you do this quickly and release the lock.
In the new screen that pops up, if the Merge option is greyed out, it means you need to make some Merge decisions. For all objects you have modified or your team owns and you are confident your changes should prevail, choose the Modified option. For all other objects, choose the Current option.
After all decisions have been specified, you should be able to click on the Merge button at the bottom of the screen.
Once the Merge is done, check all your changes in the full rpd. If you are satisfied, run a Global Consistency check one more time.
If everything is fine (no Errors), choose File\Multiuser\Publish to Network.
If there are any errors related to your own changes/metadata that you cannot fix, choose Discard local changes. This will release the main rpd without any changes. You then need to talk to your colleagues to see what is the problem with your metadata. You will need to redo your work after this step.
This is why it is better you checkin your work periodically, like once a day at least, so you don't loose much work if you have to discard any changes. We recommend developers should check in their work EVERYDAY.
No matter what happens, do not go home with the full rpd lock still maintained by you. Somebody will call you at any time of the day (or night) to release it . Or worse yet, The Administrator can remove your lock, and you will loose all your work.
MUD Best Practice process
The MUD utility allows us to support a large number of parallel users, but everybody needs to follow the same process when using this utility. Here are the general guidelines :
1. Every user should extract a project for himself to modify, and then check it in from the same environment directly in the master MUD env.
2. No user should overwrite the extracted copy with another one modified in a different machine or folder
3. Users should refresh their local copy frequently, to minimize the conflict decisions taken by the Merge engine during checkins. I suggest once every two to three days.
4. Every user should have one no more then one extracted project in his machine at any point of time. Please do not extract more then one project into the same environment. This can cause confusion.
5. If you find any object in your extracted project that you don't think should be part of the project, please do not delete it. It will get deleted from the main rpd in that case. You can simply log a bug against Admintool, and provide the master rpd, and the project name.
6. If you have any doubt about the changes you made to your local copy, please delete it and start over again, by taking a new extract. This is much cheaper for the team in the long run.
7. Run a Consistency Check on your local project before merging your changes. You should fix all Errors reported by the Consistency Check. If you cannot fix an error, please consult with your colleagues. In the past few weeks, a large number of the issues we had with checkin/checkout process have been due to bad code in the master rpd. We can avoid most of the downtime in our development if every team commits not to check in buggy code into the master repository
