Friday, 22 February 2013

Setup for Oracle BI Enterprise Edition (OBIEE 10g/11g) Multi-User Development Integrated with Source Control – Part A

One of the important challenges I come across during many years of working in OBIEE APPS world is to provide of a robust, comprehensive project management technique for managing multiuser development integrated with source control.

Introduction

Customers having large, complex or development teams that are not co-located often have multi developers simultaneously working on the same RPD. So challenge to make sure that development work is not lost or overwritten and it should be restorable to a previous freeze date as and when required.

This blog is an attempt to share some of the information I have used to setup the multi-user development integrated with source control. The text in this blog is owed to my colleagues and counterpart on multiple projects; I am just a messenger or publisher of this information. This two part blog covers multiuser development integrated with source control for 10g in the first section while second would be covering multiuser development and source control for 11g, which is more sophisticated that the earlier(10g) one.

Multi-User Development Resources

Refer technical note from oracle support and Bookshelf documentation for a detailed discussion on Multi-user development process specific to Oracle BI before started working on following configuration steps.

Step by Step Approach

1.    Administrator creates a multi-user development (MUD) folder on their desktop. This folder can be located independent of the BI installation folders.

2.    Administrator checks out the latest version of “Master” RPD from your SCM and copies it to the repository folder of your BI installation.

3.    Administrator logs into the BI application and opens the base-line version of the RPD from the repository folder in offline mode.

4.    From the Menu, Pick Manage > Projects and create new projects that are manageable in size. E.g. separate projects for each reporting area such as Finance, Procure to Pay etc

5.    After creating a project, assign objects to this project, for example, when the Sample Sales presentation catalog object is “Added”, all the BMM and Physical objects referenced by this presentation catalog will be included in this project.


6.    After defining all the projects, save your work in the RPD.

7.    From the menu pick Tools > Options and select the More tab to set the MUD directory.


8.    Save your changes and close this RPD (you do not need to exit the BI Admin tool).

9.    Using windows explorer copy this RPD to the MUD folder and change the name to identify that this is the “master” rpd. Ex: Master_Dev.rpd.

10.    From the File Menu, select Multi-User Checkout (BI checkout).

 
11.    After login with admin credentials the administrator is asked to pick one or more of the projects defined. Here I have been choosing B-Inventory Fact project.

12.    The following prompt requests for a file name that should be used to save this project(s). Note: The default folder this RPD is saved to is the BI install Repository folder.


13.    The new RPD is opened in Offline mode. This RPD will consist of all the objects that are associated to the projects chosen in the checkout process. Save the new RPD.

a.    The Repository folder will have two RPD files, the OriginalInventory.rpd and Inventory.rpd.


b.    A log file is created on the MUD folder providing information consisting of checkout data/time, creation of the two RPDs discussed above, and the Login and machine name.
14.   Administrator can continue to checkout (BI Admin Tool) other projects by following the steps 10-15 for each project. Please remember to always save the project RPDs before closing them.

15.   Administrator can next check-in (SCM Check-in) the project RPDs and Master_Dev.RPD into SCM.

16.  Developers can individually work on these project RPDs by following SCM’s check-in, check-out processes, and ensure that projects are copied to the BI installation Repository folder on their desktops.

17.   On a pre-set freeze date, Administrator will request that all project RPDs be checked-back (SCM Check-in process) into SCM.

18.   After this freeze date

a.    Administrator will check-out (SCM check out) the Master_Dev.RPD from SCM into the MUD folder.
b.    Administrator will then connect to BI Admin Tool and check-out (BI Admin Tool Check out) projects from the Master_Dev.RPD into the Administrator’s Repository folder. Note: These project RPDs must be named the same as the ones in source control.
c.    Administrator must then check-out the project RPDs from SCM and overwrite the project RPDs checked-out from the Master_Dev.rpd.

 19.Administrator will open one of the project RPDs and performs a compare
 



20.    After compare then choose Merge Local Changes


21. The lock information screen appears where Administrator can add comments regarding this check in. Once comment in put in the next screen Stats can be reviewed to monitor what was changed and the Merge button needs to be clicked.


22. Once done the next step is to Publish to Network, this step assures that the changes from this project are saved.


23.  Steps from 19-22 will be repeated for checking in ( merging) changes from each of the projects created.

24. Copy the “Master” RPD from the MUD folder to the Development server. Note: the Development Analytics Server will have to be stopped and re-started in this process.

25. Administrator to create a new project in your source control software and copy the “Master” RPD.

26. The above process is repeated for the next development cycle, with the following two important caveats.
  • The Administrator will open the RPD from the repository folder and remove and re-add presentation catalogs to each project again. This step is required to ensure that all new objects created in the previous development cycle are included for the next check-out. Alternatively, Administrator can choose to redefine projects based on new requirements
  • The source control files will need to be re-based.
Key Factors for Success Assurances  

1.    Only one key developer is tasked to execute this entire process as the Administrator to ensure consistency and to avoid miscommunication.

2.    Development cycles (phases) should be clearly defined and strictly adhered to. Initially this can be 2 weeks, but ideally team should strive to keep this at 4 weeks.

3.    Projects need to be defined in stripes covering presentation, BMM and Physical layers. These stripes should be of manageable size to ensure the following

a.    Minimize project contention issues, as only one developer can check-out a project from your source control system at a given time.

b.    Minimize the risk of overstepping each other’s work. The same object could be part of two projects, and so two developers following this process could still overwrite each other’s work. The check-in process is a true merge, which could minimize this risk, but developers will still need to be aware and educated on these consequences

c.    Developers: Ensure all new physical objects created have a corresponding BMM object defined and all new BMM objects have a corresponding Presentation object defined. Since the Administrator includes the Presentation catalog objects to a project, this check will ensure that the other layers of the RPD are automatically part of this project.

d.    d. If a given project needs to be backed out after Administrator checks the project in, Administrator can go back to the previous set of files (project RPDs and Master.RPD) on your source control system and check in all EXCEPT that one project again. This is the fall-back approach to be able to selectively roll-back a specific project’s changes.

e.    In case, a given project is not ready to be checked-in by Freeze time (meaning, developers have made modifications to a project and checked-in their changes into source control system, but the project is not complete for testing purposes). In this case, Administrator can selectively avoid checking that one project in (Oracle BI check in), but continue with the remaining projects. Later, a developer can merge the older version’s RPD into the new RPD that will be checked-out for the same project and merge the changes.

                                          i.    Caveat: Administrator has to ensure that the same project is checked out again in
                    the next cycle to achieve this workaround.


This is not ideal solution, it has many limitations. Let us discuss these limitations in next blog and also touch on what OBIEE 11g offers for source control.

1 comment:

  1. Hey,
    Nice piece of information shared for all those who want to learn online can visit http://www.wiziq.com/course/22309 as it is a e-learning platform .

    ReplyDelete