jam 2012 441 d l s d c - graceland university

This document is freely distributable and reproduceable as long as the authoring information is kept with it.

OVERVIEW

When a user logs into Cognos their information can be

captured by the system. That information can be used by

Cognos Authors to provide a myriad of options.

Information Specific to the User

Displaying who is running a report

Providing optional Security

Not all options are available in every situation and the

goal of this document is to provide a variety of options to

choose from.

This document was designed around having Microsoft

Active Directory as the LDAP and Jenzabar’s CX as the

ERP. If you have other systems, some modifications may

need to be made, and some options may not work/apply.

© Graceland University | James M Mueller

JAM 2012 441 DELIVERING LOGIN SPECIFIC DATA IN COGNOS


2 © Graceland University | James M Mueller

ver.05222012

Contents

OVERVIEW ....................................................................................................................................................................................... 1

Contents .......................................................................................................................................................................................... 2

Cognos Session Parameters Overview .......................................................................................................................................... 3

1: Session Parameter Types ........................................................................................................................................................ 3

2: Using Session Parameters ..................................................................................................................................................... 3

3: Special Session Parameters ................................................................................................................................................... 3

Importing the Session Parameters ................................................................................................................................................ 4

1a: User ID Number - Quickest Method (Custom LDAP) ........................................................................................................ 4

1b: User ID Number - Longest Method (Standard CX) .............................................................................................................5

2: Create the Calculations .......................................................................................................................................................... 6

Using the Session Parameters ........................................................................................................................................................ 7

1: Access to “Session Parameters” .............................................................................................................................................. 7

2: Prebuilt Filters ......................................................................................................................................................................... 7

Notes: .............................................................................................................................................................................................. 8

Appendix .......................................................................................................................................................................................... i

Option 1: Session Parameter Calculations ................................................................................................................................ ii

Option 2: Session Parameter Filters..........................................................................................................................................iv

Option 3: Using aliases of userid_table ..................................................................................................................................... v

441 DELIVERING LOGIN SPECIFIC DATA IN COGNOS JAM 2012

© Graceland University | James M Mueller 3

ver.05222012

Cognos Session Parameters Overview

All of the options that are outlined in this document depend on a feature of Cognos: Session Parameters. Session Parameters (a type of Cognos Macro) is information that Cognos retrieves from the Authentication Provider when a user initially logs into Cognos Connection. Cognos Macros are the method with which that information can be shared back to the user and/or to CX. Why? Having this information can help give users information that is directly pertinent to them without their need to interact with a report. It also can prevent users from seeing information that isn’t pertinent to them, allowing a type of security. But to do all of this we need to learn how to use Session Parameters, and a bit about Cognos Macros

Macros are discussed in the Framework Manager help file, and are available in the Expression definition editor in Framework Manager under the “Parameters” Tab as “Macro Functions” and “Session Parameters”.

All Macros that work in Framework Manager are also able to work in Report Studio. However they do not have syntax help, so an understanding of Macros will be required to use them.

1: Session Parameter Types These are the built in Session Parameters that are covered in this document.

account.personalInfo.userName

account.personalInfo.email

account.personalInfo.givenName

account.personalInfo.surname

2: Using Session Parameters All Macros begin and end with a # (hash)

Like all Data Expressions, any Expression using a Macro must have good syntax.

All Session Parameters will add the $ in front of them when you drag them into the Expression definition. If you manually type them you will need to make sure you add this.

All Session Parameters must return in a format Cognos supports. 1 Integers and Dates need no adjustment

2 Strings need to be wrapped in sq()

3 Example: #sq($account.personalInfo.surname)#

3: Special Session Parameters The biggest help of all would to be able to pull the id from id_rec for the user who is logged into Cognos straight from the Authentication source.

a) First you will need to add to your LDAP a method of storing id for every user. This document does not cover how to do this.

b) Follow instructions from https://www-304.ibm.com/support/docview.wss?uid=swg21341035 on how to add the field to your Session Parameters. Name this field: “userCXid”

c) After completing these steps the next time you open Framework Manager and open the Session Parameters in the Expression definition editor your Parameter will be listed.

https://www-304.ibm.com/support/docview.wss?uid=swg21341035





ver.05222012

Importing the Session Parameters

User ID Number will provide Report Studio authors the ability to filter reports based on who is logged in. To add this for Query Studio authors, filters using “User Logged-In: Id” will need to be created in Framework Manager in the packages wherever they make sense. The other Session Parameters will provide authors the ability to display information about the person running a report ON the report. This is useful for knowing who ran and printed a report. Two options are provided for getting Id to authors. The first requires id being loaded into LDAP and the second uses userid_table in CX. Each of the two options provides pros and cons about their usage. You will only need to do one. From a reporting / Cognos view, the best is 1a.

1a: User ID Number - Quickest Method (Custom LDAP) By getting id from id_rec into your LDAP (as outlined in “Cognos Session Parameters Overview” step 3) you will be able to quickly set up Cognos to be able to filter reports based on the user logged in. Advantages: This allows you to not have Cognos go back to CX to figure out who is logged in to create filters. This means

there is a zero impact on the database or on speed of a report using this field. Drawbacks: You will need to have a process to get ID into your LDAP. This process may take time to set up, and this

document doesn’t provide support for how to get id into LDAP, just how to get it back out if it’s there.

1: Standalone Folder Why? Having your Session Parameters stored in a separate Namespace and a separate Folder will allow you to only include the Session Parameters in Packages that you want them included in.

a) Open your Project in Framework Manager b) Create the Namespace “Extras”

1 Click the [+] by “CX” Namespace 2 Right-click the “Packaged Views” Namespace 3 Click “Create” and then click “Namespace” 4 Name the new Namespace “Extras”

c) Create the Folder “Session Parameters” 1 Right-click the “Extras” Namespace 2 Click “Create” and then click “New Folder” 3 Name the new Folder “Session Parameters” 4 Click the “Finish” button on the next window

2: Creating the Calculation Why? You will need this calculation to give to your authors to use. Report Studio authors will use this to create filters. Query Studio authors will require you to set up filters.

a) Right-click the Folder “Session Parameters” and click “Create” and then click “Calculation”

b) Name the calculation “User Logged-In: ID Number”

c) Under “Available Components:” click on the tab “Parameters”

d) Click the [+] by “Session Parameters” e) Drag “account.personalInfo.userCXid” to the

Expression Definition f) Click the “OK” button g) Change the Usage from “Fact” to “Identifier”



ver.05222012

1b: User ID Number - Longest Method (Standard CX) If you are unable to use Custom Session Parameters to bring in ID, you can still get a similar end result using the system as is to be able to filter reports based on the user logged in. Advantages: This does not require custom changes to your LDAP. Drawbacks: This requires Cognos to go to CX to get ID, increasing the load on CX and impacting the speed of Cognos

reports. Also it may make you uncomfortable due to its odd join and can makes report SQL more complex.

1: Standalone Folder Why? Having your Session Parameters stored in a separate Namespace and a separate Folder will allow you to only include the Session Parameters in Packages that you want them included in.

a) Open your Project in Framework Manager b) Create the Namespace “Extras”

1 Click the [+] by “CX” Namespace 2 Right-click the “Packaged Views” Namespace 3 Click “Create” and then click “Namespace” 4 Name the new Namespace “Extras”

c) Create the Folder “Session Parameters” 1 Right-click the “Extras” Namespace 2 Click “Create” and then click “New Folder” 3 Name the new Folder “Session Parameters” 4 Click the “Finish” button on the next window

2. Create “User ID Table: Logged In” a) Copy “User ID Table”

1 Click the [+] by “Common Schema Tables” then click the [+] by “Common Schema Lookups”

2 Right-click the “User ID Table” Query Subject and Click “Edit” and then click “Copy”

3 Right-click the “Common Data Source View” Namespace and click “Edit” and then click “Paste”

4 Rename the new “User ID Table” Query Subject “to “User ID Table: Logged In”

b) Making the Filter 1 Double click the “User ID Table: Logged In”

Query Subject 2 Click the “Filters” tab 3 Click the “Add” button 4 Name the Filter “User Logged-in:

Username” 5 Drag “Username” to the Expression definition 6 Type after it the = symbol

7 Under “Available Components:” click on the tab “Parameters”

8 Click the [+] by “Session Parameters” 9 Drag “account.personalInfo.userName” to the

Expression Definition 10 Since this is a String we need to put inside

the ## the String format:sq() Should now read the same as to the right

11 Click the “OK” Button 12 Click the “OK” Button

2.b10 Expression Definition [Extras].[User ID Table: Logged In].[

Username] =

#sq($account.personalInfo.userName)#



ver.05222012

3. Make the Join to id_rec Why? To be able to use the logged in information with a lot of fields in Cognos without allowing cross-joins we need to make a join to id_rec (which joins to most tables in Cognos). We don’t want the join to affect data, so we make it have a strange join.

a) Click on “ID Record” and ctrl-click on “User ID Table: Logged in”

b) Click on the menu item “Actions” and then click “Create” and then click “Relationship”

c) Create the Link (if Username is not SSN) 1 Select “Social Security Number” from “ID

Record” 2 Select “Username” from “User ID Table:

Logged in” 3 Set both Cardinalities to “1..1” 4 Set the Operator to “<>”

d) Create the Link (if Username is SSN) 1 Select “Name” from “ID Record” 2 Select “Username” from “User ID Table:

Logged in” 3 Set both Cardinalities to “1..1” 4 Set the Operator to “<>”

e) Click the “OK” Button

4: Creating the Calculation Why? You will need this calculation to give to your authors to use. Report Studio authors will use this to create filters. Query Studio authors will require you to set up filters.

a) Right-click the Folder “Session Parameters” and click “Create” and then click “Calculation”

b) Name the calculation “User Logged-In: ID Number”

c) Click the [+] by “Common Schema Tables” then click the [+] by “Common Data Source View” then click the [+] by “User ID Table: Logged In”

d) Drag “ID - Database” to the Expression Definition e) Click the “OK” button f) Change the Usage from “Fact” to “Identifier”

(see 1a:2.g for an image)

2: Create the Calculations a) Right-click the Folder “Session Parameters” and

click “Create” and then click “Calculation” b) Name the calculation “User Logged-In:

Username” c) Under “Available Components:” click on the tab

“Parameters” d) Click the [+] by “Session Parameters” e) Drag “account.personalInfo.userName” to the

Expression Definition f) Since this is a String we need to put inside the ##

the String format:sq() Should now read #sq($account.personalInfo.userName)#

g) Repeat steps b-g for each Session Parameter you want to include as per the chart to the right.

2.g Session Parameters account.personalInfo.userName User Logged-In: Username account.personalInfo.email User Logged-In: Email account.personalInfo.givenName User Logged-In: First Name account.personalInfo.surname User Logged-In: Last Name



ver.05222012

Using the Session Parameters

After importing the Session Parameters in, you will need to create ways for authors to be able to use them.

1: Access to “Session Parameters” You may want to prevent certain Packages from having access to the “Session Parameters” so we set them up in their own folder. Now you need to choose which Packages should have access and give it to them.

a) Add the “Session Parameters” Folder to the Package Definition of the Packages that you want to have access to it. 1 Click the [+] by “Packages” 2 Double-click the Package you want to add the

folder to. Note: This takes a while to load.

3 The “Package Definition” window will open. 4 Click the [+] by the “Extras” Namespace

5 Click the next to the “Session Parameters”

Folder which changes it to 6 Click the “OK” button 7 Publish the Package

b) Repeat step 2.h for each Package you want to include the Folder in.

1.a5 Including Folder

2: Prebuilt Filters For Query Studio authors to use Session Parameters they need to be made into prebuilt filters. For these instructions we are going to use cnslr_id from adm_rec as the example of how to create these filters.

a) Click the [+] by “Packaged Views” then click the [+] by “Recruiting and Admissions Information” then click the [+] by “Admissions Processing” then click the [+] by “Admissions Processing Filters”

b) Right-click the “Admission Application Filters” Folder and Click “Create” and then click “Filter”

c) Name the Filter “Admission Counselor Logged-In” d) Click the [+] by “Admission Application” e) Drag “Counselor ID Number” to the Expression

definition. f) Type after it the = symbol g) Click the [+] by “Extras” then click the [+] by

“Session Parameters” h) Drag “User Logged-In: ID Number” to the

Expression Definition.

Should now read the same as to the right i) Click the “OK” Button

2.h Expression Definition [Admissions Processing].[Admission

Application].[Counselor ID Number] =

[Extras].[User Logged-In: ID Number]



ver.05222012

Notes:


© Graceland University | James M Mueller i

ver.05222012

Appendix

The original document is housed at: https://my.graceland.edu/ics/GU_Groups/Group_Management/Cognos_Power_Users/Public.jnz?portlet=Reference_Documents under the JAM 2011 File Group. While the main document outlines two options for how to capture login information from Cognos and use it to drive reports, they are not the only methods. Outlined on the following pages are three other options. They are not as robust and flexible as the ones in the main document, but if you are unwilling to dive into those, these may provide you viable options instead Option 1: Session Parameter Calculations: This outlines how to bring in just the Session Parameters without the use of userid_table or the Custom Session Parameter. It is the simplest way to use Session Parameters and requires the least amount of setup. However it may not have much use, and isn’t very flexible. Option 2: Session Parameter Filters: If you want a light version of using Session Parameters to filter your data, without the larger impact of the main document, this will give you that information. Option 3: Using aliases of userid_table: If the strange join presented in the main document isn’t something that you find comfortable to use, you can get a similar effect of filtering for user id numbers using these instructions. While they require a similar amount of work for Authors to use, the Framework Manager requires more work.

https://my.graceland.edu/ics/GU_Groups/Group_Management/Cognos_Power_Users/Public.jnz?portlet=Reference_Documents




ii © Graceland University | James M Mueller

ver.05222012

Option 1: Session Parameter Calculations If you want to make Session Parameters accessible by authors with the ease of drag and drop, you need to create them as Calculations in Framework Manager first. Advantages: Having Session Parameters in their Packages allows report authors (both Query and Studio) to use them without having to know the syntax (something their studios don’t provide them help with). They can easily place them on the report, and in the case of Report Studio, use them for advanced layouts and filters. Drawbacks: Session Parameter Calculations cannot be used by Query Studio authors to create filters. For Query Studio authors more work is required and that is outlined in Option 2.

1: General Information Namespace Why? Having them stored in the General Information Namespace will allow all authors immediate access to the Session Parameters since all packages reference it.

h) Open your Project in Framework Manager i) Create the Folder “Session Parameters”

1 Click the [+] by “CX” and then click the [+] by “Packaged Views”

2 Right-click the “General Information” Namespace

3 Click “Create” and then click “Folder” 4 Name the new Folder “Session Parameters” 5 Click the “Finish” button on the next window

j) Create the Calculations 1 Right-click the Folder “Session Parameters”

and click “Create” and then click “Calculation” 2 Name the calculation “User Logged-In:

Username” 3 Under “Available Components:” click on the

tab “Parameters” 4 Click the [+] by “Session Parameters” 5 Drag “account.personalInfo.userName” to the

Expression Definition 6 Since this is a String we need to put inside the

## the String format:sq() Should now read #sq($account.personalInfo.userName)#

k) Repeat step 1.c for each Session Parameter you want to include as per the chart to the right.

1.d Session Parameters account.personalInfo.userName User Logged-In: Username account.personalInfo.email User Logged-In: Email account.personalInfo.givenName User Logged-In: First Name account.personalInfo.surname User Logged-In: Last Name


© Graceland University | James M Mueller iii

ver.05222012

2: Standalone Folder Why? Having them stored in a separate Namespace and a separate folder will allow you to only include the Session Parameters in Packages that you want them included in.

c) Open your Project in Framework Manager d) Create the Folder “Session Parameters

1 Click the [+] by “CX” 2 Right-click the “Packaged Views” Namespace 3 Click “Create” and then click “Namespace” 4 Name the new Namespace “Extras” 5 Right-click the “Extras” Namespace 6 Click “Create” and then click “New Folder” 7 Name the new Folder “Session Parameters” 8 Click the “Finish” button on the next window

e) Complete instructions 1.c and 1.d using this folder f) Add the Folder to the Package Definition of the

Packages that you want to have access to it. 1 Click the [+] by “Packages” 2 Double-click the Package you want to add the

folder to. Note: This takes a while to load.

3 The “Package Definition” window will open. 4 Click the [+] by the “Extras” Namespace

5 Click the next to the “Session Parameters”

Folder which changes it to 6 Click the “OK” button 7 Publish the Package

g) Repeat step 2.h for each Package you want to include the Folder in.

2.h5 Including Folder


iv © Graceland University | James M Mueller

ver.05222012

Option 2: Session Parameter Filters If you want to make Session Parameters accessible by all authors to quickly make filters on data items (especially useful if you are using Special Session Parameters from section 3 of Cognos Session Parameters Overview) you will need to create filters wherever you feel they are useful. Advantages: While a Report Studio author can create a filter from a Calculation, Query Studio does not offer that flexibility. To give them filters, you will need to create them in the Model at every place they are needed. From the Users viewpoint, this is simple to use, and that is its main benefit. To use the filter, they just have to drag it to their report. Drawbacks: Unless you are using Cognos Session Parameters Overview section 3 to pull in id_rec.id for the user logged in, this Option may not be useful. Adding each filter where it is needed can take some time.

1: Example For this example we are going to use the user name captured by Active Directory to dynamically filter vch_rec. Why? This sample works in the standard package because of the join from vch_rec to userid_table. We are using this sample not because it may be useful but because you can do it without having to have special changes to your model.

a) Open your Project in Framework Manager and click the [+] by the “CX” Namespace.

b) Click the [+] by “Packaged Views” then click the [+] by “Finance Information” then click the [+] by “General Ledger Accounts” then click the [+] by “General Ledger Account Filter” then click the [+] by “Transaction Entry Filters”

c) Right-click on “Journal Filters” click “Create” and then click “Filter”

d) Create the Filter 1 Name the Filter “Journals Prepared by User

Logged-In” 2 Click the [+] by “Transaction Entries” and

then click the [+] by “Journals” 3 Drag “Journal Preparer Username” to the

Expression Definition 4 Type after it the = symbol

5 Under “Available Components:” click on the tab “Parameters”

6 Click the [+] by “Session Parameters” 7 Drag “account.personalInfo.userName” to the


## the String format:sq() Should now read the same as to the right

9 Click the “OK” Button Note: If you have done Option 1, you could have used the Calculation field in your filter for steps 1.d7 and 1.d8, instead of retyping the Macro. There is no difference in how the filter will function.

1.d8 Expression Definition [Transaction Entries].[Journals].[Journal Preparer Username] =



© Graceland University | James M Mueller v

ver.05222012

Option 3: Using aliases of userid_table If you are not using Cognos Session Parameters Overview section 3 to pull in id_rec.id for the user logged in, this Option is very useful. It allows you to get the id_rec.id from the userid_table by filtering it with a Session Parameter. Advantages: By getting the id number of the person logged in, we can unlock a lot of options for dynamically changing reports. This is because many tables in CX have fields we can link to. This Option’s example is adm_rec.cnslr_id. Drawbacks: Every place that you will want to filter on the id of the user logged in, you will need to create a new alias of the query subject, and make a join. Then you will have to create a Filter as per Option 2. This can be time consuming.

1: Making the Master Query Subject First thing we need to do is to create a Query Subject that we can use again and again wherever it is needed. Why? Creating a master that we can reuse will help to minimize the amount of maintenance needed to update the Project and minimize the time needed to add new filters.

c) Open your Project in Framework Manager d) Create the Folder “User ID for Filtering”

1 Right-click the “CX” Namespace 2 Click “Create” and then click “Namespace” 3 Name the new Namespace “Extras” 4 Right-click the “Extras” Namespace 5 Click “Create” and then click “New Folder” 6 Name the new Folder “User ID for Filtering” 7 Click the “Finish” button on the next window.

e) Copy “User ID Table” 1 Click the [+] by “Common Schema Tables”

then click the [+] by “Common Schema Lookups”

2 Right-click the “User ID Table” Query Subject and Click “Edit” and then click “Copy”

3 Right-click the “User ID for Filtering” Folder and click “Edit” and then click “Paste”

f) Making the Filter 13 Double click the new “User ID Table” Query

Subject 14 Click the “Filters” tab 15 Click the “Add” button 16 Name the Filter “User Logged-in: Username” 17 Drag “Username” to the Expression definition 18 Type after it the = symbol 19 Under “Available Components:” click on the

tab “Parameters” 20 Click the [+] by “Session Parameters” 21 Drag “account.personalInfo.userName” to the


## the String format:sq() Should now read the same as to the right

23 Click the “OK” Button 24 Click the “OK” Button

Note: If you have done Option 1, you could have used the Calculation field in your filter for steps 1.d7 through 1.d10, instead of retyping the Macro. There is no difference in how the filter will function.

1.d10 Expression Definition [Extras].[User ID Table].[ Username] =



vi © Graceland University | James M Mueller

ver.05222012

2: Using the Master Query Subject Now that we have a master, we can create the aliases that we will use to make our joins wherever we need them. Why? We don’t want to use the same Query Subject for every join because that could cause loops in our model and make errors in reports.

a) Right-click the “User ID Table” Query Subject and click “Create” and then click “Alias Shortcut”

b) Rename the Shortcut “User ID Table: adm_rec” c) Make the Relationship

1 Click the [+] by “CX” then click the [+] by “Admissions Schema Tables” then click the [+] by “Admissions Data Source View”

2 Click on the “Admissions Records” Query Subject and ctrl-click on the “User ID Table: adm_rec” Shortcut.

3 Click on the menu item “Actions” and then click “Create” and then click “Relationship”

4 Link “Counselor ID Number” and “ID – Database”

5 Set the cardinality to “1..1” for both Query Subjects Why? Cognos does weird things when you use the 0..n and 1..n options. It does a “stitched query” that can cause reports to work wrong. Since we are just using this to make a filter, we don’t need it to have a 1..n setting.

6 Click the “OK” button d) Create the Filter

1 Click the [+] by “Packaged Views” then click the [+] by “Recruiting and Admissions Information” then click the [+] by “Admissions Processing” then click the [+] by “Admissions Processing Filters”

2 Right-click the “Admission Application Filters” Folder and Click “Create” and then click “Filter”

3 Name the Filter “Admission Counselor Logged-In”

4 Click the [+] by “Admission Application” 5 Drag “Counselor ID Number” to the

Expression definition. 6 Type after it the = symbol

7 Click the [+] by “Extras” then click the [+] by “User ID for Filtering” then click the [+] by “User ID Table: adm_rec”

8 Drag “ID - Database” to the Expression Definition.

Should now read the same as to the right 9 Click the “OK” Button

2.d8 Expression Definition [Admissions Processing].[Admission

Application].[Counselor ID Number] =

[Extras].[User ID Table: adm_rec].[ID -

Database]