- The Query Studio for simple and ad-hoc queries
- The Report Studio for more advanced and printed reports
- The Framework Manager to create custom Cognos models to be used by the Report and Query Studio.
These three components above have been encapsulated and installs on a single box with little effort. These components can also be installed on several machines or be integrated with an existing Cognos environment and there has not been much change to the Tivoli Integrated Portal implementing Tivoli Common Reporting. There is however an additional component and that is the derby server holding the Cognos Content Store. Tivoli Common Reporting V1.3 also installs the BIRT engine separately so any BIRT reports can be run as well. There are no plans at this point in time to abandon the BIRT technology in Tivoli Common Reporting going forward.
So what is the difference between BIRT and Cognos? BIRT delivers the Report Designer which is an IDE environment based on Eclipse required to create reports. The Report Designer leverage the database tables or views from the source database. All the SQL logic, page formatting and graphical layout are all stored in the report definition file (xml). Once a BIRT report has been deployed to the Tivoli Common Reporting Server it cannot be changed or modified by the end user. Changes and modification must be made by a report developer and then re-deployed to the Tivoli Common Reporting Server.
Cognos reporting with Tivoli Common Reporting delivers the Query- and Report Studio which are online tools available through the Tivoli Integrated Portal. These tools allow users to create ad-hoc (query studio) reports and more advanced (report studio) reports leveraging data models using a supported browser. There is no additional tool needed to create or modify reports. A data model is a layer in between the database and the Query- and Report studio consolidating data making it more user friendly. One example is that the Windows CPU Utilization metric in the Tivoli Data Warehouse is named “AVG_%_Processor_Time” which may not make sense to many technicians. In the Cognos model this metric can be renamed to e.g. “Average % Processor Time” and you can also hide the remaining 49 metrics in that particular table to the report user. A model can also contain OLAP definitions (dimensional model) allowing for advanced analysis of the data. The OLAP part of a model is not necessary but can be included. Cognos modeling is also another aspect that needs to be grasped, which can be a daunting task unless you keep it simple. A Cognos model is basically a three layer view of the database:
- A database view (the raw database tables). This is the placeholder or container where you pull the raw database tables needed for the consolidation view. You typically hide all these components in the Cognos model.
- A consolidation view (relational model). This is the place where metrics are selected to be disclosed to the end users. Here links and joins are provided between tables e.g. between CPU, Memory and Disk tables allowing the user to select metrics from these tables without realizing they come from 3 or more different database tables.
- An analytical view (dimensional model). This is the step where you can create OLAP cubes and dimensional drill up and drill down features. This is where things can get complex. If you need to delve into the analytic part of a Cognos model you need to plow through the Internet, perhaps study some books or even attend formal education. Note that this final step is necessarily not needed to provide a custom Cognos model.
I hope this short article has shed some light on what the added value of Cognos is. If you are a Tivoli customer and has not yet started using your Tivoli Data Warehouse data for reporting, my recommendation is to explore the Cognos technology delivered with Tivoli Common Reporting V1.3. As always, should you have questions or comments, please do not hesitate to contact us.