If you are unable to create a new account, please email support@bspsoftware.com

 

News:

MetaManager - Administrative Tools for IBM Cognos
Pricing starting at $2,100
Download Now    Learn More

Main Menu

Migrate Public-Facing Tools

Started by bijeff09, 17 Feb 2015 05:32:41 PM

Previous topic - Next topic

bijeff09

Hello All -

I have over 17 years of experience with a variety of DW and BA tools (most of it using IBM Cognos). However, it's has been a couple of years since I've touched Cognos tools. My client has a requirement that I admittedly have little experience with. I spent a lot of time creating a market evaluation to help my client select a BA suite of tools that are most closely aligned to their requirements. Cognos is one of two final options, and I'm trying to wrap my head around (from a high-level) how to embed a report/dashboard into an existing web page that is accessed by the general public (no security requirements since it's public data).

The requirement is two-fold: 1) migrate/redesign old public tool (crosstab report w/ parameters) to interactive report(s)/dashboard(s), 2) embed the report objects into the existing web pages.

The data source has very slow velocity (updated annually), so I don't need a live connection to the RDBMS (it can reside in a flat file). I think developing it is the easy part (the report requirements are pretty straight-forward), but I'm wrestling with the best way to embed the content into our website and have it totally separate from other content in Cognos Connection. Public users only need to interact with the pre-designed dashboard/report (no need to create anything). Here are the options I'm considering (ultimately, I'd prefer to not have the general public accessing Cognos Connection via a url even if access is protected):

1) Create parameterized active report (can the .mht file be embedded?)
2) Use Cognos Workspace Advanced (Share Workspace option?)
3) Use GET() or POST() method to call Cognos url
4) Cognos Mashup Services (use the BI BUS API, but it seems to be a little more involved than using the Tableau JS API)
5) Cognos SDK (will need to engage our JAVA developers, which will increase labor costs)

All above options (and any others I missed) are on the table.

I hope all that makes sense, and I look forward to any feedback you can provide. Thanks in advance.

JR

bdbits

If you are on websphere or sharepoint, there are web parts/applets you can use with those products. I have used the SharePoint ones myself, with mixed feelings on the experience.

You could use Active Reports, but since the active report contains everything necessary for viewing it, it can get rather large and the user will, I believe, be downloading the entire thing. You can export to a PDF, but that is only good for non-interactive reports. You can embed Cognos URLs into an <iframe>. The SDK approach is very flexible - Cognos has pretty decent APIs - but it is the most labor-intensive to implement. I have looked at but not tried mashup services - seems pretty straightforward.

One thing I would consider is building a separate server for the public users. You can turn on anonymous, and since you said the data can be or is local, it is a very self-contained box and your attack surface is relatively small. Of course there will be licensing considerations ($$$) for the additional server. We have been tunneling back to our Cognos server from the DMZ but are about to cut over a separate server with anonymous access enabled, as described.

bijeff09

@bdbits - Thanks, appreciate the feedback. I totally forgot about the <iframe></iframe> option. That would still require a url to a BI server instance somewhere

Yeah, I was trying to avoid standing up another server instance due to the additional cost. Essentially, I was trying to leverage the new Cognos license model that now allows you to design content in-house, then push it out for consumption at no extra cost for server licenses (the assumption is that users will only interact with the report/dashboard). It seems like the only option that fits this "self-contained app" criteria is active reports, unless I am missing something. A couple of questions about active reports:

1) Is there a file size limit at which performance degrades? We are using AWS EC2 and can size the server instance accordingly, if that helps.
2) Is there a setting in RS that I can invoke that will prevent public users from downloading the active report?
3) Other than potential file size and performance implications, are there any other reasons that would preclude me from using active reports?

All the options I listed in my first post are still viable - I just want to ensure that I get professional opinions (I'm surrounded by software developers, DBAs, and analysts...no one on my project has any exposure to DW or BI) before I cross active reports off my list.

bdbits

Maybe someone else can jump in as my experience with Active Reports is very limited, but... an Active Report is a web archive (.mht file) much if not exactly like saving a web page in Internet Explorer. The file is completely self-contained with everything needed for whatever the user can do. It does not in any sense "stream" to the user - they are simply opening it from the URL. So "performance" is really just a question of how big the file gets. From what I have heard from others, it is not uncommon to have files of 20M+ for a very interactive report with lots of graphs. Not so terrible on an intranet, but for the public that is pretty big in my book.

bijeff09

Thanks for your feedback, bdbits. It's been a couple of years since I've used IBM Cognos, so I've missed the last couple of releases and have only heard about "new" (to me) functionality like active reports and data decks. After doing a lot due diligence (reading and youtube videos) and talking to IBM solution architect, I've come to the conclusion that the technical and design limitations in active reports prevent us from using it for the public tools. So, I've decided to use CMS for our public tools, which should give us much more flexibility, but less code complexity compared to the SDK.

Thanks again, cheers!