Change Management Rittman Mead

T : +44 (0) 8446 697 995 or (888) 631 1410 (USA) E : [email protected] W: www.rittmanmead.com

Mark Rittman, Technical Director, Rittman MeadOracle OpenWorld 2011, San Francisco, October 2011

OBIEE Deployment & Change Mgmt Best Practices

Saturday, 1 October 11

mailto:[email protected]


http://www.rittmanmead.com



Mark Rittman

•Mark Rittman, Co-Founder of Rittman Mead•Oracle ACE Director, specialising in Oracle BI&DW•14 Years Experience with Oracle Technology•Regular columnist for Oracle Magazine•Author of forthcoming Oracle Press book on OBIEE 11g•Writer for Rittman Mead Blog :

http://www.rittmanmead.com/blog•Email : [email protected]•Twitter : @markrittman






http://www.rittmanmead.com/blog

http://www.rittmanmead.com/blog




About Rittman Mead

•Oracle BI and DW platinum partner•World leading specialist partner for technical excellence, solutions delivery and

innovation in Oracle BI•Approximately 30 consultants worldwide•All expert in Oracle BI and DW•UK based•Offices in US, Europe (Belgium) and India•Skills in broad range of supporting Oracle tools:‣OBIEE‣OBIA‣ODIEE‣Essbase, Oracle OLAP‣GoldenGate‣Exadata







Oracle Business Intelligence 11g (11.1.1.5)

•Oracle’s BI platform, now at release 11.1.1.5 (11gR1)•Wide range of servers, tools, metadata stores based around Oracle FMW11g•Based on Siebel Analytics with additions from Oracle and Hyperion products•Often used in conjunction with the BI Applications and EPM Suite







Elements of an Oracle BI EE 11g Project

•Oracle BI Repository (RPD file)•Oracle BI Presentation Catalog•System Configuration Settings•UI Customizations•Security artifacts (application roles, users, directory settings)•Plus associated database schemas, ETL packages etc (out of scope for this though)







OBIEE 11g Project Lifecycle Stage #1 - Early Days

•Prototype to first production•Typically a single developer, no version-control• Initial project is moved from DEV server into PROD once first phase complete

Test ProdDev

SingleDeveloper

End Users

Full uploadof RPD andcatalog via EM








OBIEE 11g Project Lifecycle Stage #2 - Further Releases

•Updates to this first release, to add new RPD objects, shared folder catalog objects• Incremental metadata needs to be merged into PROD, keeping existing objects•Uses the three-way merge features for the RPD and the catalog

Test ProdDev

SingleDeveloper

End Users


Incremental updateof RPD andcatalog sharedfolders via merging,then EM M

erge







OBIEE 11g Project Lifecycle Stage #3 - Project Expands Out

•Additional developers wish to add content to the RPD•Typically all developers on the project start accessing the RPD online, concurrently•Other separately developed projects may need to be merged into the main RPD•Version control becomes important as multiple developers start contributing changes

Test ProdDev

SourceControl

MultipleDevelopers End Users

Other projectRPDs

Merge

Merge







OBIEE 11g Project Lifecycle Stage #4 - Enterprise Deployment

•Soon, ad-hoc merging of RPDs and shared online development becomes unworkable•A system needs to be put in place to handle distributed development•Multi-User Development (MUD) Environment then becomes an option

Test Prod

SourceControl


DevelopmentBranches

Merge

Merge

M e r g e

MUD Administrator

SourceControl

SourceControl







Propagating System Configuration Changes

•At various points, system configuration changes have to be applied to BIEE environments‣Deploying new repositories, presentation catalogs‣Enabling SSL, new connections to directories (AD) etc‣Changing performance parameters

•All changes have to be applied to all nodes in a cluster, possibly with rolling-restarts

TestDev Production Cluster

Developer Production Support







BI EE Features to Support Change Management & Deployment

•Three-way merges of repository files•Catalog archiving/unarchiving•New in 11g - repository and catalog patching•Multi-User Development Environment•New in 11g - Enterprise Manager Fusion Middleware Control (“EM”)•New in 11g - WebLogic Server Scripting Tool & Oracle BI Systems Management API







Merging Repository Files (RPDs)

•Merging repositories is a common task on projects past the initial stage‣ To merge new and changed objects in DEV into the PROD repository‣ To merge two RPDs into one, to run online in PROD

•Common task in general software development projects, with common complications‣Repositories may contain similarly-named objects, but logically different‣Repository objects may have changed in both DEV and PROD - which do you

choose?‣ These, and others, are called “merge conflicts”

Repository #1 Repository #2

Merged Repository







Oracle BI Repository Three-Way Merges

•Oracle BI, like many software development tools, uses the concept of three-way merges‣A modified repository, which is usually the PROD repository‣A current repository, which is usually the DEV repository‣An original repository, from which they were both derived

•Provides a number of benefits compared to 2-way merges‣Avoids “guessing” whether objects with the same

name are actually logically the same‣ For branching development, allows both branches

to be updated with subsequent changes to the original‣More accurate and efficient way of merging

two sets of objects with common parentage• If no common repository available, then substitute

blank repository (and loose the 3-way merge benefits)

Repository #1(“current”)

Repository #2(“modified”)

Merged Repository

Common ParentRepository(“original”)







Understanding Merge Rules

•The merge process makes most sense when you understand the merge rules•The RPDs you select for modified and current are important, do not choose at random‣Current = development, Modified = production

•Rules assume that changes added to modified want to be preserved•Deletions in current that are still in modified have to be confirmed•Additions added, or deletions from, both repositories are automatically propagated•Objects added to both, but with differences, cause a merge conflict•Objects modified in both cause a merge conflict

Repository #1(“modified”)Production


DevelopmentCommon ParentRepository(“original”)

Merged RepositoryNew Production

Merge







Repository Equalization

•Repositories may contain logically identical objects that have different upgrade IDs‣Upgrade IDs are internal ID codes for objects in the repository

•Can be caused by deleting, then recreating, the same object•Mismatching upgrade IDs can cause the upgrade process to create duplicates in the

merge repository, thinking that the two objects are completely different•Answer is to equalize the repositories

Sales Subject AreaUpgrade ID : 1001


Modified Repository(Production)

Current Repository(Development)

Modified Repository(Production)

Current Repository(Development)



Equalization

Merge

Merged Repository








Three-Way RPD Merge Step 1 : Open Current RPD, Select Merge

•Start the BI Administration tool•Open the Current (typically, Development) repository offline•Select File > Merge...







Three-Way RPD Merge Step 2 : Select Modified & Current RPDs

•With the Merge Repository Wizard - Select Import Files dialog open,select the modified (production) and original (common parent) RPDs

•Enter passwords•Tick the Equalize during merge checkbox•Select Full Repository Merge







Three-Way RPD Merge Step 3 : Resolve Conflicts

•Conflicts typically occur if a choice needs to be made between two options•Select the choice either from the modified (prod) or current (dev) repository•Choices can go down to the object property level•Once all conflicts resolved, merged repository is then opened for editing







New in 11g : Repository and Catalog Patching

• In some situations, you want to perform the merge hands-off•To remove opportunity for human error, to allow it to be scripted•11g introduces the concept of repository (RPD) and catalog patching•Whole process, from extracting changes to patching target, can be scripted

DevelopmentRepository

DevelopmentCatalog

ProductionRepository

ProductionCatalog







Repository Patching

•Repository patching is a two-step process1. Compare the current repository to the original one, create an XML patch file of the

differences between the two2. Apply the XML patch file to the modified repository, as a three-way merge

also using the original repository•Can be performed using BI Administrator tool, or from the command-line


Development


Compare


Repository #1(“modified”)Production

XML PatchFile of diffs

between Currentand Original RPD

XML Patch File

Merged RepositoryNew Production

Merge

1 2







Interactive Repository Patching using the BI Administration Tool

•To create the XML patch file, use the File > Compare... feature

•To apply the patch file, use the File > Merge... feature







Patching using BI Administrator Step 1 : Open Current RPD

•Usign the BI Administrator tool, open the current (development) repository offline•Select File > Compare...







Patching using BI Administrator Step 2 : Open Current RPD

•View comparison report•Press Equalize button if required







Patching using BI Administrator Step 3 : Generate Patch File

•Press the Create Patch... button to create the XML patch file







Patching using BI Administrator Step 4 : Open Modified RPD

•Now open the modified (production) repository, select File > Merge







Patching using BI Administrator Step 5 : Select Patch and Original

•With the Merge Repository Wizard - Select Import Files dialog open,select the original (common parent) RPD and the XML patch file‣Patch file substitutes for

the current repository•Select Patch Repository







Patching using BI Administrator Step 6 : Resolve any Conflicts

•As with full repository merges, you may then need to resolve merge conflicts•Same rules around current, modified and original RPD merge rules apply•Once resolved, merged repository

is then opened for editing







Command-Line Creation and Applying of RPD Patches

•Command-line utilities are avaialble for creating, and applying, RPD patch files•comparerpd creates a patch file based on current and original repositories

•patchrpd does a three-way merge with the patch file, original and modified repositories

•Both located at [middleware_home]\Oracle_BI1\bifoundation\server\bin\

comparerpd –P [current repository password] –C [current repository path and name] – W [original repository password] –G [original repository path and name] –D [patch file path and name]

patchrpd -P [modified repository password] -C [modified repository path and name] -Q [original repository password] -G [original repository path and name] -I [patch file path and name] -O [new repository path and name]







Scripted RPD Patching Step 1 : Generate Patch File

•Open a command-line prompt•Change directory to[middleware_home]\Oracle_BI1\bifoundation\server\bin\

•Run the comparerpd command

•View the console output

cd c:\middleware\Oracle_BI1\bifoundation\server\bin

comparerpd -P password -C c:\GCBC_Repository_updated.rpd -W password -G c:\GCBC_Repository_original.rpd -D c:\patch.xml

The following repository is opened: c:\GCBC_Repository_original.rpdThe following repository is opened: c:\GCBC_Repository_updated.rpd







Scripted RPD Patching Step 2 : Apply Patch File

•Open a command-line prompt•Change directory to[middleware_home]\Oracle_BI1\bifoundation\server\bin\

•Run the patchrpd command

•View the console output

patchrpd -P password -C c:\GCBC_Repository.rpd -Q password -G c:\GCBC_Repository_original.rpd -I c:\patch.xml -O c:\GCBC_Repository2.rpd

---------------Complete Success!!---------------

Complete Success of patch application on original repository!!The following repository is opened: c:\GCBC_Repository.rpdRepository equalized successfully.

[94017] Complete success of patch application on customer repository.







Version Control in Software Development Projects

•Version control is a common concept in software development •Allows you to store copies (versions) of project elements over time•Refer back to old versions, restore old versions, create named/numbered releases•Branch projects, re-combine branches•Typically peformed using tools such as PVCS, Subversion, Git, Visual Sourcesafe

Local copyof RPD

Version # 2.47

Version ControlSystem

RPD #1.22

RPD #2.45

RPD #2.47

RPD #1.30

RPD #1.35

Downloadworking

copy

Check-inchanges

Retrievehistorical

versions at will







Subversion and OBIEE 11g

•OBIEE 11.1.1.5 does not have in-built integration with version or source control•But you can store the various project artifacts in any version control tool•Subversion, together with VisualSVN Server and TortoiseSVN, are suitable tools•There are however some limitations‣ The RPD has to be uploaded in its entirety‣Although you can also upload XML patch files‣ The Catalog has to be archived before uploading‣You cannot use the merge/patch facility in SVN,

you must use BI Administrator / Catalog Managerpatch/merge instead







Creating a Subversion Repository for use with Oracle BI EE

•A standard subversion repository should be created for the OBIEE project•Create standard three directories‣ Trunk : the main development path for the project‣Branches : branches off of the main development path‣ Tags : named/numbered releases

•All top-level directories have subdirectories forRPD, catalog, config etc

Repository Name

Project Name

Project Name

Trunk

Branches

Tags

RPD

Catalog

Config

Project Name







Subversion Freeware Server and Client Tools

•Subversion is an open-source project, freely usable and downloadable‣ http://subversion.tigris.org/

•However you may wish to use freeware/open-source client & server tools with it•VisualSVN Server Standard Edition - Windows GUI for Subversion‣ http://www.visualsvn.com/server/

•TortoiseSVN - Windows shell extension for project checkout/check-in/branching etc‣ http://tortoisesvn.tigris.org/






http://subversion.tigris.org/

http://subversion.tigris.org/

http://www.visualsvn.com/server/

http://www.visualsvn.com/server/

http://tortoisesvn.tigris.org/

http://tortoisesvn.tigris.org/


Creating an OBIEE SVN Repository Step 1 : Install SVN

• Install Subversion, or a tool such as VisualSVN Server that embeds SVN and includes management tools

•Ensure that SVN server is up andrunning, ready for folder creation







Creating an OBIEE SVN Repository Step 2 : Create Repository

•Using the SVN admin tools, create a new repository (for example, GCBC)•Within the repository, create a project (for example, GCBC_OBIEE)•Within the project, create the standard three top-level folders‣ Trunk, Branch, Tags

•Within the Trunk folder, create sub-folders for major OBIEE project artifacts‣ RPD, Catalog, Config etc







Creating an OBIEE SVN Repository Step 3 : Define Security

•Create users and roles for SVN repository access•Some tools (e.g. VisualSVN Server) allow you to use Windows authentication•Define permissions on objects as required•SVN repository is then ready for use







SVN Development Lifecycle Step 1 : Checkout of Project Files

•Developer right-clicks on desktop, selects SVN Checkout...•Select trunk folder, or particular branch or tag•Select HEAD revision, or particular revision number•Files copied to version-controlled folders on desktop

1 2 3







SVN Development Lifecycle Step 2 : Edit Files, Upload to EM

•Files are then usually copied to a working directory, or uploaded to EM for online edits•Perform all changes as required, add or delete objects•Working copies can be updated using SVN Update•Objects are not specifically locked when you check-out, unless you choose to lock them•Ensure all changes are performed in relevant tools (BI Admin, Catalog Manager etc)•Once changes complete, copy back to SVN folders on desktop‣Ensure catalog is archived,

not left as folder + files







SVN Development Lifecycle Step 3 : Check Changes Back into SVN

•Once complete, new and changed files can be added back into SVN repository•Right-click on folders, select SVN Commit...•New files have to be added to the project to be included in check-in•Uploaded files get a new revision number‣ Text files are just stored as diffs‣Binary files (RPD, catalogs etc) are stored

in their entirety

1 23







Tagging Projects

•Particular revisions/versions can be “tagged” as a particular release‣Version 1.0‣Version 2.0 migrated to OBIEE 11.1.1.5

•Check out the top-level folders for a project (e.g. GCBC_OBIEE) for a particular revision•Right-click on the Trunk folder and select TortoiseSVN > Branch/Tag•Copy the folder to a new sub-folder under the Tags directory (for example, Rel. 1.0)

12 3







Branching Projects

•Projects can be branched in the same way as tagged•Create new sub-folder under the Branches folder•Used for when a copy of the project is made, then enhanced separately‣ For rolling out country-specific versions, with localizations‣ For working through an upgrade to OBIEE 11gR2, whilst still preserving the 11gR1

version• If you wish to merge the branch back into the Trunk folder, use BI Admin three-way

merge rather than SVN’s merge/patch feature

UK-Localized Branch

Repository OptimizationBranch

Test Upgrade Branch

Main Development Stream







Managing Change with Large Teams of Developers

•So far, we have looked at projects where there is a single developer•On many projects though, you wish to scale-up developers to deliver larger scope•The catalog supports multiple developers editing, adding objects etc•For smaller teams, you might consider concurrent online editing of the RPD‣Has the virtue of simplicity‣ 11g certifies up to 5 concurrent developers‣Works through a system of check-out

and check-in of objects- Check-out is coarse-grained though- Edits to a logical table lock the

whole business model

Test ProdDevSourceControl








Multi-User Development Environment (MUD)

•MUD Administrator divides main repository into projects; self-contained RPD subsets•Master repository is then published to a network share•Projects are then worked on independently,

and then merged back into the master RPD•Uses the repository compare and

merge features under the covers•Works best when each developer has a full

OBIEE “Sandbox” environment to develop with and unit test their work‣ License considerations through -

may require named user plus licensingto be financially viable

•More complex than online development,but makes sense when you know how it works







What Happens During MUD Check-Out / Merge / Check-In?

Developer Selects Projects(s)for checkout from Master RPD

Subset RPD + copy of Subset RPD copied to developer PC

Developer then edits theRPD, adds, makes changes

Subset RPD is then compared to the subset RPD copy

Local changes merged in to local copy of the master RPD,

merge conflicts resolved

Changes are published to the network Master RPD, and

lock taken during this merge







What Happens During MUD Check-Out / Merge / Check-In?

Developer Selects Projects(s)for checkout from Master RPD

Subset RPD + copy of Subset RPD copied to developer PC

Developer then edits theRPD, adds, makes changes

Subset RPD is then compared to the subset RPD copy

Local changes merged in to local copy of the master RPD,

merge conflicts resolved

Changes are published to the network Master RPD, and

lock taken during this merge

Change in 11g compared to 10g :Locking only now takes place

at the publish step, not merge of local changes







Setting up MUD Environment Step 1 : Define Projects

•Administrator opens the repository to be shared, offline•Select Manage > Projects•Define projects using selections of business model, or subject area, fact tables•Add init blocks, variables, users and other objects‣Physical layer objects get added automatically







Setting up MUD Environment Step 2 : Copy to Network Share

•Create network shared directory that is accessible to all developers•Set permissions so other users can write to it•Copy the file to this directory; this is now the “master” repository







Setting up MUD Environment Step 3 : Configure Workstations

•On each developer workstation, configure it for MUD access•Create a mapped network drive to the MUD network share folder•Select Tools > Options > Multiuser•Use Browse... to select the mapped network drive•Type in the name of the developer (for recording MUD updates, checkouts, locks)







MUD Lifecycle Step 1 : Select and Checkout Project

•From the developer workstation, select File > Multiuser > Checkout...•Select the project(s) to check-out•Name the subset RPD file (a temporary copy of the whole RPD is made here)•On save the subset RPD, plus a duplicate, is saved and the temporary copy removed

1

2

3

4







MUD Lifecycle Step 2 : Make Changes to Subset, Do Compare

•Make changes to the subset RPD, such as adding, deleting or modifying objects•After a time, use File > Multiuser > Compare with Original...‣Performs an automatic File > Compare... with the duplicate subset RPD

•Save your changes as normal•Upload to a sandbox OBIEE environment and run online if required







MUD Lifecycle Step 3 : Merge in Local Changes

•Once work is complete, select File > Compare > Merge in Local Changes•Merges your subset RPD in with a fresh copy of the master RPD‣Peformed using an automatic three-way merge‣ If there are merge conflicts, this is where you will deal with them

•Merged results are then stored locally until published by the next step•Change compared to 10g: lock is not taken at this step

Define Merge Strategy only displayed if

merge conflictsencountered







MUD Lifecycle Step 4 : Publish or Discard Changes

•After local changes have been merged into local copy of the master repository, these changes can then be merged in with the actual master repository‣Again performed using an automatic three-way merge

•Changes can also be discarded, or rolled-back (giving you the original subset RPD again)•At this point, the lock is taken (to stop multiple sessions trying to write to the master)‣Only taken briefly in 11g as in most cases, conflicts dealt with in previous step

• If master RPD has been updated since local merge, local merge is rolled-back and performed again







MUD Lifecycle Step 5 : Viewing MUD History

•Developers with MUD configured on their workstations can view the MUD history•See history of checkouts, check-ins, comments added during publish (lock) phase•Useful history of MUD activity







MUD and Version Control

• If MUD subset RPDs are part of the same development stream, store them as subdirectories under the main RPD directory

• If MUD is used for branching the project, create a branch using SVN, and then update the branch’s RPD with the one generated by the MUD branch check-out

Repository Name

Project Name

Project Name

Trunk

Branches

Tags

RPD

Catalog

Config

Project Name

MUD Subset RPD #1

MUD Subset RPD #2

MUD Subset RPD #3







Deploying Configuration Changes across Clustered OBIEE Systems

•Another aspect of managing change and deployments is at a system level•How do you apply configuration changes across multiple clustered nodes?•How do you deploy repositories when your BI servers are clustered?•How do you script the process so that it is automated?

TestDev Production Cluster

Developer Production Support







Project Deployment and Migration Best Practices

1. Use Enterprise Manager to deploy repositories and catalogs between environments2. Use Enterprise Manager to apply system configuration changes to environments3. Use WLST and the Oracle BI Systems Management API to script these tasks

cd (biinstance.toString())biserver = get('ServerConfiguration')cd('..')cd(biserver.toString())ls()argtypes = jarray.array(['java.lang.String','java.lang.String'],java.lang.String)argvalues = jarray.array(['C:/SampleAppLite.rpd','Admin123'],java.lang.Object)invoke('uploadRepository',argvalues,argtypes)

cd('..')cd('oracle.biee.admin:type=BIDomain,group=Service')objs = jarray.array([],java.lang.Object)strs = jarray.array([],java.lang.String)invoke('commit',objs,strs)







Managing the Oracle BI Repository and Web Catalog using EM

•Enterprise Manager is now used to deploy new RPD files (repository) and presentation catalog directories‣RPD files are uploaded using EM; catalogs have to be manually copied to servers

•Deploys metadata across all BI Server and Presentation Server nodes in the cluster (unless shared directories have been defined)







Deploying a New RPD Step 1 : Lock & Edit Configuration

• Using EM, select Capacity Management > Performance• Press the Lock and Edit Configuration button‣ Places an exclusive lock on the domain; you either then have to Activate changes, or

Release Configuration







Deploying a New RPD Step 2 : Select RPD, Enter Password

•Select Deployment > Repository•Press Browse to select repository (RPD) file•Enter repository password twice, then press Apply to save the change







Deploying a New RPD Step 3 : Activate, and Restart BI Server

• Press the Activate button to make the configuration changes• Restart the BI Server(s) to start using the new RPD online







Deploying a New Catalog Step 1 : Lock & Edit Configuration

• Using EM, select Capacity Management > Performance• Press the Lock and Edit Configuration button‣ Places an exclusive lock on the domain; you either then have to Activate changes, or

Release Configuration







Deploying a New RPD Step 2 : Select RPD, Enter Password

•Select Deployment > Repository•Type in path to the new web catalog•Press Apply to save the change







Deploying a New RPD Step 3 : Activate, and Restart BI Server

• Press the Activate button to make the configuration changes• Restart the BI Presentation Server(s) to start using the new catalog







System Configuration Changes using Enterprise Manager

•Most important system configuration settings are now managed through EM•Ensures that all changes you make are applied across all nodes in the cluster•Graphical interface for managing common settings including‣Caching and other performance settings‣Number and scale-out of system components across cluster‣Miscelaneous settings including # rows returned, read-only RPD etc

•Each BI environment has its own EM website,which manages all nodes in the domain







Performance Options Managed Through EM

• Query Cache Enabled | Disabled‣ Maximum Cache Entry Size ‣ Maximum Cache Entries

• Global Cache Path (used when clustering BI Servers)‣ Global Cache Size

• Disallow online RPD Updates• User Session Expiry (seconds)• Maximum Rows Processed (for Table View)• Maximum Number of Rows/Page (for Email)







Manually Managed System Configuration Settings

• Settings not managed by EM have to be manually managed by editing configuration files (NQSConfig.INI, instanceconfig.XML) etc‣ Populate Aggregate Rollup Hits (Cache)‣ Use Advanced Hit Detection (Cache)‣ Maximum Subexpression Search Depth (Cache)‣ Use Advanced Hit Detection (Cache)‣ Virtual Table Page Size

(for in-memory joins, calcs)• Be sure to deploy changes across all

system components on all nodes,and to not alter managed settings







How Does Enterprise Manager Work “Under the Covers”?

•Enterprise Manager uses the OBIEE 11g Systems Management API to perform administration tasks‣You can also use this API through WLST scripting, or through Java code

•Uses a set of JMX MBeans (Java Management Extensions) to perform tasks‣MBeans are Managed Beans, Java utilities

that have properties and methods‣Every EM task has a corresponding

MBean method‣Some MBeans have yet to be

exposed through EM







The Oracle BI Systems Management API

•A collection of MBeans used for providing systems management functions for OBIEE•A subset of the wider range of MBeans in Fusion Middleware 11g•Key Systems Management API MBeans include‣ServerConfigurationMBean : upload and register new repositories‣BIDomainMBean : lock, commit and rollback changes to OBIEE config‣BIInstanceMBean : Start, stop and restart components‣BILogConfigurationMBean, EmailConfigurationMBean etc







Invoking an MBean using WLST

•All Simple BI WLST scripts have the same common structure1. Connect to the WLS Admin Server (connect)2. CD to the correct Systems Management API MBean3. Prepare input array for invocation4. Prepare output array for invocation5. Call the MBean method

connect("weblogic","welcome1","localhost:7001")domainCustom()cd ('oracle.biee.admin')cd ('oracle.biee.admin:type=BIDomain,group=Service')biinstances = get('BIInstances')biinstance = biinstances[0] cd ('..')cd ('oracle.biee.admin:type=BIDomain,group=Service')objs = jarray.array([],java.lang.Object)strs = jarray.array([],java.lang.String)invoke('lock',objs,strs)cd('..')







Scripting EM Operations using WLST and the Systems Mgmt API

•All calls to the Oracle BI Systems Management API can be scripted through WLST•Command-line tool using Jython as the scripting language








Scripting EM Operations using WLST and the Systems Mgmt API

•All calls to the Oracle BI Systems Management API can be scripted through WLST•Command-line tool using Jython as the scripting language


Lock method

• Create lock on Oracle BI Domain, prior to configurationchange







WLST Script Continued












uploadRepository Method

• Obtain next RPD sequence no.• Copy the RPD name and

password into the MBeanproperties










commit Method

• Activate configuration changes• Upload the RPD• Update config files• Store password in Credstore







Other Useful Uses of WLST Scripting

•Stopping, starting and restarting the BI Instance•Stopping, starting and restarting individual components•Changing the web catalog path•Creating roles and mapping them to LDAP groups•Enabling and disabling caching•Setting other performance parameters•Vertical and horizontal scaleout







Summary

•Projects that scale beyond a single developer need deployment & change management•Many tools are available within OBIEE 11g to handle multi-developer teams•Keep things as simple as possible; but if required, there is MUD•Key to MUD is understanding what goes on when you check-out/check-in projects•11g introduces far less intrusive locking, makes MUD more viable•The lack of in-built version control can be overcome with tools such as Subversion•Always use EM to propagate system changes, and if required, script with WLST.







More Information

• Thank you for attending this presentation• More information can be found at http://www.rittmanmead.com• Contact us at [email protected] or [email protected]• Look out for our book, “Oracle Business Intelligence Developers Guide” due Q1 2012• Follow-us on Twitter (@rittmanmead) or Facebook (facebook.com/rittmanmead)













Mark Rittman, Technical Director, Rittman MeadOracle OpenWorld 2011, San Francisco, October 2011

OBIEE Deployment & Change Mgmt Best Practices






Change Management Rittman Mead

Documents

Transcript of Change Management Rittman Mead