Using multiple frameworks as dataproviders in report 1

[blom0344]

I'm trying to relate the Cognos framework to the concept of Business Objects universe.
Basically I can use multiple dataproviders based on more than 1 universe with a BO report and than 'synchronize' data over common dimensions.
We currently take for granted that we need to stack the whole datamodel within one big framework (even though there is little or no relation between parts of the datamodel)

Question: Can we build reports with more than 1 dataprovider that are based on different frameworks?

Ties Blom

 

[mfgf]

Hi,

Cognos products work slightly differently from BO (from what you're describing). With ReportNet or Cognos 8 the concept is that either:

1) A single project in Framework Manager can span multiple data sources (and join or union them as appropriate), and then be used to create multiple packages including whatever parts of the project are appropriate, but then a report is based on a single package.

or

2) Alternatively a high-level project can be used to combine multiple other independent projects into one (linking them as segments), then again packages can be created from relevant parts of the data available in the high-level project, but again a report is based on a single package.

So I guess the answer to your question is yes, provided you create a package including data from the relevant areas (if I'm understanding the question correctly

Best regards,

MF.

 

[blom0344]

Thank you for your reply.
The concept of package is new for me (a least when not in combination with a database stored procedure)

Let me give you an example from BO's full client (nowadays desktop reporting):

Suppose dataprovider 1 brings revenue for a set of products by means of universe A.

Dataprovider 2 brings in the UPC codes for these items by means of universe B. (which can be based on a different RDBMS)

Full client BO will let me create a full client report that synchronizes the revenue (measure) and the UPC-code (attribute) over the common dimension item and display all data as if fetched from 1 query.

The pay-off is that a datamodel need not be covered by one big universe, but can be divided into smaller universes avoiding complexity and possible mismatch of incompatible objects.

The synchronization mechanism works like an full outer join between datasets and by applying filters can be forced to display data like an outer join or inner join.

Apart from creating very advanced reports it comes in very handy for ad-hoc analysis. When you need to examine data from different sources simply build 2 universes and use reporter to examine differences.

At the moment we are trying to force our datamodel as a whole into 1 framework, which means that table-structures that have nothing in common have to be accomodated somehow.
The only reason why this is attempted is that we were told that all data within 1 report should come from 1 framework.

Could you comment on this?

Ties Blom

 

[mfgf]

Hi,

In the Cognos environment, all the data required would need to be available in one Framework Manager project, and be published into one package. The different sets of tables do not necessarily have to be joined in the project - this would mean that you could use different sets of tables in separate queries within a report and join or union the queries however you saw fit - but the downside is you would get cross-join errors if you tried to bring data from multiple unjoined sets of tables into a single query.

A better bet would be to bring in both revenue and UPC code in their relevant tables, along with the common dimensions that link them, and set up relationships between them in Framework Manager. Then you could use them in the same query. As long as you understand the assumptions the CQE makes about whether a query subject is Fact or Dimension (based on the relationships), you can remodel the data to provide stitch queries (full outer joins between facts linked by common dimensions) as required to get the correct results displayed.

Best regards,

MF.

 

[blom0344]

Thanks for your extensive and very informative answer.
I am just now following a shorttrack Cognos 8 course, so I will probably be back for some more questions.
Have a star..

Ties Blom

 

[mfgf]

Thank you for the star - much appreciated! Hope you enjoy the course!

 

[blom0344]

So far We've been through Portal,Query studio,Analysis studio and Report studio.
I am much impressed with all the portal functionality, especially the fact that there is one central point to work from including scheduling of reports.
Query studio and Analysis studio seem to be okay for ad-hoc work.
Report studio is all about highs and lows. There is a very large set of features that involves making the most of layout and slick presentation, but I cannot understand the absence of a client. Creating complex reports must be painful, having to actually run the report to see the latest changes applied to layout. Surely having a client would speed up the design process?
What really troubles me is the murky water surrounding the actual SQL generated and send to the back-end. I am used to copy past the SQL to a DBA tool and then check the actual explain from the database. Cognos offers the SQL, but you need to do a lot of editing before you can parse it within
a DBA tool. Another matter is the actual building of the SQL. Some functionality (filters, sorts) are worked into the SQL, others are native Cognos and need to be handled by the Cognos server.

Furthermore I can actually create 2 identical queries if I build a list and then a graph. If objects fetched are identical then I would expect the application to tell me that the query already exists. (No need for 2 calls to the database)

I also would like to restrict the # records returned when designing (to a fixed number). This is only possible by setting a filter on an object to restrict the output.

Aggregation behavior is something of a puzzle too. With BO you set aggregation behavior at universe level and normally all measures will be aggregated (no revenue, but always sum(revenue)) at SQL level. With report studio I have the impression that this can be manipulated from within the report? Seems very tricky , risking SQL statements that fetch VERY large resultsets by bringing in everything at record-level.

I am used to quick checks on query-time and records fetched in BO, but can't find something similar in Cognos8.

So, my experience is that the focus lies very heavily on presentation of data and much less on keeping things manageable. Doesn't lack many features though, very lovely implementation of cascading prompts!

Ties Blom