[OBIEE 11g] About Enterprise Manager

About Enterprise Manager in OBIEE 11g

An OBIEE 11g system (or “Oracle BI Domain”) is generally managed through a combination of Oracle Enterprise Manager Fusion Middleware Control, part of the Enterprise Manager “family”, or through WebLogic Server Scripting Tool (WLST) scripts. Each Fusion Middleware Control instance as shipped with OBIEE 11g controls a single Oracle BI Domain (DEV, or PROD for example), and is installed along with WebLogic Server Admin Console in the WebLogic Admin Server, one of the two JVMs (the other being the managed server) that gets installed by default with OBIEE 11g. The screenshot below shows Fusion Middleware Control showing the status of the BI Server, Presentation Server and other system components within the installation.

So how is Enterprise Manager Fusion Middleware Control showing this information, and how does it perform the various OBIEE administration functions? And where does WebLogic Scripting Tool come into this?

The key to all of this is another java component that’s also installed on the WebLogic Admin Server; the JMX Admin MBeans. JMX (or “Java Management Extensions”) is a technology used for monitoring and managing J2EE systems such as Oracle Business Intelligence 11g, and the MBeans (or “Managed Beans”) are java objects that have properties (such as “the system is locked”) and methods (for example, to upload a new repository). Enterprise Manager Fusion Middleware Control is a Java application that can make use of MBeans, and in fact every operation that Fusion Middleware Control performs for you when you use it to administer an OBIEE 11g system, is actually done through an invocation of one of these MBeans.

The same goes for WebLogic Scripting, which uses Jython scripts and the WebLogic Scripting Tool command-line environment to call various MBeans to perform scripted operations. Both Enterprise Manager and WLST therefore get their abilities from calling, and reading, these MBeans, and understanding how these work is really the key to scripting and automating the administration of an OBIEE 11g system.

You can take a look at the various MBeans that are provided with OBIEE 11g through the MBean Browser. To access this, within Fusion MIddleware Control right-click on the AdminServer entry under the Farm_bifoundation_domain > Weblogic Domain > bifoundation_domain menu entries, and select MBean Browser, like this:

Within the MBean Browser, if you navigate to Application Defined MBeans > oracle.biee.admin, you’ll see the list of MBeans that are used by Enterprise Manager, and utilities like the Config.bat configuration tool that runs after the Universal Installer and creates, or extends, an Oracle BI Domain.

So how, in practice, does Enterprise Manager Fusion Middleware Control use these MBeans to, for example, upload a new Oracle BI Repository file and take it online?

To start off, if you were going to use Enterprise Manager to upload a new repository, you would navigate to the Deployment > Repository tab within Enterprise Manager, and press the Lock and Edit Configuration button, like this:

When you press this button, Enterprise Manager calls the lock method provided by the oracle.biee.admin:type=BIDomain,group=Service MBean, to lock the configuration of the Oracle BI Domain. This exclusive lock prevents any other administrator from trying to make other configuration changes, and is held until either you press the Release Configuration button (equivalent to the rollback method from the same MBean, or you press the Activate button.

You can invoke this same method from either a Java program or WLST script, or directly using the MBean Browser itself:

Calling the lock method then sets the Locked attribute for the same MBean, which triggers the display of the Activate Changes and Release Configuration buttons in Enterprise Manager.

Once you’ve locked the Oracle BI Domain, you would then use the same screen back in Enterprise Manager to browse and select the RPD file, and then enter the password, twice.

Once you’ve entered these details you would then press the Apply button, to save the changes. At this point, the RPD gets a sequence number after it, and it’s displayed as the current default online repository for the Oracle BI Domain.

So what’s gone on in the background to make this happen? When you press the Apply button, another MBean method gets called; this time, the uploadRepository method from the oracle.biee.admin:type=BIDomain.BIInstance.ServerConfiguration,biInstance=coreapplication, group=Service MBean.

This MBean takes the two parameters that you entered into Enterprise Manager, or that you can enter directly into the MBean Browser yourself:

When you call then method, it reads the value of the DataZipFileVersion attribute within the oracle.biee.local:Location=bi_server1,type=DomainConfigProxy,group=Config MBean, and increments it by one, to get the sequence number it appends to the RPD file name.

Once the uploadRepository method is called, you can see the name of the uploaded repository in the MBean’s Repository Name attribute:

At this point though, your RPD file is still sitting in the original place on your filesystem, and the various configuration files have yet to be updated, let alone the RPD uploaded or put online. To do this, you would press the Activate Changes button on the Enterprise Manager page, like this:

Pressing this button calls the commit method within the oracle.biee.admin:type=BIDomain,group=Service MBean (the same one that provided the lock method). This method takes a parameter that requires a literal (such as ERROR) to specify the error threshold for the operation.

Running this method from the MBean browser should bring back the Operation executed successfully message.

Behind the scenes, when this method is invoked, a number of things happen:

1.      The biee-domain.xml file (the central configuration file for the MBeans) under C:\Middleware\user_projects\domains\bifoundation_domain\config\fmwconfig will have been updated with the details of the new RPD. 

2.      The new RPD file will have been copied into the biee-data.zip file, within the same file, and then transferred via this archive file to the Repository directory within your coreapplication_obisn directories, with the sequence number appended to it.

3.      Each BI Server’s NQSConfig.INI file will also have been updated with the name of the repository, as well.

4.      The Credential Store will have been updated with the password for this particular RPD, so that the BI Server can obtain access in the future.

Something we’ve not worked out yet, but think might be the case, is whether this method directly updates the NQSConfig.INI file itself (or indeed any other system component configuration files), or whether another MBean monitors or reads the central configuration file and then updates the NQSConfig.INI file as a separate process. We think the latter might be the case, as this would also explain how the Admin Server can update all the system component files with the “correct” settings from the central configuration file when you do a reboot, and you’ve manually changed system component parameters that supposed to be exclusively managed by Enterprise Manager.

At this point, if you return to Enterprise Manager, you’ll see that the Activate Changes button has changed back to Lock and Edit Configuration, but there’s now a Restart to apply recent changes message instead. This is because the RestartNeeded attribute value in the oracle.biee.admin:type=BIDomain,group=Service MBean has now been set to True.

In Enterprise Manager, you’d clear this message (and restart the BI Server, to pick up the configuration changes in the NQSConfig.INI file) by either navigating to the Overview page and selecting Restart, or navigating to the Capacity Management > Availability tab, selecting the BI Servers row, and pressing Restart Selected. Only a full restart of all system components will clear this message though, and this is carried out using another MBean, this time oracle.as.management.mbeans.opmn:Location=AdminServer,name=instance1,type=opmn which has methods for stopping, starting, restarting or showing the status of all, part or single system components.

I therefore run the stopProcess method first, using the version that requires no parameters and stops all of the system components in the Oracle Instance, and the MBean browser shows the success message afterwards.

I then run the corresponding StartProcess method (restartProcess doesn’t seem to actually do anything, same goes for restarting through either Enterprise Manager or opmnctl with 11.1.1.3), and then finally log into the dashboard to see my new subject areas.