Introduction This is the third part of three detailed articles making up a mini-series about OBIEE monitoring. It demonstrates how to capture OBIEE performance information, and optionally graph it out and serve it through an auto-updating webpage. This final article describes how to bolt on to OAS a simple web page hosting the graphs that you created in part 2, plotting data from OBIEE collected in part 1. The webpage This is just an old-school basic HTML page, with a meta-refresh tag (which note that Chrome doesn’t work with) and img tags:

Oracle Application Server (OAS) is the Web and Application server typically deployed with OBIEE. There are several settings which by default may be viewed as security weaknesses. Whether realistically a target or not, it’s good practice to always be considering security and lock down your servers as much as reasonably possible. I adopt the default stance of having to find a reason to leave something less secure, rather than justify why it needs doing.

Oracle have published an interesting doc 968223.1, entitled “Enterprise Deployment of Oracle BI EE on OC4J and App Servers”. It details the differences between OC4J and OAS which is useful for the current versions of OBIEE. It then also gives a useful heads-up – that WebLogic becomes the App server of choice in the next version of OBIEE All of this changes in OBI EE 11g where several projects will become absolutely dependent upon an App Server.

Introduction Whilst the BI Cluster Controller takes care nicely of clustering and failover for BI Server (nqsserver), we have to do more to ensure further resilience of the stack. A diagram I come back to again and again when working out configuration or connectivity problems is the one on P16 of the Deployment Guide. With this you can work out most issues for yourself through simple reasoning. Print it out, pin it to your wall, and read it!

The Critical Patch Update Pre-Release Announcement for October has been published. The pre-release is advance notice of the affected software prior to release of the quarterly Critical Patch Update. It is published on the Thursday prior to the patch releases (which was postponed by a week because of OOW). It looks like if you’re running OBIEE 10.1.3.4.0 or 10.1.3.4.1 through OAS 10.1.2.3.0/10.1.3.4.0/10.1.3.5.0 then you should check back next Tuesday 20th for details.

I successfully installed OAS 10.1.3.3 and patched to 10.1.3.4. http://localhost:7777 gave the OAS welcome page, but going to http://localhost:7777/em gave 404 Not Found. In [OASHome]/j2ee/home/config/servers.xml search for ascontrol, you should get: change the start attribute to true Restart OAS ([OAShome]/opmn/bin/opmnctl restartproc) and Enterprise Manager should now be available

If, for some reason, you need to check what web application server is in use for Presentation Services (as this chap needed to), you can use an add-in for FireFox called HttpFox to inspect the HTTP headers. 1. Install HttpFox (and obviously Firefox if you don’t have it already!) 2. Open the HttpFox window (Tools -> HttpFox -> Toggle HttpFox) 3. Click the Start button in the HttpFox window 4. Navigate to your OBIEE home page

It’s possible to change the error pages served up by OAS/Apache by using the ErrorDocument directive. This is widely documented. However, to get this to take effect in an oc4j application (such as analytics) you need to change mod_oc4j.conf too. (I found this out from this post here) Take backups of httpd.conf and mod_oc4j.conf, and then edit them as follows: In httpd.conf add: ErrorDocument 500 /500.html where /500.html is a relative path to your custom document

We’ve got a setup of two OAS/Presentation Services boxes and two BI Server boxes, with load balancing/failover throughout. The Load Balancing of the web requests is being done through a separate bit of kit, an F5 BIG-IP load balancer. This directs the requests at the two OAS servers. The problem we have is that by default OAS serves HTTP on port 7777, but the F5 is using port 80. A request for our load balanced URL: http://bi.

I noticed that the j2ee server.log file was filling up with these entries: oracle.ons.Notification@afba5d 09/04/02 10:15:12.207 Send notification: oracle.ons.Notification@17ca0f5 09/04/02 10:15:42.217 Send notification: oracle.ons.Notification@1a28842 09/04/02 10:16:12.227 Send notification: oracle.ons.Notification@5144d5 09/04/02 10:16:42.237 Send notification: oracle.ons.Notification@19078ed 09/04/02 10:17:12.247 Send notification: oracle.ons.Notification@fcc268 09/04/02 10:17:42.257 Send notification: oracle.ons.Notification@16df388 A quick google turned up this page in which bug 7132128 (“OC4J EMITS “SEND NOTIFICATION” MESSAGES THAT FILL SERVER.LOG”) is identified. The server.log is currently only 6MB and given the size of the server it will be a while before it causes us problems, but it’s worth being aware of.