IBM Cognos 8 Report Studio Cookbook

Chapter 1. Report Authoring Basic Concepts

In this chapter, we will cover the following:

The summary filter and detail filter
Sorting options
Aggregation and rollup aggregation
Implementing IF THEN ELSE in filtering
Data formatting options
Creating sections
Hiding columns in crosstab
Examining display value and use value for prompts

Introduction

In this chapter, we will cover some fundamental techniques which will be used in your day-to-day life as a Report Studio author. In each recipe, we will take a real life example and see how it can be accomplished. At the end of the chapter, you will have learnt several concepts and ideas which you can mix-n-match to build complex reports.

Though this chapter is called 'Basic Concepts', it is not a beginner's guide or a manual. It expects the following:

You are familiar with the Report Studio environment, components, and terminologies
You know how to add items on the report page and open various explorers and panes
You can locate the properties window and know how to test run the report

Based on my personal experience, I will suggest this chapter to new developers with two days to two months of experience. If you have larger experience with Report Studio, you might want to jump to the next chapter.

In the most raw terminology, a report is a bunch of rows and columns. The aim is to extract the right rows and columns from database and present them to the users. The selection of columns drive what information is shown in the report, and the selection of rows narrows the report to a specific purpose and makes it meaningful. The selection of rows is controlled by 'Filters'. Report Studio provides three types of filtering: Detail, Summary, and Slicer. Slicers are used with dimensional models and will be covered in later chapter (Chapter 7, Working with Dimensional Models). In the first recipe, we will cover when and why to use the Detail and Summary filter.

Once we get the correct set of rows by applying the filters, the next step is to present the rows in the most business-friendly manner. Grouping and ordering plays an important role in this. The second recipe will introduce you to the sorting technique for grouped reports.

With grouped reports, we often need to produce sub-totals and totals. There are various types of aggregation possible. For example, average, total, count, and so on. Sometimes the nature of business demands complex aggregation as well. In the third recipe, you will learn how to introduce aggregation without increasing the length of query. It will also show you how to achieve different aggregation for sub-totals and totals.

The fourth recipe will build upon the filtering concept you will have learnt earlier. It will talk about implementing IF THEN ELSE logic in filters. Then, we will see some techniques around data formatting, creating sections in a report, and hiding a column in crosstab.

Finally, the eighth and last recipe of this chapter will show you how to use prompt's Use Value and Display Value properties to achieve better performing queries.

The examples used in all the recipes are based on the GO Data Warehouse (Query) package which is supplied with Cognos 8.4 installation. These recipe samples can be downloaded from the Packt Publishing website. They use the relational schema from Sales and Marketing | Sales (query) namespace.

This is similar to Database Layer of the traditional GOSales package supplied with Cognos 8.2.

Please note that though there might be slight variations to scripts or features available in different versions of Report Studio, all the recipes mentioned in this book are applicable for all versions of Cognos 8 (8.1 through 8.4).

The screenshots used throughout this book are based on version 8.4. With versions 8.3 and 8.4, you need to choose Professional Authoring Mode from the View menu.

Summary filter and detail filter

Business owners need to see the sales quantity of their product lines to plan their strategy. They want to concentrate only on the highest selling product for each product line. They would also like the facility to select only those orders that are shipped in a particular month, for this analysis.

In this recipe, we will create a list report with product line, product name, and quantity as columns. We will create optional filter on Shipment Month Key. Also, we will apply correct filtering to bring only the highest sold product per product line.

Getting ready

Create a new list report based on GO Data Warehouse (query) package. From the Sales (query) namespace, bring Product | Product Line, Product | Product Name, and Sales fact | Quantity as columns.

How to do it...

We will start with adding the optional filter on shipment month. To do that, click anywhere on the list report on Report Page. Select Filters from the toolbox.

In the Filters dialog box, add a new detail filter. Define filter as:

[Sales (query)].[Time (ship date)].[Month key (ship date)] = ?ShipMonth?

Set the usage to Optional.
Now we will add a filter to bring only highest sold Product per Product line. To achieve this, select Product line and Product name (Ctrl+select) and click on the Group button from toolbox.
This will create grouping shown as follows:
Now select the list and click on Filter button again. This time go to the Summary filters tab and add a new filter.
Define the filter as: [Quantity] = maximum([Quantity] for [Product line]).
Set usage to Required and set the scope to Product name.
Now run the report to test the functionality. You can enter 200401 as Month Key as that has data in the Cognos supplied sample.

How it works...

Report Studio allows you to define two types of filters. Both work at different grain and hence have different applications.

Detail filter

The detail filter works at the lowest level of granularity in selected cluster of objects. In our example, this grain is the 'Sales entries' stored in the 'Sales fact'. By putting a detail filter on shipment month, we are making sure that only those sales entries which fall within the selected month are pulled out.

Summary filter

In order to achieve the highest sold product per product line, we need to consider the aggregated sales quantity for the products.

If we put a detail filter on quantity, it will work at sales entry level. You can try putting a detail filter of [Quantity] = maximum([Quantity] for [Product line]) and you will see that it gives incorrect results.

So, we need to put a summary filter here. In order to let the query engine know that we are interested in filtering sales aggregated at product level, we need to set the SCOPE to Product name. This makes the query engine calculate [Quantity] at product name level and then allows only those product names where the value matches maximum([Quantity] for [Product line]).

There's more...

When you define multiple levels of grouping, you can easily change the scope of summary filters to decide the grain of filtering.

For example, if you need to show only those products whose sales are more than 1000 and only those product lines whose sales are more than 25000, you can quickly put two summary filters for [Quantity] with the correct Scope setting.

Before/After aggregation

The detail filter can also be set to apply after aggregation (by changing the application property). However, I think this kills the logic of detail filter. Also, there is no control on the grain at which the filter will apply. Hence, Cognos sets it to before aggregation by default, which is the most natural usage of the detail filter.

Aggregation and rollup aggregation

Business owners want to see the unit cost of every product. They also want the entries to be grouped by product line and see the highest unit cost for each product line. At the end of the report, they want to see the average unit cost for the whole range.

Getting ready

Create a simple list report with Product | Product line, Product | Product name and Sales Fact | Unit Cost as columns.

How to do it...

We will start by examining the Unit Cost column. Click on this column and check the Aggregate Function property.
Set this property to Average.
Add grouping for Product line and Product names, by selecting those columns and hitting the GROUP button from toolbar.
Click on the Unit Cost column and click on the Aggregate button from toolbox. Select Aggregate option from the list.
Now click again on the Aggregate button and choose Average option.
This will create footers shown as follows:
Now delete the line with Average (Unit cost) measure for Product line. Similarly, delete the line with <Unit cost> measure from Summary. The report should look like this:
Click on the Unit cost column and change its rollup aggregate function to Maximum.
Run the report to test it.

How it works...

In this recipe, we have seen two properties of the data items related to aggregation of the values.

Aggregation property

We first examined the aggregation property of unit cost and ensured that it is set to average. Remember that the unit cost here comes from the sales table. The grain of this table is sales entries or orders. This means there will be many entries for each product and their unit cost will repeat.

We want to show only one entry for each product and the unit cost needs to be rolled up correctly. The aggregation property determines what value is shown for unit cost when calculated at product level. If it is set to TOTAL, it will wrongly add up the unit costs for each sales entry. Hence, we are setting it to AVERAGE. It can be set to MINIMUM or MAXIMUM depending on business requirements.

Rollup aggregation

In order to show the MAXIMUM unit cost for product type, we create an 'Aggregate' type of footer in step 4 and set the Rollup Aggregation to Maximum in step 8.

Note

Here we could have directly selected MAXIMUM from the 'Aggregate' drop-down toolbox. But that creates a new data item called Maximum (Unit Cost). Instead, we ask Cognos to aggregate the number in footer and drive the type by rollup aggregation property. This will reduce one data item in the Query Subject and Native SQL.

Multiple aggregations

We also need to show the overall average at the bottom. For this we have to create a new data item. So, we selected unit cost and created an 'Average' type of aggregation in step 5. This calculates the Average (Unit Cost) and places it on the product line and in the overall footer.

We then deleted the aggregations that are not required in step 7.

There's more...

The rollup aggregation of any item is important only when you create the aggregation of 'Aggregate' type. When it is set to automatic, Cognos will decide the function based on data type which is not preferred.

It is good practice to always set the aggregation and rollup aggregation to meaning function than leaving as 'automatic'.

Implementing IF THEN ELSE in filters

Business owners want to see the sales quantity by order methods. However, for the 'Sales Visit' type of order method, they want a facility to select the retailer.

Therefore, the report should show quantity by order methods. For the order methods other than 'Sales Visit', the report should consider all the retailers. For 'Sales Visit' orders, it should filter on the selected retailer.

Getting ready

Create a simple list report with Order Method | Order Method and Sales Fact | Sales Quantity as columns. Group by order method to get one row per method and set the aggregation for quantity to TOTAL.

How to do it...

Here we need to apply the retailer filter only if Order Method is 'Sales Visit'. So, we start with adding a new detail filter.
Define the filter as: if ([Order method]='Sales visit') then ([Sales (query)].[Retailer site].[Retailer name] = ?SalesVisitRetailer?)
Validate the report. You will find multiple error messages.
Now change filter definition to this: (([Order method]='Sales visit') and ([Sales (query)].[Retailer site].[Retailer name] = ?SalesVisitRetailer?)) or ([Order method]<>'Sales visit')
Validate the report and it will be successful.
Run the report and test the data.

How it works...

The IF ELSE construct works fine when it is used in data expression. However, when we use it in a filter, Cognos often doesn't like it. It is strange because the filter is parsed and validated fine in the expression window and IF ELSE is a valid construct.

The workaround for this problem is to use the pair of AND..OR as shown in this recipe. The IF condition and corresponding action item are joined with AND clause. The ELSE part is taken care by OR operations with the reverse condition (in our example, Order Method <> 'Sales Visit').

There's more...

You need not use both AND and OR clauses all the time. The filtering in this example can also be achieved by this expression:

([Sales (query)].[Retailer site].[Retailer name] = ?SalesVisitRetailer?)

([Order method]<>'Sales visit')

Depending on the requirement, you need to use only OR, only AND, or the combination of AND..OR.

Make sure that you cover all the possibilities.

Data formatting options: Dates, numbers, and percentages

Virtually all the reports involve displaying numerical information. It is very important to correctly format the numbers. In this recipe, we will create a report which formats dates, numbers, and percentages.

Date transformation and formatting are important in business reports. We will see two ways of displaying MONTH-YEAR from the 'Shipment Date Key'. We will apply some formatting to a numeric column and will also configure a ratio to be displayed as percentage.

Getting ready

Create a simple list report with Product | Product line, Product | Product type and Time (Ship date) | Day key (Ship date) as columns from the Sales (query) namespace.

Also add Quantity, Unit Price, and Unit Cost from the Sales Fact Query Subject.

Create grouping on Product line and Product type.

How to do it...

We will start by adding a new calculation to convert the Shipment Day Key into a date and show in MONTH-YEAR format. So, add a new Query Calculation to the report from the toolbox.
Define the calculation as: cast([Sales (query)].[Time (ship date)].[Day key (ship date)], date).
Select this new column for the calculation and open Data Format from Properties pane. Open the Data Format dialog by clicking on the browse button next to Data Format property.
Choose the format type Date, set Date Style to Medium, and set Display Days to No.
Now select the Quantity column on the report. Choose Data Format from property and open the dialog again.
This time pick 'Number' as the type and set different properties as required. In our example recipe, we will set the number of decimal points to 2, and use brackets () as a negative sign symbol.
Finally, we will add the ratio calculation to report. For that, add a new query calculation and define it as: [Unit price]/[Unit cost].
Select this column and from Data Format property dialog, set it as Percent. Choose % as the percent symbol and set the number of decimal places to 2. Also set the Divide by Zero Characters to N/A.
Run the report to test it.

How it works...

In this recipe, we are trying multiple techniques. We are using the CAST function to convert a number to date. Also, we are checking how dates can be formatted to hide certain details (for example, days) and how to change the separator. Finally, we have tested formatting options for numbers and percentage.

CAST function

The CAST function is used to convert data from one format to another. We specify the target format in second argument. Here, we are converting to date. It converts the date key which is in YYYYMMDD format to a date.

Later, we are setting the data format for this column as date for display purpose. We have set the display days to No as we only want to display MONTH-YEAR.

Numerical format

This is straightforward. The quantity column is displayed with two decimal points and negative numbers are displayed in brackets as this is what we have set the data formatting to.

% Margin

The ratio of unit price to unit cost is calculated by this item. Without formatting, the value is simply the result of division operation. By setting the data format to Percent, Cognos automatically multiplies the ratio by 100 and displays it as percentage.

There's more...

Please note that ideally the warehouse stores a calendar table with a 'Date' type of field , or this is made available through Framework Model. So, we need not cast the key to date every time. However, this recipe is meant to show you the technique and introduce you to the casting function.

Also, we are assuming here that business needs to see the shipment month. So, they want to see MONTH YEAR format only and we are hiding the days.

Another way of achieving this is explained as follows:

Let us change the expression for Shipment Day Key column to this: [Sales (query)].[Time (ship date)].[Day key (ship date)]/10000

Now set the Data Format to Number, with the following options:

No of decimal places = 2
Decimal separator = hyphen (-)
Use thousand separator = No

Run the report to examine the output. You will see that we have gotten rid of the last two digits from the day key and the year part is separated from month part by a hyphen. This is not truly converted to MONTH YEAR but conveys the information.

The advantage here is that the numerical operation is faster than CAST to DATE. We can use similar techniques to cosmetically achieve the required result.

Creating sections

Users want to see the details of Orders. They would like to see the Order number and the details (product name, promotion, quantity, and unit sell price).

Getting ready

Create a simple list report with Sales order | Order number, Product | Product name, Sales fact | Quantity, and Sales fact | Unit sale price as columns.

How to do it...

Click on the Order number column. Hit the section button on the toolbar.
You will see that Report Studio automatically creates a header for Order number and moves it out of the list.
Notice that the Order number field is now grouped.
Run the report to test it.

How it works...

The information we are trying to show in this report can also be achieved by normally grouping on order number. That will bring all the related records together. We can also set appropriate group/level span and sorting for better appearance.

However, in this recipe, I want to introduce another feature of Report Studio called Section.

When you create a section on a column, Report Studio automatically does the following:

It creates a new list object and moves the current report object (in our case, the existing list) inside that. This is report nesting. Both the inner and outer objects use the same query.
It creates grouping on the column selected for section, which is Order Number here. Creates a Group Header for that item and removes it from the inner list.
It formats to outer list appropriately. For example, hiding the column title.

There's more...

Some of the advantages of creating sections are as follows:

As mentioned above, Report Studio does a lot of the work for you and gives a report that looks more presentable. It makes the information more readable by clearly differentiating different entities, in our case, different orders.
As the outer and inner queries are same, there is no maintenance overhead.

Hiding column in crosstab

Users want to see sales figures by periods and order method. We need to show monthly sales and year's totals. The year should be shown in the Year total row and not as a separate column.

Getting ready

Create a crosstab report with Sales fact | Quantity as a measure. Drag Time dimension | Current year and Month on rows, Order method | Order method on column as shown in the following screenshot. Create aggregation on measure.

Define appropriate sorting.

How to do it...

First, let's identify the issue. If you run the report as it is, you will notice that the year is shown to the left of the months. This consumes one extra column. Also, the yearly total doesn't have user friendly title.
We will start by updating the title for yearly total row. Select <Total(Month)> crosstab node. Change its Source type to Data item value and choose Current year as the Data item.
Run the report and check that the yearly total is shown with the appropriate year.
Now, we need to get rid of the year column on left edge. For that, click the Unlock button on Report Studio toolbar. The icon should change to an open lock (unlocked).
Now select the <#Current Year#> text item and delete it.
Select the empty crosstab node left after deleting the text. Change its padding to 0 pixels and font to 0.001 pt size.
Run the report.

As you can see the year column on the left is now successfully hidden.

How it works...

When we want to hide an object in Report Studio, we often set its Box Type property to None. However, in this case, that was not possible.

Try setting the box type of year column to None and run the report. It will look like the following screenshot:

As you can see, the cells have shifted to the left leaving the titles out of sync. This is most often the problem when Report Studio creates some merged cells (in our case, for the aggregations).

The solution to this is to format the column in such a way that it is hidden in the report.

There's more...

This solution works best in HTML output. The excel output still has a column on the left with no data in it.

You might need to define the background colour and bordering as well, so as to blend the empty column with either the page background on left or the month column on right.

Prompts: Display value versus use value

In order to achieve the best performance with our queries, we need to perform filtering on the numerical key columns. However, the display values in the prompts need to be textual and user friendly.

In this recipe, we will create a filter that displays the product line list (textual values) but actually filters on the numerical codes.

Getting ready

Create a simple list report with Product | Product name and Sales fact | Quantity as columns.

How to do it...

Open Page Explorer and click on the Prompt Pages folder. Drag a new page from Insertable Objects under Prompt Pages.
Double click on the newly created prompt page to open it for editing.
From Insertable Objects, drag Value Prompt to the prompt page. This will open a wizard.
Set the prompt name to ProductLine, and then click Next.
Keep the Createa parameterized filter option checked. For package item, choose Sales (query) | Product | Product line code. Click Next.
Keep Create new query option checked. Give the query name as promptProductLine.
Under Value to display select Sales (query) | Product | Product line .
Click the Finish button. Run the report to test it.

How it works...

When you drag a prompt object from insertable objects, Report Studio launches the prompt wizard.

In the first step, you choose the parameter to be connected to the prompt. It might be an existing parameter (defined in query filter or framework model) or a new one. In this recipe, we chose to create a new one.

Then, you are asked whether you want to create a filter. If there is already a filter defined, you can uncheck this option. In our example, we are choosing this option and creating a filter on Product line code. Please note that we have chosen the numerical key column here. Filtering on a numerical key column is standard practice in data warehousing as it improves the performance of the query and uses the index.

In next step, Report Studio asks where you want to create a new query for prompt. This is the query that will be fired on database to retrieve prompt values. Here we have the option to choose a different column for display value.

In our recipe, we chose Product line as display value. Product line is the textual or descriptive column that is user friendly. It has one to one mapping with the Product line code. For example, Camping Equipment has Product Line Code of 2101.

Hence, when we run the report, we see that the prompt is populated by Product line names, which makes sense to the users. Whereas if you examine the actual query fired on the database, you will see that filtering happens on the key column, that is, Product line code.

There's more...

You can also check the 'Generated SQL' from Report Studio.

For that, select the Tools | Show Generated SQL/MDX option from the menu.

It will prompt you to enter a value for the product line code (which is proof that it will be filtering on the code).

Enter any dummy number and examine the query generated for the report. You will see that the product line code (key column) is being filtered for the value you entered.

So, now you know how the 'Prompt display values' and 'Use values' work.

If you ever need to capture the prompt value selected by the user in expressions (which you will often need for conditional styling or drill-throughs), you can use the following two functions.

ParamDisplayValue (parameter name): This function returns the textual value which represents the display value of the prompt. In our example, it will be the product line that was selected by the user.
ParamValue(parameter name): This function returns the numeric value which represents the use value of the prompt. In our example, it will be the Product Line Code for the Product Line selected by the user.

Duane A. Rochelle Jul 02, 2010

I would definitely recommend this book to anyone looking for ideas to overcome some of many challenges encountered while trying to learn Cognos Report Studio.I work for a company which has recently made a decision to use the Cognos software platform for its performance reporting and data analysis activities. This encouraged me to attended training classes and read numerous technical books\articles on using Report Studio.For the last few months, I have been struggling to master some techniques needed to produce exceptional business reports using Report Studio. Most of the technical guides that I have read contained long drawn-out explanations that were difficult to understand.Within 1 week after purchasing the "IBM Cognos 8 Report Studio Cookbook", I was able to use 3 techniques to overcome some challenges I was having in developing some reports.The author of this book describes his techniques in a simple but effective form using "Getting Ready", "How to do it...", "How it works..." and "There's more...". This makes it easy for readers to easily interpret how to apply the technique being described. I really like the section describing "How it works..." because this is usually not included in most technical guides.This is an excellent book and well worth the price.

Amazon Verified review

Vic Oct 06, 2010

There are a number of helpful hints and tips here. Some are dead on the money. However, trying to correlate his partial explanations of his examples, to actually applying it to closely related real world issues, is a no go. On one of the pages, he refers you back to IBM's documentation, that has no explanation of the code, and worse, he uses newer code and refers back to old code that won't work on other versions.I'm surprised they didn't edit the book for grammatical errors. Someone else posted on it. For the price, its really sad.

rvfizher995 Jul 22, 2015

Pure Garbage !! Never buy it please !!