Integrating OBIEE with SharePoint Server (MOSS + OBIEE)

A colleague of mine is huge on Microsoft SharePoint (MOSS) and with good reason; It is Microsoft’s #2 best sold licensed software product behind Microsoft Office. It is a collaboration tool, a CMS, a document repository, and now with PeformancePoint 2007 rolled into the suite is will be an analytical tool. And, since quite a few organizations that have implemented SharePoint use it as their launchpad portal for all things internal (intranet) it only makes sense to be able to integrate SharePoint with more powerful heterogeneous analytical tools like OBIEE. But the big question I have heard over the last few months is, “What is the best approach to integrating OBIEE into SharePoint?”.  In this blog post, I will point you to a White Paper on the subject and some integration code you can use to get started with your integration.

Ultimately we need to look at the limitations of communicating with OBIEE as I describe below.

Like a lot of integrations, there are several ways to reach the end goal. I usually prefer to know what the possibilities and options are in advance so that I at least know what I am getting myself into and can have an idea of what resources I need to gather in order to scope out an integration. In the case of integrating OBIEE into SharePoint those bloody brilliant blokes at Oracle have already done this in a document called Oracle Business Intelligence Enterprise Edition Plus and Micorosft Office SharePoint Server (PDF). This is a white paper by Oracle and not a technical guide.  The reason I mention it here is merely to point out that it exists and to expound upon it with some commentary.

The document boils down to this…There are five different ways you can integrate OBIEE with MOSS:

1. URL-Based
2. SOAP-API or Web Services
3. RSS
4. WebDAV
5. Report UI Portlet

URL-Based

By now you should know about the OBIEE GO URL and Dashboard URLfunctionality. With either, you can incorporate an HTML form on a SharePoint page using a POST method and return the view(Answers) report or dashboard to the user.  You could also set up pre-defined links on let’s say a Financial page in SharePoint that points to an OBIEE Answers report page.

Here’s a great syntatical post on GO/Dashboard URLs

Here’s the OBIEE Web Services Guide

SOAP-API / Web Services

If you’ve developed with SharePoint technology for any time you are on top of consuming web services.  Here you can write a custom web part to hit OBIEE behind the scenes and pull data into SharePoint.  This is a more customized approach but in my opinion, gives the best look and feel for what most users would consider a seamless integration. Here is the link to a code snippet (zip) to create a custom web part provided by those Oracle blokes.

RSS

By using the OBIEE catalog folder and alerts syndicationfeeds you can easily leverage SharePoint to consume this OBIEE data and present these as a link into the end-user.  This is not a fully seamless integration but it is a great approach for incorporating a navigation path into OBIEE.

WebDAV

When I think of seamless integration between OBIEE and MOSS it is a toss-up between WebDavand the SOAP-API (web services).  They will both provide an aesthetic end-user experience and they will both require a higher level of skill to incorporate.  WebDav may start to get into serious security implications since it is File System based.  Also, you may need to configure WebDav on the MOSS server since it is not set-up by default which requires a network administrator to also be involved. What’s more, is that you need the assistance of your OBIEE administrator to set up particular reports to be scheduled via OBIEE Delivers which could be a maintenance nightmare if you are trying to incorporate 100 OBIEE views, etc.

Report UI Portlet

Admittedly, I am not certain where the Oracle White Paper was going with this when it stated Report UI Portlets as part of the possible integrations. MOSS supports something called WSRP1.1 which stands for Web Services for Remote Portlets. Currently, MOSS would consume these remote portlets as Web Parts. This had me confused because as you can see from the code snippet above that creates a custom web part, it simply calls the OBIEE SOAP-API web services.  I am uncertain of OBIEE having portlets or any functionality that would define its views or dashboards under the WSRP standard, so unless the White Oracle Paper was talking about web parts, in general, I’ll have to do some more research on this one.  Either way, a web part consuming the OBIEE web services would ultimately be analogous to this.

If you are interested in WSRP with SharePoint here is some further reading: Blog1, Blog2.

Update: 2009/09/12

Last year around this time Suresh wrote a pretty quick intro to integrate SharePoint with OBIEE.  His blog post is here. He has some good links that are worth looking at.

Update: 2009/11/16

Here are also a few more links on the topic mainly with Oracle Access Manager, Kerberos, and SSO

• http://technet.microsoft.com/en-us/library/cc262305.aspx
• Integrating SharePoint with Oracle Access Manager

Conclusion

In closing, I would tell any client that integration of OBIEE into SharePoint is possible. We even have many options to work with. You could integrate OBIEE via links, via file system, via web services, and/or show only alerts. The rub will come in with resource management. Does an implementation team have resources that have both OBIEE skills, SharePoint skills, and Microsoft development skills? If so this becomes a sweet project. If not, you are either limited to the basics (links only). Otherwise, you had better have some solid project management skills to coordinate, cross-train, and get creative.