Welcome as the changes to OBIEE 12c are, the day after install generated for me basic questions to where things went and how things work. Tasks like restarting the system, checking status and moving repositories/catalogs are quite different in 12c. At least they are different enough to have me searching the file system for file names and processes I’ve used since nQuire. The changes in 12c are not as dramatic as going from OBIEE 1og to 11g, but the following items were on the short list of things that held my attention before moving on to building repositories and creating dashboards.
- Restarting all or part of the components
- Checking the status of components
- Location of logs and configuration files
- Deploying repositories and catalogs
Along the way the topic of OPMN’s departure surfaced a some additional questions.
- What is a service instance?
- What are BAR files?
The VM used in the following is windows server 2012, but linux locations and commands are the same in concept.
Let’s take a look.
Starting Components
Let’s start with the scripts to start the weblogic servers. There’s a short list of scripts I’ve come to expect to be there.
Their new location is:
C:\Oracle\Middleware\Oracle_Home\user_projects\domains\bi\bin
There’s a lot of scripts here, but I recognized these guys:
- setDomainEnv.cmd
- startManagedWebLogic.cmd
- startManagedWebLogic.cmd
- startNodeManager.cmd
- startWebLogic.cmd
Using these scripts Weblogic did come up allowing me to log into the console. And about right here my brute force approach hit a snag.
What about system components now? The familiar <Middleware_Home>/instances folder is no more. So long OPMN. Which led me to pause a moment and refer to the documentation. For 12c we have a new set of scripts to start/stop components located at:
DOMAIN_HOME/bitools/bin
Let’s start the system from zero with nothing running.
A couple of surprises happen here. First, if node manager is not running, start.cmd will start it. Second, more started than expected. Expecting just weblogic servers to start, this status shows up at the end.
Not only does AdminServer and bi_server1 start, but the system components start as well.
Checking Status
In the same directory there is a status.cmd which will report the current status. It will report status just as reported at the end of the above start.cmd results.
Stopping Components
Stop.cmd with no arguments stops everything. What about stopping one component from the command line? With 11g opmn it was a clumsy, wordy command.
Let’s stop BI server(obis1) using the command:
stop.cmd –I obis1
And the status command will show:
Multiple components can be started/stopped. For example:
start.cmd -i obis1,obips1
More information on the start and stop syntax is here.
Using EM for Status and to Start/Stop Components
The look and feel of 12c EM is updated, but very similar to 11g EM. Our last system status has BI server(OBIS1) down.
Since the look and feel is familiar, I won’t screen shot whip you, but I will say that system component restarts within EM 12c for OBIEE system components are fast. This was painful and mysterious in 11g often leading one to open a status command line window to try to figure out what is taking so long. Within 12c EM, component starts/stops are fast as in within 3–5 seconds. Start all and Stop all within EM also happened in under a minute each.
Configuration Files
The domain home location in my default Windows install is:
C:\Oracle\Middleware\Oracle_Home\user_projects\domains\bi
Most of the system component type configurations are now located in:
<DOMAIN_HOME>\config\fmwconfig\biconfig
12c has most everything you’d look for under a domain folder location instead of the 11g’s splitting servers/components up into domains and instance locations.
C:\Oracle\Middleware\Oracle_Home\user_projects\domains\bi\servers
Log File Locations
Logs, for the most part, live under the domains leg of the directory structure.
Some familiar logs names such as nqserver.log and nqquery.log have changed, but logs are all in one place now and a little easier to get at. I shall not miss the vile coreapplication click through folder in the 11g folder structure.
Here’s an example of the 12c bi server log folder.
Weblogic servers AdminServer and bi_server1 12c log folder contents as compared to it’s 11g pre-cursor are almost identical for location and filenames.
12c BI Repository(RPD) Files
My first clue to the big change was not finding the deployment tab in Enterprise Manger.
While I’ll admit that I looked in Enterprise Manager for a deployment tab until it got awkward. No longer are repositories deployed from Enterprise Manager. Before looking at exactly how it’s done in 12c, it’d be good to understand what’s different in 12c and where things live now in the absence of OPMN and OPMN’s instances directory structure. In its place, we have service instances.
Service Instances
For 12c all metadata, content and security provisioning reside under a service instance. There’s a lot of methods available for service instances, but for now let’s keep it simple and look at what goes into a service instance.
Authmodel is the home of the jazn-data.xml file. Within it’s weirdly named contents lives the roles we see in Enterprise Manger referred to as the authorization model.
Content is the home of the web catalog folder and a messages(msgdb) folder referred to as the content model.
Datamodel is the home of the current BI Server repository file referred to as the, surprise, the data model.
BAR Files
If you export your service instance, you are exporting the authmodel, content and datamodel’s information into a single Business Intelligence Archive File(BAR). There’s a lot to say here on BAR files, but for now BAR files make it easy to export the Big 3(auth model, content model, and data model) from one environment and import it into another environment. If anyone has ever migrated security roles between environments, then surely you can appreciate that being able to do all this in one export and one import command line call is SO NICE!
BAR File Export Syntax
exportServiceInstance(domainHome serviceInstanceKey workDir, exportDir, applicationModuleName, applicationModuleDesc, applicationModuleVersion, includeCatalogRuntimeInfo, includeCredentials)
BAR File Import Syntax
importServiceInstance(domainHome, serviceInstanceKey, barLocation, importRpd, importWebcat, importJazn, includeCredentials, includeCatalogRuntimeInfo, includeCredentials)
As always with oracle methods, some parameters are optional. Not all are required. Bar files and the many BAR file methods deserve there own post at some point.
Let’s move on to download and upload a repository file.
Upload/Download Repository
There is a new command line script for downloading/uploading RPD files to the service instance named “data-model-cmd-cmd”.
Can’t I Just Grab It From File System?
No you may not! Apparently there is a slight of hand deal going on and the repository password on the repository loaded to the service instance is unknown.
What we find are these files in the default installed service instance:
If you open the filename “liverpd.rpd” in the admin tool you’ll find that it is an empty repository. It will mysteriously disappear in the steps to follow.
Try as you might to open the filename “liverpd.rpd_1” and you’ll find that the password is a state secret. Renaming the file to “liverpd.rpd” is a no go as well. All attempts resulted in “Login Failed” on entering an RPD password.
What is going on?
To find out, let’s download the RPD file, change it and load it back. I’ve updated the PATH variable with the location of the bi tools scripts to make it easier to call from the C:\temp directory.
Download syntax is:
downloadrpd -O RPDname [-W RPDpwd] -SI service_instance -U cred_username [-P cred_password] [-S hostname] [-N port_number] [-SSL] [-H]
Download Example:
data-model-cmd.cmd downloadrpd -O liverpd.rpd -W Admin123 -U weblogic -P Admin123 -SI ssi
A file named “liverpd.rpd” is downloaded to the local directory c:\temp as requested. The downloaded file size does not match either of the service instance files, but comes closest to the file we cannot open “liverpd.rpd_1”. The downloaded file is not the same exact file loaded to the service instance.
We can open the downloaded rpd file c:\temp\“liverpd.rpd”.
So let’s whack the subject area “Sample Targets Lite”, rename the rpd to “liverrpd_modified.rpd” and change the rpd password to “Admin456”(File/Change Password) and reload it.
Let’s take note of what’s in the obis1 log directory. HINT: A clue will appear here after upload.
Upload the RPD
Upload syntax is:
uploadrpd -I <RPDname> [-W <RPDpwd>] -SI <service_instance> -U <cred_username> [-P <cred_password>] [-S <hostname>] [-N <port_number>] [-SSL] [-H]
Upload Example:
data-model-cmd.cmd uploadrpd -I liverpd_modified.rpd -W Admin456 -U weblogic -P Admin123 -SI ssi
And the OBIS1 log directory?
We have a password change log and and XML Gen log. The logs do not have any specifics as to what happened and in what order, but I’m guessing that the loaded RPD file’s password is changed and a new RPD file was generated and placed in the service instance.
The file loaded is not named “liverpd_modified” in any way. Under 11g the current or “live” rpd kept the filename as selected from the file system with sequence numbers appended to the end. In 12c the newly loaded RPD file is “liverpd.rpd_2”. Each new 12c load increments the number.
The empty RPD file from earlier “liverpd.rpd” curiously disappears, but does not seem to be important.
One last interesting difference in 12c concerning reloading server metadata.
I had an open session to OBIEE in the browser. To my surprise, the newly loaded RPD is live without having to restart the OBIS1 process and without having to reload server metadata.
Create new analysis shows that only one subject area “Sample Sales Lite” is available which matches the the “liverpd_modified.rpd” file we loaded.
There you have it. We’ve covered some basic what’s going on behind the scene’s in OBIEE 12c and covered just a few of the day 1 necessities of starting/stopping and loading RPD files. I think the start/stop scripts are easier to use and less cumbersome. I’m interested to see how using the BAR files to migrate between environments works out in various real world scenarios, but the concept alone is impressive. Uploading/Downloading RPD’s from the command line will take some getting used to. It’s early on for me, but I’m liking what I’m seeing in OBIEE 12c.
Until next time, RDWHAHB! Cheers!
