By default, OBI 11g will listen for connections on port 7001 or port 9704 depending on your installation type. There are several reasons you may want to change this, and one of them would be to make it use port 80, the default http port. If you use port 80, then you don’t have to specify it in the URL, so you can use http://biserver/analytics/ as your URL instead of http://biserver:9704/analytics/.

The port configuration is a simple change to be made to the Server configuration in Web Logic Console. However, if you want to use port 80 and are running Linux/Unix there is an additional consideration. On Linux/Unix (hereafter, I’ll just refer to Linux), any port < 1024 is considered privileged and you must run the program binding to it as root.

At this point, if you don't have root access on your box already and are beholden to a sysadmin team, I would suggest validating your reasons for wanting to run on port 80, since you are going to have to go begging for some kind of privileged access. If you're up for that, then read on. If not, then why not stick with 9704, it's a nice number anyway....

Overview of the change to listen on port 80

The configuration changes are actually very simple. They are just within Web Logic Server, we don’t touch the BI components at all.

We change the Listen Port property of the Server to port 80.

Since we are using port 80, we will have to start the server process as root. But, we can get Web Logic to revert back to the OBI user&group once the port has been bound to (since running a process as root is generally a Bad Idea)

To do this, we configure Post-Bind UID in the Machine properties.

WLS – Server configuration

Depending on whether you have a Enterprise or Simple OBI installation, the configuration will differ slightly. See Mark’s post here for explanation of the difference between the two installation types. In an Enterprise installation, you need to modify the properties of the bi_server1 Managed Server, whereas a Simple installation has all the bits within AdminServer.

For both however, you need to login to Web Logic Admin Console, and locate the Servers screen. Click on either AdminServer (Simple installation) or bi_server1 (Enterprise installation) to view the Server settings.

Click on Lock & Edit

Locate Listen Port on the Server configuration (Configuration -> General, if not already displayed). Change this to 80.

Click on Save.

WLS – Machine configuration

Still logged into Web Logic Admin Console, with the above Listen Port change pending, click on the Machines link under Environment in the Domain Structure menu. Click on your server name.

Now, tick the two items Enable Post-Bind UID and Enable Post-Bind GID.

To determine your userid and group, login with your normal OBI user, and type id

$ id
uid=300(oracle) gid=301(oinstall)

Enter these values in Post-Bind UID and Post-Bind GID

Click on Save.

Activate the changes

In Web Logic Admin Console, click on Activate Changes.

When this has completed successfully, shutdown the stack and then see below for how to start it back up.

Starting up the stack to listen on port 80

You don’t need to run all of the components with root privilege, only those that are binding to port 80. In addition, in an Enterprise installation you have the Node Manager component which is responsible for invoking Managed Servers, and since we need the Managed Server bi_server1 to be run with root privileges, Node Manager must be too.

‘Simple’ installation

1. Start WebLogic, as root
2. Start OPMN and BI Components (not as root)

‘Enterprise’ installation

1. Start NodeManager, as root
   • If you don’t start this as root, you won’t be able to start up the Managed Server bi_server1 from within Web Logic Admin Console
2. Start WebLogic (AdminServer) (not as root)
3. Start WebLogic Managed Server (bi_server1), as root
4. Start OPMN and BI Components (not as root)

Validate the changes

You should now be able to access OBI at port 80, which as the default HTTP port doesn’t need specifying in your URL. So if previously it was http://localhost:9704/analytics/ you should now be able to see it at http://localhost/analytics

If you look in the Web Logic server log (AdminServer.log / bi_server1.log respectively), you should see this kind of entry:

<Notice> <Server> <BEA-002613> <Channel "Default[1]" is now listening on 192.168.69.0:80 for protocols iiop, t3, ldap, snmp, http.>
<Notice> <Server> <BEA-002613> <Channel "Default[2]" is now listening on 127.0.0.1:80 for protocols iiop, t3, ldap, snmp, http.>

And netstat should show something like:

$ netstat -a|grep LISTEN|grep 80
[…]
biserver01.80             *.*                0      0 49152      0 LISTEN
localhost.80               *.*                0      0 49152      0 LISTEN
[…]

or you might see the port named instead of numbered, thus:

$ netstat -a|grep LISTEN|grep http
tcp        0      0 rm-oel02.localdomain:http   *:*                         LISTEN
tcp        0      0 localhost.localdomain:http  *:*                         LISTEN

Possible errors

If you don’t start the process as root, then it will fail to bind to port 80, and you’ll see this error in the log:

 <Error> <Server> <BEA-002606> <Unable to create a server socket for listening on channel "Default[1]". The address 127.0.0.1 might be incorrect or another process is using port 80: java.net.BindException: Permission denied.>

sudo

What is sudo? Well, any chance to quote this xkcd cartoon is a good one:

What sudo does is let you run a command under root (superuser) privileges, without actually being root. This is very useful in two ways: (1) your sysadmins don’t have kittens when you ask for root access, because they can give it in a very granular way which is logged every time it is used (2) you’re not let loose on a server with unfettered root access where a simple slip of the keyboard can serious knacker things up (hence your sysadmin’s kittens).

sudo can be granted globally for a user, that is, any command the user wants to run as root can be done so. Alternatively, sudo can be allowed for one or many pre-specified commands. This means that in this case your sysadmins can give you the right to run the required WLS processes as root, and absolutely nothing else.

This is an example of such an entry in the sudo configuration file, /etc/sudoers :

Cmnd_Alias BISERVER = /app/fmw11115/user_projects/domains/bifoundation_domain/bin/startManagedWebLogic.sh bi_server1, /app/fmw11115/wlserver_10.3/server/bin/startNodeManager.sh
# This defines a command alias, BISERVER, with the web logic startup script and arguments to call, and the command to start Node Manager
oracle     localhost=NOPASSWD BISERVER
# user oracle, on machine localhost, can run BISERVER command alias, without being re-prompted for their password

Whenever you invoke sudo, it’ll be logged in /var/log/secure, eg:

Jan  3 17:07:19 rm-oel02 sudo:      rnm : TTY=pts/2 ; PWD=/home/rnm ; USER=root ; COMMAND=/app/fmw11115/user_projects/domains/bifoundation_domain/bin/startManagedWebLogic.sh bi_server1

Alternative to running root/sudo

An interesting alternative is to leave OBI listening on its default port, and configure the server to forward requests on port 80 to it, for example using iptables. I found this suggestion here, amongst other places. This way you’d only need a one-time privileged change made on the server, instead of needing privileged rights continually (however limited they may be)

I’ve not had chance to try it, and in keeping to the KISS principle would probably only consider it if all other options were exhausted. Thinking of someone coming to the server after me, would their first thought around OBI port configuration really be to look at iptables? Whereas Listen Port is a standard configuration item within WLS.

The simple answer is that, out of the box, this is not (yet) supported in the 11G release, unless the user has administrative privileges on the weblogic server.
This leaves :

1. Asking an administrator to do it.
2. Granting more privileges on the BI stack, allowing them to log into the weblogic console and modifying the password there.

Neither of these methods is very flexible since it requires 3rd party intervention on some level to make it happen. Worse, administrative access would have to be granted to those users, defeating in large part the purpose of the security infrastructure.

One option would be to create a set of WLST scripts that, to some degree, hide the administrator credentials, but that option requires users to run scripts outside of the web front-end. It works but it’s hardly intuitive or user-friendly.

This post will explore a method that would enable users to do this themselves, directly from within Analytics, without the need to divulge any higher privileged credentials.

Since the introduction of OBIEE 11G running on weblogic an extensive API is available containing the functionality that is already present in the enterprise manager and weblogic console. Part of this is the Mbean tree that OBIEE uses to manage its configuration. This Mbean tree can be browsed using the Enterprise Manager. Each of the Mbeans in this tree relates a part of the stack and exposes methods to either get or set bits of the configuration. Of interest in this case are the Mbeans relating to the Authenticators. More specifically, in the case of a default installation, the DefaultAuthenticator linked to the myRealm security provider.

Logging into the enterprise manager gives us its exact name and exposed methods:

From here we can invoke the ChangeUserPassword method and change the password for a user.

In order to leverage these Mbean methods outside of the Enterprise Manager a simple java class can be built, using the aforementioned API.

The steps to be taken in this class are:

1. create a connection to the Mbean server
2. call the password change method in the appropriate Mbean

I used Jdeveloper 11G R1 for this.

So far so good. I can now change the weblogic password by calling the java class and verifying success by logging into Analytics with the new password.

In order to make this class available from within the OBIEE dashboards I’ll use a feature that was introduced in OBIEE 11G: the ability to consume web services. This is possible in 10G as well but some jiggery pokery is required to get this to work. OBIEE 11G on the other hand has this functionality by default.

First I have to expose the class as a Web Service. In order to do so I have to create a Web Service out of it and deploy it to an application server in the form of a war file. The good thing is that no additional installation or configuration is required since I already have a full fledged application server at my fingertips viz. weblogic.
A few clicks in JDeveloper later and it is deployed to the Admin server where it’s visible under the deployments:

A quick test in Jdeveloper verifies that it’s working as advertised.

Now all that remains is to create an action item, call the webservice and place it on a dashboard somewhere.

1. Create a new action item in Answers

2. Point it to the WSDL descibing my ChangePassword web service

3. Make it prettier by setting prompts, messages and a few of the other options

4. Put in on a dashboard.

And there we are. Any user can now change their password from the within Analytics, without being exposed to any administrative credentials.

To finish, this consideration:

The Web Service can hardcode the weblogic password to connect to the Mbean server. Obviously this is not ideal since, should it be used to change the weblogic password itself, the  webservice would stop working. This means that the weblogic user has to be treated as the exception.

One way of dealing with this is to not use username/password authentication but rather use config- and key files to authenticate the weblogic user. The Web Service in that case would have to regenerate these files each time it’s used to change the weblogic password.

But there’s an app API call for that.

Ragnar

1. Ability to modify BI EE Metadata through WebService Calls - So far the only way to modify BI EE RPD was through UDML & XUDML utilities like xudmlgen.exe/sh etc. But with this release we can do these through native Java Web Service Calls. How has this been enabled? Well, now the JDBC/ODBC drivers of BI EE have methods that can update as well in addition to returning results (which in itself is a topic for a future post).

2. 4 new BI EE JDeveloper Extensions – Oracle has added 4 new extensions for JDeveloper. Each extension enables native access to BI EE and its objects. This is a feature that Oracle enabled when JDeveloper 11g TP4 was released. That was even before the BEA acquisition. Refer my post here to find how this feature worked in that tech preview. The extensions are

a. BI EE ADF Extension – With this we can extract BI EE objects directly into an ADF application and apply our own visualizations on the data.

b. BI EE ADF Logical SQL View Object – With this we can now fire Logical SQL directly from ADF applications thereby leveraging the capability of BI Server right within our custom BI Apps.

c. BI EE Soap API extension – With this we can make native BI SOAP calls. Custom web catalog services, metadata services etc can be accessed through this extension.

d. BI EE ADF Task Flow extension (Composer) - With this we can now create ADF Task Flows using BI EE. This enabled integration right into webcenter.

The extensions can be downloaded from here.

In this post, i shall be covering the first 2 extensions i.e. the ADF extension and the Logical SQL View Object Extension. For extensions to work we need JDeveloper 11.1.1.5. Earlier releases will not work.

BI EE ADF Extension:

We start off with creating a simple Fusion application as shown below.

While creating the View Controller choose the Business Intelligence View Component. You will see this entry only after you have loaded the BI Extensions.

As you as you have created the application, you will notice that the in the list of the Application Resources, BI Presentation Services will be listed as one of the connectors. Lets make a connection to BI EE (11.1.1.5).

In the next step, you will have an option to choose static resources. Again, this is a new feature of BI EE 11.1.1.5 i.e. we can configure BI EE to use static resources from an external HTTP server there by making the application render images etc faster.

In terms of security, impersonation can be chosen there by allowing multiple user contexts to be passed down to the application natively.

As soon as you establish the connection, you can notice that all the BI EE Web Catalog objects are exposed natively to ADF.

From here on it is just a matter of dragging and dropping these objects into the application (as these are now native ADF objects). To test this, lets first create a sample JSF page and then drag and drop one of the dashboards on to the page.

When we drag and drop the dashboard, all the filters of each report within the dashboard and the corresponding prompts are shown as parameters. To have control on the page display we can set these parameters right within the ADF app or we can choose them during runtime. This gives us a lot of control on how BI EE objects are handled within ADF.

Let’s now run this application. You can see that BI EE now runs as a native ADF application.

BI EE logical SQL View Object:

Another important feature that i had shown here to some extent is the ability to make Logical SQL calls directly and then apply custom ADF visualizations (which are not available in BI EE yet). Its now easily possible through the Logical SQL View Object. To demonstrate, lets create a new Logical SQL View Object within our ADF application

To use the extension we need to create a native JDBC connection to the BI Server.

Let’s now create a new View Object and then apply a custom Logical SQL as shown below.

Using the View Object, create an application module and then import that app module into a custom JSF page.

As mentioned in my last BI Forum presentation, ADF now supplies a lot more visualizations than that is packaged with BI EE. So, just to demonstrate, let’s use a Pivot visualization not available in BI EE i.e. Ring Bar Pivot.

If we now render the page, you can see that ADF extracts the data through the BI Server JDBC (using the logical SQL) and then applies its own visualization on the data.

Can you imagine the possible integration possibilities this now has opened up? BI EE no more is a black box which is too good for System Integrators like us.

1. Reporting from a set of database(relational, multi-dimensional, flat-files etc) tables
2. Reporting from a set of pre-defined data services

The problem with these approaches (even in BI EE) is that one has to spend time doing the data modeling. Data Modeling from a BI Perspective is good as it helps in visualizing the data from an end-user standpoint. But in some cases, for example, when reporting out of transactional databases we might already have some pre-defined reporting screens available (real time reporting as part of the transactional system). E-Business Suite, Peoplesoft etc all come with pre-defined reporting or updatable forms/screens. Each of these screens will be firing some sort of SQL to get the data and display it to the end user(which might span multiple tables). Screenshot of an expense reporting application screen in EBS is given below

This itself contains 2 SQL queries(minimum) for displaying the data. To fire the same report in another reporting tool, requires the following tasks

1. Identify the source tables
2. Model them in the reporting tool
3. Develop and then match the results with the EBS screen (testing)

In effect, this requires a person who knows EBS source systems, a BI Developer and then atleast 2 to 3 days of time in modeling, reporting and testing. All of this is needed for a single report, what if the requirement is to mimic the reporting available in 50 or 100 such EBS screens. In such cases, the reporting can grow quite complex and requires careful balancing of resources who know EBS and resources who know BI EE (or any other reporting tool for that matter).

BI EE – ADF View Objects integration alleviates the above said problem by completely bypassing the need to do initial source table identification (and sometimes modeling). Its advantage is it can understand the transactional system and convert the ADF metadata into BI EE specific metadata. So, all a BI EE developer has to know is what application module View object provides the data for a specific screen. That way rather than importing the metadata from the database, BI EE will reverse the source tables/columns from the transactional system and then import them accordingly. This is not only applicable for EBS, PSFT etc but also applicable for any application built out of the ADF framework.

The fundamental goal of Oracle Fusion Applications is to make everything interoperable thereby reducing implementation/go live times. You can sort of start seeing how BI EE will eventually merge into the Fusion Stack with this capability. This feature will also provide the ability for BI EE to do true real-time reporting. The diagram below explains how this integration works

To demonstrate how this works, we will be creating an application(Order Entry for example) which will contain 2 View Objects. One for getting the Orders and the other for getting the Order Items as shown below

To create these AM’s/View Objects follow the instructions in my previous post. In an ADF application, generally all business logic, business rules etc get applied in a View Object/Application Module. So, during the BI EE import/reporting all of these business rules/business logic will be honored as well. To set this up there are 3 steps we need to follow

1. Have a Weblogic application server with a domain that will contain the JRF, Oracle Appl Core binaries – While creating a domain, weblogic will not show the option of Application Core libraries. If that is the case, get the Appl Core binary from Oracle BI EE 11g instance and deploy it to your weblogic instance. This is key to get the integration working.

2. BI EE and the application can be in completely different boxes. To enable the communication, a BI EE broker needs to be deployed in the application weblogic instance.

3. A SQL Bypass database can be specified for improving performance. Another good feature wherein one can persist aggregation to a physical database rather than performing in the BI Server memory. Now, only if we could have this feature for cross database joins.

In my example, i will be deploying the application in the same weblogic instance as BI EE. To check whether the Application Core libraries exist, lets go to the weblogic console and check for applcore library.

As mentioned before, if this does not exist in your weblogic domain, copy the applcore library files from BI EE instance and then deploy them in your weblogic instance. In the same way, a BI EE broker needs to be deployed in your application weblogic instance. This broker is a war file that is present under {Middleware_Home}\Oracle_BI1\bifoundation\javahost\lib\obisintegration\adf folder of the BI EE 11g instance. Copy the ear file oracle.bi.integration.adf.ear under this folder and then deploy it in the application weblogic instance.

Now the next step is to prepare our application for deployment. To do that we need to make sure that the database connection that we are using as part of the application (OE schema) exists as a JNDI in weblogic(details of why we need to do this is given in the last blog post). Also, we need to enable the configuration of the application module to use the JNDI instead of going through the Credential Framework.

So, we go to the configuration of the Application Module and then enable a new configuration to use the JNDI as shown below

Ensure that this configuration is the default configuration of the application.

After enabling this, create a New Business Components Archive in the Model Project (click on New from the Project) and give it a name

You should now see 2 jars that will be deployed as part of the Archive.

Deploy the model using this deployment profile (use the default options of deploying to a file)

Right click on the application and create a new Web Project as shown below (adapt the names as necessary for your application)

Go to the project properties of the OBIEEBroker application and then ensure that the jar files that we created before are included as dependent libraries for this application war file (default profile webapp).

Expand the web.xml of this project and add the following entries

Now create a new EAR deployment profile for the whole application. Ensure that the webapp.war that was created for the webproject is included in the EAR.

In the application resources task pane, open up the weblogic-application.xml and add the following entries to the xml file.

This is needed for referencing the broker and applcore libraries. Login to the weblogic console and then add a JDBC data source with the same name & JNDI as the one we specified in the Application module (without the java:comp/env in the name).

Deploy this to the BI EE 11g cluster as shown below

Deploy the application now directly to the BI EE 11g instance from JDeveloper.

After this the URL for the broker should be accessible from a browser (http://172.16.62.131:9704/BIEEOrders/obieebroker in my case). Now the application is ready for import into BI EE. Lets now open up BI Administrator and choose the OracleADF_HTTP as the database type. In the database source, enter the same JNDI name as we entered in weblogic. Enter Model Name.Application Module name as the Application Module definition (model.orders). Enter the name that we gave for the Application Module config(ordersAM). Also enter a valid weblogic username and password

We should now be seeing both the View Objects that we created before. Lets now import both of them.

If we now look in the connection pool, there is an option to set the SQL Bypass Database which we can use for pushing aggregation/sorting etc to a physical database rather than doing them in the BI Server layer.

In the next part, i will cover how to use the SQL Bypass Database and see how that influences the queries etc.

One of the first integrations that i noticed between Fusion Middleware and BI EE was when JDeveloper 11g Tech Preview 4 was released almost 2 years back. I had blogged about it sometime back here. This integration was very promising wherein every report in BI EE Web Catalog was exposed as a view object. So in effect, from within JDeveloper one can easily apply ADF visualizations to an existing BI EE report/dashboard. This integration was very similar to the BI Publisher – BI EE integration where instead of a template, ADF visualization is applied. Unfortunately, this feature does not exist anymore in the production release of JDeveloper 11g. Though it does not exist as a feature now, there are ways to still expose them within JDeveloper. I will cover them in future blog entries.

In the current release of Fusion Middleware 11g, there are quite a few BI specific visualizations that have been made available. All of these can be used even on existing BI EE 10g installations. But the only downside is, there will be quite a bit of coding involved to tie BI EE 10g with the FMW 11g graphs. Hopefully this should be made easier with BI EE 11g.

I will basically highlight some of the interesting ADF Visualization components specific to Business Intelligence in this blog entry here. Many of the graphs shown below are available as part of a sample application that needs to be obtained from OTN. All these(base components for the charts/graphs) are available out of the box with the FMW 11g installation.

Custom Gauges:

FMW 11g adds some significant number of Gauge components. I have listed the important ones below. All these are very interactive like the Corda Charts that we are used to seeing in BI EE. ADF Gauges are based on SVG and hence the drills are supported here as well.

Graph Visualizations:

FMW 11g supports 2 main features in any graph

1. Custom Annotations can be added
2. Individual data points can be moved (drag and drop) for better visualization

Custom panel splitters are supported as well. One can essentially have 4 graphs in a page and then hide/unhide them in a pane layout as shown below

Its very interesting to note that time based interactivity in the graphs have been added. For example, one can choose a time period within a master graph, the child graphs will change automatically.

There is also an inline graph component called Spark Charts. These are charts that are embedded as a cell object in a table/pivot view.

Pivot Tables:

This is one area where i am seeing significant changes to the way BI EE 10g pivot table and FMW11g Pivots. Some interesting features of FMW11g pivot tables are

1. Pivot Table Heat Maps & Conditional Formatting

2. Ability to embed charts (Spark Charts & Gauges) in the pivot tables

3. Ability to drag and drop the columns outside of the edit layout. Also ability to edit cells (potential for writebacks)

Gantt Charts:

This is a significant addition to the list of supported graphs in the FMW 11g. Quite a lot of visualizations are supported on the Gantt Charts

There is another nice add-on to the normal Gantt charts i.e one can track Resource utilization as a stacked bar against Time as the base.

Hierarchy Viewer:

This visualization is probably one of the highlights of FMW 11g. Instead of a normal hierarchy drills from Pivots/tables, this visualization can provide visual hierarchical drills as shown below

Mapviewer Integration:

This is another area where FMW 11g adds a lot of value. It is now possible to directly reuse Maps built out of Mapviewer and render them along with BI components within the FMW framework

There are other areas as well where every graph/chart has improved. For example, now FMW 11g supports a set of attributes that can be modified uniformly for all the graphs. It also provides Master-Detail forms/reports. On a whole, to me, it looks like Oracle has indeed spent quite a bit of time and effort to get the BI framework in FMW ready. Now if only these can be reused out of the box directly from within the BI EE in future releases, then it could add significant dimension to the way we do BI reporting. I guess only time will tell on how these components eventually get into BI EE.