[OBIEE 11g] Basic System Administration

 

www.sssbi.com

OBIEE 11G Basic System Administration

In OBIEE 10g administrator,  administration tasks were mostly performed either through the Administration tool, the web-based Presentation Server administration screen, or through editing files in the filesystem. OBIEE 11g addresses these by where possible moving administration and configuration into Fusion Middleware Control (also referred to as Enterprise Manager).

To start off with something familiar, the Administration tool that was present in OBIEE 10g is also present in 11g, is also Windows-based, and is used to maintain the semantic model used by the BI Server. Here’s a screenshot of the 11g version, showing the SampleApp and some of my own subject areas:

This tool is more or less the same, and has some enhancements in terms of dimension handling, new data sources and the like. A big change though is around security; now when you bring up the Security Manager dialog, it looks like this:

Users and Application Roles (roughly analogous to groups in 10g) are now defined in the WebLogic Server admin console, and you use the Security Manager to define additional links through to other LDAP servers, register custom authenticators, and set up filters and other constraints. In the above screenshot, the users shown in the Users list are those that are held in WebLogic Server’s JPS (Java Platform Security) service, and there are no longer any users and groups in the RPD itself. Notice also that there is no Administrator user – instead the standard administrator user is the account that you set up as the WebLogic Server administrator when you installed OBIEE, which typically has the username weblogic. There are also two additional default users; OracleSystemUser is used by the various OBIEE web services to communicate with the BI Server, and BISystemUser is used by BI Publisher to connect to the BI Server as a data source (both default to the same password as the weblogic admin user you set up during the install).

If you switch to the Application Roles tab, you’ll also see a list of new default application roles; BISystem, BIAdministrator, BIAuthor and BIConsumer, which are used to grant access to Presentation Server functionality and also encompass the old XMLP_* groups that you used to get in 10g that were used to manage access to BI Publisher. There’s also AuthenticatedUser which is the same as found in the previous release. So how do you create a new user in OBIEE 11g? For that you’ll need to start up the web-based WebLogic Server admin console.

To create a new user, log on to the WebLogic Server admin console (http://localhost:7001/console) and bifoundation_domain > Security Realms from the Fusion Middleware Control menu. Then from the list of security realms, select myrealm, and then from the Settings for myrealm dialog select Users and Groups, and then Users, from the tab menu, You are then presented with a list of existing users.

Pressing the New button brings up a dialog where you can enter the user’s details, and you can also use the Groups tab to define a group for the user, or assign the user to an existing group. Security is quite a bit of a big change in 11g and in addition, we have the Application Roles setting that you saw in the Security Manager screenshot, which you then map to the groups in WebLogic. I’ll cover security in a future posting, but for now, this is how to define basic users and groups.

Another area that’s changed significantly where configuration files and metadata files are stored. In OBIEE 10g, you had two top-level folders, $ORACLEBI and $ORACLEBIDATA. $ORACLEBI (typically installed, for example, in c:\oracle\oraclebi) would hold binaries and configuration files for the BI Server, plus other components such as BI Publisher and JavaHost. $ORACLEBIDATA (installed, typically at c:\oracle\oraclebidata) would hold binaries for the Presentation Server, config files for the Presentation Server, plus cache files and temporary files for the BI Server. In OBIEE 11gR1 the filesystem changes, with the diagram below showing the high-level filesystem layout for a Windows installation at c:\Middleware:

So where are the key files that we are used to working with? Taking my installation on Microsoft Windows 2003 Server, and with OBIEE 11gR1 installed at C:\Middleware, here’s where my key files are located:

• RPD Directory : C:\Middleware\instances\instance1\bifoundation\OracleBIServerComponent\coreapplication_obis1\repository
• NQSConfig.INI : C:\Middleware\instances\instance1\config\OracleBIServerComponent\coreapplication_obis1\nqsconfig.INI
• NQClusterConfig.INI : C:\Middleware\instances\instance1\config\OracleBIApplication\coreapplication\NQClusterConfig.INI
• nqquery.log : C:\Middleware\instances\instance1\diagnostics\logs\OracleBIServerComponent\coreapplication_obis1\nqquery.log
• nqserver.log : C:\Middleware\instances\instance1\diagnostics\logs\OracleBIServerComponent\coreapplication_obis1\nqserver.log
• nqsserver.exe : C:\Middleware\Oracle_BI1\bifoundation\server\bin\nqsserver.exe
• Webcat Directory : C:\Middleware\instances\instance1\bifoundation\OracleBIPresentationServicesComponent\coreapplication_obips1\catalog\
• instanceconfig.xml : C:\Middleware\instances\instance1\config\OracleBIPresentationServicesComponent\coreapplication_obips1\instanceconfig.xml
• xdo.cfg : C:\Middleware\instances\instance1\config\OracleBIPresentationServicesComponent\coreapplication_obips1\xdo.cfg
• sawlog0.log : C:\Middleware\instances\instance1\diagnostics\logs\OracleBIPresentationServicesComponent\coreapplication_obips1\sawlog0.log
• sawserver.exe : C:\Middleware\Oracle_BI1\bifoundation\web\bin\sawserver.exe

Taking a look at tthe NQSConfig.INI file, whilst the format is the same, notice how many of the parameters are now marked as being managed by Enterprise Manager (Fusion Middleware Control):

 

Now these are parameters that you’re supposed to change only through Fusion Middleware Control. You can change them manually, but they’ll get overwritten by the WebLogic Server admin server when you restart WebLogic. You can override this behaviour so that changes you do make to these particular parameters don’t get overwritten, but then you’ll have to remember to copy changes to all the nodes (in OBIEE 11g, clustering is automatically enabled). Not all parameters are managed in this way (in the screenshot above, DATA_STORAGE_PATHS, POPULATE_AGGREGATE_ROLLUP_HITS and USE_ADVANCED_HIT_DETECTION still have to be changed by manually updating this file, but over time the plan is to move more and more parameters to management through Fusion Middleware Control.

To change the managed parameters, go to Fusion Middleware Control, log in as an administrator user (weblogic/welcome1 in my case), and click on the coreapplication node under the Business Intelligence menu entry, so that an overview of the system components status is shown:

From this screen, you can stop, start and restart all of the system components (BI Server, Presentation Server etc) via OPMN. From this point, you can then click, on the Capacity Management, Diagnostics, Security or Deployment tabs to perform further maintenance.

• Capacity Management has four further sub-tabs, and can show Metrics gathered via DMS; the Availability of all the individual system components (allowing you to stop, start and restart them individually); Scalability lets you dynamically increase the number of BI Servers, Presentation Servers, Cluster Controllers and Schedulers in the cluster in conjunction with the “scale out” install option, and Performance lets you turn caching on or off and modify other parameters associated with response time.
• Diagnostics has two sub-tabs; Log Messages shows you a cluster-wide view of all server errors and warnings, and Log Configuration lets you limit the size of logs and what information gets included in them.

• Security is used for enabling SSO and selecting the SSO provider
• Deployment has five sub-tabs; Presentation lets you set dashboard defaults around page tabs, section headings etc; Scheduler sets the connection details for the scheduler schema; Marketing is for configuring the Siebel Marketing Content Server connection; Mail is for setting up the mail server that’s used by Delivers for email alerts. The most interesting tab is Repository though, as this is where you upload new RPDs for use by the BI Server.

When you first navigate to this tab, the option to upload a new RPD is grayed-out. This is because you have to press the Lock and Edit Configuration button, which stops anyone else from attempting the same operation at the same time. The default installation of OBIEE 11gR1 comes with an RPD called SampleAppLite, and I want to replace this with my own RPD, developed offline previously.

After pressing Lock and Edit Configuration, an “in progress” message comes up, and then you can start uploading your new RPD file. In the example below, I’ve used the Browse button to pick up a new RPD called OBIEE11g_Examples.rpd, and I’ve entered the RPD password into the text boxes below (remember in 11g, the RPD itself has a password, rather than you giving the password of an RPD user with admin privileges as you did with 10g).

Pressing Activate Changes will firstly bring up a message saying that the changes will be applied regardless of whether you close your browser window, and shortly afterwards, a second message is displayed saving that the action is completed successfully.

Then if you check the NQSConfig.INI file, you should see your change written to the file. (Technically, the Activate Changes process actually writes the changes to an intermediate file, which the Admin Server then polls regularly and once it sees the changes, writes them to the NQSConfig.INI file).

At this point though, as with OBIEE 10g, you still need to restart the BI Server for this change to take effect. To do this, click on the Restart to Apply Recent Changes link at the top of the web page, which takes you to the Overview page for the coreapplication system components in Fusion Middleware Control. From this point, you can either restart all components (which is a bit of overkill), or switch to the Capacity Management tab, then Availability sub-tab, and restart just the BI Server system component. Once you’ve done this, the new RPD will become active. Note also from the screenshot above that RPDs get automatically versioned, with each upload of a particular RPD being saved in the BI Server repository directory with a sequence number appended to it.

Many administration tasks in 11g are the same as 10g. For example, the log level for a particular user is still defined in the security manager, and you still view the query log (nqquery.log) either through the filesystem, or through the Manage Sessions link in the Presentation Server administration screen. Usage tracking is still manually set up through the NQSConfig.ini file, though the schema it uses is automatically created at installation time through the RCU (Fusion Middleware Repository Creation Utility). In 11gR1, only a subset of these administration tasks are performed through Fusion Middleware Control, but as the releases stack up, more of these functions will move to this environment, something that’s more important now that clustering is turned on by default.

Finally, the Administration screen in the Presentation Server web interface has had a visual overhaul with the 11g release. Some functions, such as the one to reload server metadata in 10g, have moved from Answers into this screen, and new functions have been added to manage, for example, the mapping feature.

Once you get beyond the main menu screen, the way the functions work hasn’t changed much in this release. Some of the dialogs have visually changed, but as you can see in the screenshot below, the functions work in much the same way as 10g, and you can see the Application Roles that were visible in the Security Manager at the start of this posting being used to grant access to Presentation Server functionality.