Is it Classic ASP, or is it BOBJ? Only Your Web Dev Team Knows For Sure

To the uninitiated, custom portal integration of BOBJ reports may seem complex or cumbersome to implement, but with the correct pieces in place, it can be done on a very short timeline.  Here is a brief overview of what needs to be done in a project such as this:

To the uninitiated, custom portal integration of BOBJ reports may seem complex or cumbersome to implement, but with the correct pieces in place, it can be done on a very short timeline.  Here is a brief overview of what needs to be in place to execute a project such as this:

  • Installing .NET framework & BOBJ components
  • Embedding the correct code in the website and its back-end to communicate with BOBJ, both to authenticate users and to retrieve the report, and its data
  • Configuring the firewalls to allow the data to transmit 

And sometimes (as in the case of our recent client) the web login is separate from the client’s internal security systems that would normally communicate seamlessly with BOBJ, so a process must be created to mirror user records between the website back-end and BOBJ as well.

So what is really happening in a BOBJ/ portal reporting scenario?

 

 

 

 

It all starts with the OpenDocument link. OpenDocument is a web service of BOBJ that allows a document to be called out via web URL. The syntax is pretty straightforward, and looks something like this:

“http://<serverlocation>:<port>/opendoc/openDocument.jsp?”, and then there are a series of parameters added to the link, that specify the exact document that is being accessed and under what conditions, which can include report prompts as well.

 

The end product will look something like this:

“http://<serverlocation>:<port>/opendoc/openDocument.jsp?iDocID=<iDocID value, in this case, the CUID, or unique identifier of the report, found in a report’s properties>&sIDType=CUID&sRefresh=Y&token=” 

 

This is the point of entry for the report from the website. In fact, you could just embed a link like this into a website and call it a day.

 

There are two reasons to not do this:

  • The user is forced to leave their portal
  • The user is forced to login with another set of credentials into BOBJ

For users, this may stop some altogether, but at the very least would be a bit of a head-scratcher. So, how do we make it into a more consistent experience? Embed the link in a container, like a frame, and do something about the log in.  The frame is pretty straightforward, and is a design element in your existing web page.  Our recent client used something like this (please bear in mind that there is a wrapper being used to get the .NET components of BOBJ to work with the ASP site, your exact website may be coded differently, and may not require this):

And again, this is a point at which someone could hit the brakes. You have a nice window, that will link into BOBJ, and the report will certainly be visible in it (which can be formatted to nicely compliment what is happening outside the frame). But what about the log in? That’s where things get modestly more complex but, again, doable.

 

What will need to happen at this point is that the BOBJ system will need to know that it is being accessed in a legitimate fashion, and more specifically, by whom. If the report were the same for everyone, then a “trusted authentication” method is acceptable, but for what we are trying to do, we actually want the view to be tailored to the user. So this is where login tokens and the BOBJ SDK get involved.

 

What will be needed is a piece of code that “talks to” BOBJ, and says “Hi, here is the user and password that we have, can you give us some way of identifying ourselves?” If the ID and password are a match, then BOBJ will return a value that will be usable for a specified period of time. This value can then be used as a parameter in the OpenDocument link that is being accessed. That way, the login is automatic.

 

For those of you who are following the code, you will notice that there is (at least one) step in between that we haven’t shown. The method “GetBOLogonToken” has parameters that are not being set anywhere, and the iframe in the earlier code sample doesn’t have any detail on what is happening in the DotNetWrapper.aspx file…   Well, here it is:

 

What this is doing is acting as a go-between involving BOBJ, the iframe, and the ASP login information (as part of a non-disclosed config file, already part of the client’s web site) to correctly take the info, plug it into BOBJ, retrieve the token, and use it in the construction of the link that will open in the iframe. The result is a seamless experience for the user, who will benefit from the computing power of the data warehouse with the familiarity of their web portal.

 

 

 

Contact Us

National Office Telephone | Mon-Fri 8:30am-5:30pm CT