Guident Whitepaper Multi User Dev Strategy (1)

Guident

Multi User Development Strategy for Oracle Business Intelligence A White Paper by Guident

Darren Grogan

Senior BI Architect

April 2010

Guident

Collaborate 10 Copyright ©2010 by Darren Grogan 1 | P a g e

MMUULLTTII UUSSEERR DDEEVVEELLOOPPMMEENNTT SSTTRRAATTEEGGYY FFOORR OORRAACCLLEE BBUUSSIINNEESSSS IINNTTEELLLLIIGGEENNCCEE

Darren Grogan, Guident

CONTENTS

What is MUD? .............................................................................................................................................................................................. 2 Why use MUD with OBI EE? ................................................................................................................................................................... 2 MUD Process ................................................................................................................................................................................................ 3

MUD in action ......................................................................................................................................................................................... 3 Multi-user checkout ................................................................................................................................................................................. 5

Merge Management ...................................................................................................................................................................................... 7 Ensuring changes are pushed................................................................................................................................................................. 7

Publish to Network .................................................................................................................................................................................... 10 Validate updates on Shared drive ........................................................................................................................................................ 10

Guident


INTRODUCTION

WHAT IS MUD? Multi-User Development (MUD) is the enablement of a shared repository in Oracle Business Intelligence Enterprise Edition (OBIEE) which provides grouping of objects in the repository (.rpd) for check out/in against a master version. This capability allows for developers to work on different aspects of the Oracle Business Intelligence .rpd simultaneously without stepping on each other. During the requirements stage of an OBIEE project is typically when the decision for MUD is made including factors like team size and number of environments for development. The requirements for MUD can vary project to project but typically one implements this solution when there are many data sources and lots of tables; it would make sense to distribute the repository development work to multiple users. This paper will look at why MUD is a good solution for an Oracle Business Intelligence Applications (OBIA) or OBIEE project and will explore how and why implementation benefits the team. Whether your implementation team is using OBIA or building a completely custom solution the steps are the same including:

A master repository (shared location)

Subset repository

Local master repository

Repository merging

Share drive

WHY USE MUD WITH OBIEE? When analyzing the requirements of your OBIEE development environment many factors should be considered. If your application must deal with integration of many data elements including custom sources like an ERP or CRM system as well as a variety of business areas MUD may not be the easiest tool to administer, however, it is necessary to keep control of your development efforts. If your implementation project will be in phases, this can be the best way of ensuring you keep development consistent one project to the next. The four biggest reasons for using MUD:

Free - Included with the Admin Tool

Can reduce development re-work (nothing is performed live against the BI Server)

Organizes repository objects into projects

Allows multiple users in the same repository at the same time These factors allow for many projects to implement the MUD functionality quickly and cost effectively. An OBIEE developer that has previous experience will find this feature was missing from earlier versions of the tool set.

PROJECT SUMMARY Our project was a government contractor with a large scale implementation of OBIEE with BI Applications (Fusion) for Financials, Procurement and Projects. Our client requirements were for the Financial Analytics repository objects to be configured at the same time a separate set of developers building custom reports against historical data from eBusiness Suite R12. Remember one of the reasons for choosing is MUD is multiple data sources which was one of our deciding factors. We approached the client with the topic of forming two development teams to perform offline development and have a merge process every so often; however, we realized the recommended approach was to use MUD feature, which is an Oracle best practice. This very simple division of duties required our project team to develop in silos, however, as technical architect I still wanted to ensure proper configuration management. Since additionally our customer was new to OBIEE we decided to establish some basic ground rules for each of the developer workstations. The developers needed to check out on Monday and check in on Friday, assuming code was unit tested and completed. Before we could begin the work our specific implementation needed to involve network administration and security personnel for each developer for the following capability;

1. A shared drive to host the Master Repository 2. Access to the master repository. 3. Each workstation must have the OBI EE admin tool installed.

Guident


For MUD to work the repository needs to be shared by both of our development teams therefore the .rpd needs to be on a shared directory (Samba share if on Linux). The shared directory should be accessible by each member of the development team. In each of the developer’s Admin tool, it is necessary to enter the Shared Directory path.

MUD PROCESS The diagram below highlights the high level process our team needed to implement a MASTER Repository on the shared drive. This master repository is NOT the repository used in the BI Server memory which is (Online mode) but is a baseline repository we used for our project.

MUD IN ACTION Now, our master repository contains the pre-built Financial Analytics objects as installed from the OBIEE and OBIA installation. The file was copied to the shared folder. Each developer accesses a copy from the admin tool in offline mode. For MUD each object in the repository will be organized into Projects. Navigate to Manage –> Projects as seen below.

Guident


The projects window is now open and we projects are basically subsets of objects within the Admin tool which are grouped. The idea being each developer has their own objects assigned to a project which they work on. Typically, each project should contain one or more Subject Areas as well as logical fact tables from the Business Model and Mapping (BMM) layer in the repository. Once a developer selects a logical fact table, included are the other dependent objects which automatically become part of the new project. It is recommended import all the physical tables and create the physical joins in the repository first before implementing MUD. Since one part of the team is using the pre-built Financial Analytics we have the baseline for the physical already out of the box.

Multiple projects inside of the Admin Tool

In the above screen a developer selects the catalogs/objects needed for their piece of the project. So for our project team working with the pre-built Financial Analytics, we highlighted Financial Analytics Fusion Edition, clicked it and presented with the following screens.

Projects objects can be selected by Subject Area (Catalog) or Business Model. Each developer highlights by adding or removing objects to a project, and saving by clicking OK.

.

Guident


MULTI-USER CHECKOUT Before our project team and developers start the check out process we needed to ensure a share drive has been configured properly in the Admin tool. Navigate to Tools -> Options

Each developer on the project team needs to fill in the value under Multiuser development directory and match the share drive path. Make sure to click OK or the developer will need to re-enter the information. For our project we tested out the access a couple of times to make sure each developer was able to have the same experience.

As each developer configures their Multiuser development directory value and clicks OK it now facilitates their ability to access and test the checkout process. A developer navigates to File ->Multiuser -> Checkout. The checkout process performs 3 functions.

1. Copies the Master repository from the shared drive to the local drive (This will serve as the developer’s local master repository). 2. Allows the developer to choose the project as defined in the earlier steps 3. Creates a subset repository containing the selected project related objects for that developer.

Guident


The Checkout option is enabled once the shared path has been entered

Once the developer chooses check out the process moves quickly.

Next, ensure that the projects defined are visible and select the appropriate project for developer use.

Guident


The next window will ask for a new name of the subset repository (i.e. the local version for each developer)

Provide name for new subset repository

Once the new subset repository has been created, there are two items to validate.

1. The new name of the repository is the same as the value you just provided – For our team we named it MUD 2. The only Subject Areas are from the project – Remember our developer selected the “Financial Analytics” catalog previously.

The screen shot below validates our work.

MERGE MANAGEMENT

ENSURING CHANGES ARE PUSHED It is important to validate changes prior to pushing to the network. Once a developer makes changes, they can be validated by choosing the Compare with Original option to ensure configured items do not break the rpd.

The name of the rpd is MUD

The Subject Areas are all Financial Analytics

Guident


Notice the Multiuser menu has enabled four (4) menu options from which to choose.

1. If the developer chooses Checkout again, they will lose the current local changes since those changes have not been pushed to the

Master. 2. Compare with Original will do just that and the developer will see the differences of what they have configured vs. the vanilla Master 3. Merge Local Changes allows the developer to accept what has been configured and merge before pushing back to the server 4. Discard Local Changes allows the developer a do over.

Multiuser menu changes once a developer has made configuration changes

The developer can then decide if more information is needed or if they will perform the actions. By clicking the Compare with Original (highlighted) we can see what changes were made.

By clicking on the Diff button we see in the popup the changes made by the developer, and it’s up to the developer to compare the differences against the Master.

Guident


Now let’s complete the development lifecycle by selecting Merge Local Changes and push to the target Master rpd on the server.

In choosing Merge Local Changes the developer updates the local copy by organizing and locking the objects needed for check in. Make sure to click OK or nothing will happen.

Next in the merge process the developer chooses to make local changes by making decisions about what was developed. The window shows the developer the Original repository, the Modified repository MUD.rpd and the Current repository.

The developer reviews the changes that have been made and makes a Decision.

Guident


After making a Decision, the developer must choose to perform the Merge and selects that value from the pick list Use value from repository which now enables the Merge Button and merging of the local repository.

PUBLISH TO NETWORK

VALIDATE UPDATES ON SHARED DRIVE Once the repository merge is complete the developer has the option to publish the update to the shared location on the server and changes are now merged with other developer changes. Since the developer only works on specific Projects and objects the merge will not overwrite other development efforts. Once validated our merge from the developer is ready for Publish to Network which means the changes are pushed to our Master rpd on the shared drive. This is a very important step because the presentation catalog change our developer made will now be a part of the Master for all developers when each performs the next check out. It is important to coordinate checking in and check outs so development teams are have a clear understanding of when code has been completed. Our project defined rules to check in only after a developer unit tested their own repository changes/code.

If the developer does not make a decision the Merge button will continue to be grayed out

Guident


Here we see the Publish to Network Button is finally enabled. Once selected the copy happens quickly and pushes the changes to the shared Master repository.

The developer sees a quick copy motion of objects to the Share but once the process is complete the developer is no longer in the local repository and is placed at a blank screen in the Admin tool.

The check in process is complete and we see on the Shared drive an update to the .rpd with a timestamp showing a current date.

The version of the rpd is now ready to be moved to the BI Server\Repository directory and started up the next time the BI Server is brought up..

Guident


Guident Whitepaper Multi User Dev Strategy (1)

Documents