Cog Macros Cookbook 1

Working with Macros
In this chapter we will cover the following:

ff Adding data-level security using the CSVIdentityMap macro
ff Using the Prompt macro in native SQL
ff Making prompts optional
ff Adding a token using macros
ff Using the prompt() and promptmany() macros in query subjects
ff Showing the prompt values in a report based on security
ff String operations to get it right
ff Showing a username in the footer
Introduction
This chapter will introduce you to an interesting and useful tool in IBM Cognos BI called
Macros. They can be used in the Framework Manager as well as the Report Studio. In this
book, we are not covering the Framework Manager; therefore, I will restrict myself to the use
of macros in the Report Studio.
Generally, macros are thought to be a way to add programming and to automate tasks in most
applications; for example, in Excel macros. However, in Cognos reporting, a macro is a way to
make some key changes in the report specification at runtime based on prompt values, user
security, and so on.
The Cognos engine understands the presence of a macro as it is written within a pair of
hashes (#). It executes the macros first and puts the result back into the report specification
like a literal string replacement. We can use this to alter data items, filters, and slicers
at runtime.
Working with Macros
184
In previous versions, it was difficult to find any information about Macro Functions within
the Report Studio. With Version 10, IBM has put a new table in the data item editor to list all
macro functions and their syntax. It can be seen as the last tab when you edit a data item or
create a new calculation:
We have already seen one example of macros in the Swapping dimensions using MUN
manipulation recipe in Chapter 7, Working with Dimensional Models. In this chapter, I will
show you more examples and introduce you to more functions which you can later build
upon to achieve sophisticated functionalities.
We will be writing some SQL against the GO Data Warehouse data source. Also, we will use
the GO Data Warehouse (query) package for some recipes.
Adding data-level security using the
CSVIdentityMap macro
Let's say that a report shows the employee names by region and country. We need to
implement data security in this report so that a user can see the records only for the country
they belong to. There are User Groups already defined on the Cognos server (in the directory)
and users are made members of appropriate groups. For this recipe, I have added my user
account to a user group called Spain.
Chapter 8
185
Getting ready
Open a new list report with GO Data Warehouse (query) as the package.
How to do it...
In this recipe, we will start by creating a new list report using the following steps:
1. Drag the appropriate columns (Country, City, and Employee name) onto the report
from the Employee by Region query subject:
2. Go to Query Explorer and drag over a new detail filter.
3. Define the filter as:
[Country] in (#CSVIdentityNameList(',')#)
Working with Macros
186
4. Run the report to test it. You will notice that a user can see only the rows of the
country/countries of which he/she is a member.
How it works...
Here we are using a macro function called CSVIdentityNameList. This function returns
a list of groups and roles that the user belongs to along with the user's account name.
Therefore, when I run the report, one of the values returned will be Spain and I will see
the data for Spain.
The function accepts a string parameter which is used as a separator in the result. Here,
we are passing a comma (,) as the separator. If a user belongs to multiple country groups,
he/she will see data for all the countries listed in the result of a macro.
There's more...
This solution, conspicuously, has its limitations. None of the user accounts or roles should
be the same as a country name, because that will wrongly show data for a country the user
does not belong to. For example, for a user called Paris, it will show data for the Paris region.
So, there need to be certain restrictions. However, you can build upon the knowledge of this
macro function and use it in many practical business scenarios.
Using the Prompt macro in native SQL
In this recipe, we will write an SQL statement to be fired on the data source. We will use the
Prompt macro to dynamically change the filter condition.
We will write a report that shows a list of employees by region and country. We will use the
Prompt macro to ask the users to enter a country name. Then, the SQL statement will search
for the employee belonging to that country.
Getting ready
Create a new blank list report with the GO Data Warehouse (query) package.
How to do it...
In this recipe we will see how to use macros to pass a parameter to an SQL statement,
as follows:
1. Go to Query Explorer and drag an SQL object onto the query subject that is linked to
the list (Query1 in most cases):
Chapter 8
187
2. Select the SQL object and ensure that great_outdoor_warehouse is selected as the
data source.
3. Open the SQL property and add the following statement:
SELECT DISTINCT "BRANCH_REGION_DIMENSION"."REGION_EN"
"REGION" , "BRANCH_REGION_DIMENSION"."COUNTRY_EN"
"COUNTRY" , "EMP_EMPLOYEE_DIM"."EMPLOYEE_NAME"
"EMPLOYEE_NAME"
FROM "GOSALESDW"."GO_REGION_DIM" "BRANCH_REGION_DIMENSION",
"GOSALESDW"."EMP_EMPLOYEE_DIM" "EMP_EMPLOYEE_DIM",
"GOSALESDW"."GO_BRANCH_DIM" "GO_BRANCH_DIM"
WHERE ("BRANCH_REGION_DIMENSION"."COUNTRY_EN" IN (
#PROMPT('REGION')#))
AND "BRANCH_REGION_DIMENSION"."COUNTRY_CODE" =
"GO_BRANCH_DIM"."COUNTRY_CODE" AND "EMP_EMPLOYEE_DIM".
"BRANCH_CODE" = "GO_BRANCH_DIM"."BRANCH_CODE"
4. Hit the OK button. This will validate the query and will close the dialog box. You will
see that three data items (Region, Country, and Employee_Name) are added
to Query1.
5. Now go to the report page. Drag these data items onto the list and run the report to
test it.
Working with Macros
188
How it works...
Here we are using the Prompt macro in a native SQL statement. Native SQL allows us to
directly fire a query on the data source and use the result on the report. This is useful in
certain scenarios where we don't need to define any Framework Model. If you examine
the SQL statement, you will notice that it is a very simple one that joins three tables and
returns the appropriate columns. We have added a filter condition on country name which
is supposed to dynamically change depending on the value entered by the user.
The macro function that we have used here is PROMPT(). As the name suggests, it is used to
generate a prompt and returns the parameter value back to be used in an SQL statement.
The PROMPT() function takes five arguments. The first argument is the parameter name, and
this is mandatory. It allows us to link a prompt page object (value prompt, date prompt, and
so on) to the PROMPT() function. The rest of the four arguments are optional and we are not
using them here. You will read about them in the next recipe.

Cog Macros Cookbook 1

Uploaded by

Copyright:

Available Formats

Cog Macros Cookbook 1

Uploaded by

Document Information

Original Description:

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

Cog Macros Cookbook 1

Uploaded by

Copyright:

Available Formats

Working with Macros

In this chapter we will cover the following:

You might also like