Guidelines For Report Development in Cognos

1.
Introduction
This document is intended to provide guidelines for development of reports.
2. Intended Audience
Cognos Report Developers.
3. Program Objectives
Document is intended to explain how to utilize the available cognos features to get maximum results from
your Cognos development.
4. Program Structure
4.1. Creating a report:

Reporting requirements:
Before beginning anything the report developer should determine what the reporting requirements are this will
help to search out the correct data and define a data access strategy.
Setting Report Properties

 Name of the report should let the user know what the report is and it should summarize the purpose
of report.
 Setting report description can also be very useful as it describes exactly what the object is and does
without having to run the report or open it in report studio.
 Entering the Screen tip gives a more descriptive pop-up when mouse is hovered over object icon.
 You can select the default run options if different than the standard HTML, Also set the paper
orientation for the render of PDF or HTML page.
 While setting the report properties owner should be set to report developer. Contact should be report
developer or user in charge of handling communication about the report, this can help in case any
issues come in the report.
Calculations
 Try to move as many calculations as possible into the model so your query doesn't have to do them
for every row of data pulled.
 Place calculations strategically. Rather than include a calculation in a CASE statement in multiple
places, do it once in a separate field and then refer to it in multiple places. This minimizes processing
time.
Sorting
 When sorting a field, sort it either at the tabular model level or the query levels but not both.
Rows per page
 In report studio developer can set the rows per page for a list, (view - list - properties - rows per page)
this will override the default of 20 rows per page permanently
4.2. Building report query:

Before creating the report a query containing all the required columns should be created as it is always useful
to analyze the data that drives your report. Check the main query generated (Generated SQL/MDX option) for
report. The query should not be very lengthy and more or less to be similar with the normal DB query.
Query Processing:
There are two types of query processing available in cognos i.e. Database and Local Processing
Local Processing: Setting report processing to local enables the processing of data locally
Database: If set to database only this will force the work to be done at the database end
Joins
Do not use Outer joins between tables if they can be avoided.
Functions:
Where possible use database functions for calculations instead of their equivalent Cognos functions.
Auto Group and Summarize Property

 Using this property specifies whether the application will apply suggested aggregate functions to
aggregate data items and group all non-aggregate data items, producing groups and summary rows.
In all queries which are putting one record out in the report per database record, always turn the Auto
Summarize option for the query to No (default is Yes) - this can make a huge difference to query
performance and complexity when picking up lots of fields, as otherwise the SQL consists of a mass
of SUM () and MAX () and then GROUP BY for all dimensions/attributes - unnecessarily so.
 Auto Group and Summarize property is used for applying aggregate functions to Aggregate data
items and group a set of non-aggregated data items. When this property is enabled (set to ‘YES’) and
any aggregation is applied to even one of the data item then, the SQL generated has a ‘group by’
clause. Process of grouping and aggregating data is very expensive with respect to performance on
the Cognos side. When this property is disabled (set to 'NO') the query would produce detail rows for
all the columns (Aggregate/Non-Aggregate).Even though the data items are aggregated in the query,
the SQL would not render the aggregation calculations and hence the data would no longer be
grouped to get the 'totals'. This reduces the execution time.
4.3. Formatting the report:
Templates
A developer can also create report templates when frequently produces the same type of report. It helps in
ensuring a consistent look and feel for reports. Saving the template to a common folder would be helpful in
multi developer environment.
Setting Sizes:
 Fixed Column widths: Try to use fixed column widths where possible. Dynamic sizing increases the
execution times—As once it has to find the largest data content, then dynamically size the columns
based on the largest data content
Tables
 Developer should use tables can be helpful in achieving complex formatting on reports. They can go
anywhere -in list columns, in headings, on the background (and list controls should generally always
sit within a table cell so you can add items above and below the list). There is no overhead with tables
and they are a great way of keeping control of output if used well.
 When working within table cells, always set the vertical and horizontal alignment the cell to control
what happens if the objects within the cell don't fill it - again, take control of the output. You can set
cell attributes for a wide range of cells in a table by control-clicking on opposite corners
 In particular, remember that the default width for tables is 100% of their parent or container object.
This is generally desirable 'within' other tables and list columns and the like - however at the outer
levels it is almost certainly something to delete and leave the width setting to blank. The table (and/or
list) will then size correctly to be as wide or narrow as it needs to be rather than stretching
unnecessarily.
Visibility of objects
 Quite often it is necessary to control when an object appears and when it doesn't. If this is a simple
yes or no, always use the rendering control rather than conditional blocks/formatting - much simpler
and less hassle within report studio.
Layout Component Reference

 The Layout Component Reference object in the Report Studio toolbox allows a named object from
the current report or another report to be referenced so that redundant authoring is minimized. Any
changes to the source object will be automatically reflected in references to it.
 Creating templates that use Layout Component References can minimize maintenance and allow
necessary changes to be automatically reflected in reports that were created using the template.
Changing a component reference that is used in other reports will be automatically and immediately
reflected in any reports that use it.
 Why is this Better than a Manual Approach: To compare this approach to doing it manually on
every report, consider this: Suppose we need to specify all the page size/layout properties, drag in
objects to create the header, apply fonts, ensure all is lined up and matching to company standards,
repeat for footers and other elements. Every developer needs to do this manually for every report if
Layout Component Reference is not used.
4.4. Tuning:
Grouping:
Do not use group items if not required on the report as it would impact the performance.
Sort Memory
 It is the amount of memory that Cognos 8 uses to sort then data which has been retrieved from the
database. Editing Sort Memory is required when you see that large reports are taking long time to
display results in Cognos Viewer even after the database has processed the request.
 The Sort Buffer Size is in MB (default value is 4 MB) parameter under Environment in Cognos
Configuration needs to be modified. The value can be modified to 16 or 32 MB as required. For the
changes to effect you need to save the settings and restart the service.
Session Caching
 When the user runs the report, a query is created for which the request is passed to the Database
server. The database processes the request sent and returns the result set to cognos BI server. If the
report author sets the
 If the Report Author sets the Use Local Cache property to yes then after the initial report execution. If
the user runs the report again the cached data can be used without querying the database again
 If the Author want to always execute the query whenever the user runs the report the property should
be set as ‘No’ else set the property to ‘Yes’ to use cached results.
4.5. Unit testing:

Periodic Testing of reports: Reports should be periodically tested while authoring them in Report Studio to
ensure that multiple error messages are not encountered when the report is executed.
Validating your reports

 This property performs sanity checks on the report specifications and data types. Validation Level is
by default set to Warning to change go to menu Tools > Validate Options > Validation level, and then
this can be set to Information. When set to information can give extra tips on joins, metadata or other
"less than perfect" issues.
 So when creating reports in Report Studio, developer should validate the reports time to time and in
case a warning shows up always deal with it. Warning will allow a report to run, but you may get
unexpected results, especially if you are mixing dimensional and relational functions.

Guidelines For Report Development in Cognos

Uploaded by

Copyright:

Available Formats

Guidelines For Report Development in Cognos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Guidelines For Report Development in Cognos

Uploaded by

Copyright:

Available Formats

1.

4.1. Creating a report:

Setting Report Properties

4.2. Building report query:

Auto Group and Summarize Property

Layout Component Reference

4.5. Unit testing:

Validating your reports

You might also like