What are you in for when migrating from OBIEE 11g to 12c? Short answer is there is a lot less pain going from 11g to 12c than there was going from OBIEE 10g to 11g. The upgrade to 12c is an out of place upgrade as was the 10g to 11g which means new software install followed by migrating/upgrading 11g artifacts(web catalog, RPD file and permisssion) to the 12c versions.
If you’re new to these upgrades, here is a super-short outline:
- Check Software/Hardware Pre-requisites.
- Install the OBIEE 12c software.
- Export/migrate the 11g artifacts in the form of an export bundle.
- Import the export bundle from the 11g system into the 12c system.
- Test everything out in 12c.
- Re-mediate any conversion issues.
- Go Live
I won’t go into excruciating detail about planning steps, but I will offer up that the re-mediate any conversion issues phase for most OBIEE 12c upgrade projects should be way less work. Some quick reasons why are;
- User interface jump from 11g to 12c far shorter than the user interface jump from 10g to 11g.
- The export bundle takes care of moving everything in one export/import operation. This includes OBIEE content as well as BI Publisher content.
- Security migration(application roles) is included in the export bundle process and
- The 12c upgraded dashboards look very close to their 11g predecessors.
Quick Tech Hammer Warning
There’s quite a bit of detail that below. If you’d like to jump to the Cliff Notes version of how this goes down. See the “Import Review Time” Section near the end. It has a bullet list of upgrade steps and some before and after screen shots. The very last section has the quick-hit take aways.
Gotcha Time
Weblogic does not have a path for upgrading from the versions that come with OBIEE 11g (10.3.x) to Weblogic 12c. As a result, anything configured in the console is a re-do in this migration.
- Security realm configuration(Authentication, Authorization, etc.)
- Local weblogic users/groups will need to be exported from the 11g console and imported to 12c console.
- Additional deployments beyond out-of-the-box such as analyticsRes will need to be re-configured.
- Integrations such as APEX and ADF will need to be re-configured.
In short, if you touched it in 11g weblogic console, it’s gotta be touched in 12c weblogic console.
Usage Tracking data, Agent schedule data and BI Publisher schedule data are migrated manually. Links to the post-migration tasks are included at the end of this post.
Not a gotcha, but BISystemUser as a named user in security configuration is gone. It is a non-player in Weblogic/OBIEE 12c security configuration. Also gone are user GUIDs. Yes, free up that part of your mind that knows of refreshing the user GUIDs.
What’s the Starting Point?
All of these activities below are after OBIEE 12c installed. If you’re curious about the install, have a look at blog post by fellow red-pillian Fahd Saeed. The blog can be found here. Also, both the 11g OBIEE system and the 12c OBIEE system are completely down.
Let’s Migrate Some Stuff!
BI Migration Tool JAR
There is a utility jar to be executed on the OBIEE 11g system. My chosen platform for my OBIEE 12c sandbox adventures happens to be Windows Server 2012R2. Funny thing happened on the way to creating my first BI Migration Tool Jar file.
Right about here the Oracle doc’s say to run a migration-tool.sh command. It says to run a shell script. I’m on windows, so I will change it to the windows command script version which is sits right next to it on the file system.
So the Oracle doc says to run this:
ORACLE_HOME/user_projects/domains/bi/bitools/bin/migration-tool.sh package bi-migration-tool.jar
My command is executed from where the command script lives.
Change Directory to where the script lives.
cd c:\Oracle\Middleware\Oracle_Home\user_projects\domains\bi\bitools\bin
Execute the Windows version of the migration-tool command line.
migration-tool.cmd package bi-migration-tool.jar
And what had happened was…
An error message stating that the jar file must be must be called from migration-tool.sh? Not happening on Windows! Swear jar deposit happens here.
Try as I might to get around this, I could not. I tracked down the scripts to the front door of the java classes. This message is happening inside the java classes, so no joy. Not interested at this point to ask WHY, ORACLE, WHY?
So…..
Downloaded the linux VM Sample App 12c, I did. Fired it up an executed the same command line(sh version, of course) and success. Swear jar, I want my money back!
Now we have a bi-migration-tool.jar file. The next step is to move it to the 11g system.
So my VirtualBox arsenal contains the OBIEE 11g sample app powered by linux. The OBIEE version on this VM is 11.1.1.7.x. The bi-migration-tool.jar file is now copied to the 11g VM’s /tmp directory.
Next we’ll run an export command on the 11g system to create our export bundle.
Making the Export Bundle
The main command is
java -jar ./bi-migration-tool.jar out $ORACLE_HOME $DOMAIN_HOME ./test_export.jar
Here’s the output below. It includes some environment variable checks. Just to live curiously, I let the OS java(instead of OBIEE’s) do the work. Note the output reports the log location of this operation.
[oracle@demo tmp]$ echo $ORACLE_HOME
/app/oracle/biee/Oracle_BI1
[oracle@demo tmp]$ echo $DOMAIN_HOME
/app/oracle/biee/user_projects/domains/bifoundation_domain
[oracle@demo tmp]$
[oracle@demo tmp]$ which java
/usr/bin/java
[oracle@demo tmp]$ java -jar ./bi-migration-tool.jar out $ORACLE_HOME $DOMAIN_HOME ./test_export.jar
Oracle BI Migration Tool
Oracle BI Migration Tool
Logging to: /app/oracle/biee/user_projects/domains/bifoundation_domain/bilogs/migration/migration-2016–02–24–14–26–29.log
Performing export with top-level install directory/app/oracle/biee, domain
home=/app/oracle/biee/user_projects/domains/bifoundation_domain, output file = ./test_export.jar
Removed the node credstore
Removed the node keystore
Find the policy store node policystore.xml
Removed the node audit
Removed the node trust
Removed the node pdp.service
Removed the node attribute
Removed the node idstore.ldap
false
Successfully created file /app/oracle/biee/user_projects/domains/bifoundation_domain/config/fmwconfig/jps-config-migration.xml
Migration policy store executed successfully: [policyStore, /app/oracle/biee/user_projects/domains/bifoundation_domain/config/fmwconfig/jps-config-migration.xml, default, policystore_dest_context]
Export succeeded
Migration action succeeded
[oracle@demo tmp]$ ls -l test_export.jar
-rw-r — r — 1 oracle oinstall 207750473 Feb 24 14:28 test_export.jar
Export Bundle Contents
What’s in this export bundle thing? Free archiver 7-zip will help answer this surprisingly well.
The export bundle has a ton of scripting files and a ton of class files which are either unreadable due to binary-ness or just not good reading.
However, In the top level of the archive we find an 11g and 12g version of the BI Server config files(NQSConfig.INI). Just marking as interesting and moving on.
Down the PluginData leg of the folders we find our Business Intelligence Archive(BAR) file. It’s a new feature for OBIEE 12c(here).The metadata.bar file contains the 3 main artifacts for our upgrade.
The first artifact is our system-jazn-data.xml file containing our Application Roles & Policies from our source OBIEE 11g system.
Next up is our OBEE 11g web catalog file, live.cat, in catalog archive format along with a custom messages zip file, msgdb.zip.
The third artifact is our OBIEE 11g RPD file, live.rpd, upgraded to the 12c version. It’s pretty big!
The 12c admin client will open this packaged RPD file with the 11g system’s repository password.
Import Options
There are two options for importing this information. The first is to include the import bundle during the configuration of the OBIEE weblogic domain(i.e. Configuration Assistant). If you like the 2 for 1 aspect of configuring the domain and importing your 11g artifacts in one go, then the details are here. My personal preference is to get OBIEE 12c up with the defaults and then have a go at the export bundle.
This second option happens after OBIEE 12c is installed and configured. Our export bundle file(test_export.jar) is copied to the target 12c Windows VM to the C:\TEMP directory. The command is executed from where the script lives under bitools\bin.
Import Command
Here’s the command line for the import:
Change directory to bitools\bin.
cd c:\Oracle\Middleware\Oracle_Home\user_projects\domains\bi\bitools\bin
Execute the import.
migration-tool.cmd in c:\temp\test_export.jar ssi
NOTE: The first argument is “in” for import. Second argument, “c:\temp\test_export.jar”, is the path to the export bundle. The third argument, “ssi”, is the name of the out-of-the-box 12c service instance. If you have any doubts about what your service instance name is, then check the file path on your system at the location shown in the image below.
Example: c:\Oracle\Middleware\Oracle_Home\user_projects\domains\bi\bidata\service_instances
OBIEE 12c Service Instance Folder
Once you execute the migration-tool.cmd(windows) or migration-tool.sh(linux) command, it will ask for the OBIEE 11g repository password. A couple of beats after that it will be DUNZO(a.k.a done)!
A quick scan of the log located at DOMAIN_HOME\bilogs\migration\migration-2016–02–24–17–01–51.log reports no errors during import.
Import Review Time
Quick re-cap of how we have at this point.
- An linux VM running the OBIEE 11g sample app on which we exported the 11g metadata(Security Roles/Policies, RPD,Web Catalog) into an export bundle(test_export.jar)
- This export bundle is copied to the newly created OBIEE 12c system which before the import contains the out-of-the-box Sample Sales Lite Subject Areas and out-of-the-box security.
- The migration-tool script took the information in the export bundle and imported the security information(Roles/Policies), the web catalog and the RPD file into this clean Windows 2012 OBIEE environment.
- It’s important to note that this import does not import along side the old content. It completely replaces the content(Security,Web Catalog, RPD).
- I’ve change the connection information in our new OBIEE 12c RPD to connect back to the 11g system.
In short, we have the 11g artifacts running on a new 12c system, and the 12c system is using the 11g system’s data sources.
OBIEE 12c Before and After Import
Here’s what we have before importing our export bundle. The import will replace security roles/polices, RPD and web catalog.
OBIEE 12c Dashboards Upgraded from 11g
Here’s what it looks like. Click images to see larger views. The images are in pairs(11g/12c) and labeled in red at the top.
If you’re familiar with the 10g to 11g upgrade, note that the OBIEE and BI Publisher content came over in one import instead of the separate steps previously required.
Post-Migration Tasks
These tasks are very similar to tasks performed with the 10g to 11g upgrade.
There is a list of tasks to Perform for:
Sum It Up Already! What Just Happened?
Outside of the one windows script error, the migration steps went smoothly. All 11g metadata imported without issue and in one pass. Once the dashboards fired up in 12c, the differences were minor. From what I could see, the 12c dashboard layouts and functions looked and performed the same as the 11g versions unlike the 10g to 11g upgrade where things looked and functioned quite differently in many cases. In migrating the sample app from 11g to 12c, there were no errors on the dashboards due to missing or failed migration content.
Test it out for yourself, but you will probably spend much less time re-mediating reports and dashboards with the 11g to 12c migration than with the previous 10g to 11g migration.
So with the extra time, I think I’ll RDWHAHB! Cheers!
