Why MUNS are important?

Being a Cognos solutions architect, I take special interest in the integration between products. Every TM1 planning or forecasting implementation I did required some degree of reporting. When Cognos BI was involved, solution demanded tight integration between TM1 and Cognos BI components. Unfortunately, this remains a fairly unexplored area with many questions still to be answered.

One of the key objectives that I pursue when integrating products is to minimize maintenance. Today, I will explore the impact of the TM1 dimension changes on the sustainability of Cognos BI Report Studio reports. Concept of Member Unique Name (MUN) is crucial to understanding the subject of this post.

In general, report developers should avoid directly referencing members in the reports; however sometimes it is not possible, e.g. when a filter needs to be created. When member is directly referenced, element identifier becomes part of the report definition. Cognos Connection user guide defines MUN as “a unique identifier for a member in IBM® Cognos® reports. It is stored in the report specification when the member is referenced in the report directly.” “If the MUN changes, members that are directly referenced in expressions, filters, or reports are no longer found.” In other words, if element is directly referenced in the report and MUN changes, user will get an error message when attempting to run the report.

Sample error messages that user may receive when member reference is no longer valid:

"QE-DEF-0461 The provided MUN does not match levels in the literal member expression."
"OP-ERR-0181 At least one invalid member reference was encountered in the query.'<…>"
"OP-ERR-0087 Expression refers to an object that does not exist: dataItem=<…>"
"No Data Available (e.g. if referenced element changed levels)"

Obviously, we want to avoid these type of messages and this is why understanding how Cognos BI manages TM1 MUNs is important.

Test Environment

I used the following product versions for my test:

I created a simple TM1 application with one cube (GA_Expense) and two dimensions: company and ga_expenses_m (measure dimension). I published Framework Manager package to Cognos Connection.

Important step of the Framework Manager Metadata Wizard (Select Locales): select alias table that you want to be displayed for each dimension. In our case, company dimension had 2 aliases (“desc” and “code_desc”). I selected code_desc alias. Currently, only one alias-table per dimension per language can be selected.

TM1 Element MUN Structure

Let’s explore how TM1 MUNs are structured using Cognos BI Report Studio. When I dropped element “C1360 – Canrock Canada” from the company dimension tree into the query Data Items in Report Studio, the following MUN was displayed:
[GA_EXPENSE].[company].[company]->:[TM].[company].[company].[@MEMBER].[C1360]

This MUN can be interpreted as follows:
[cube name].[dimension name].[hierarchy name]-> [TM].[dimension name].[hierarchy name].[@MEMBER].[tm1 element name]

As expected, my report showed alias that I selected when running Framework Manager Metadata Wizard (code_desc) – “C1360 – Canrock Canada”; however element definition stored within the report (MUN) is based on the name “C1360” and not the alias. It is good as it means that alias values changes will not affect my report in the future.

I now have access to the TM1 custom element attributes that also have unique identifiers, e.g. company local_currency attribute is expressed as:
[GA_EXPENSE].[company].[company].[local_currency]

There is also a special attribute:
[GA_EXPENSE].[company].[company].[company – Name]
This attribute value contains company code “C1360” (element name in TM1). Both attributes can be used in reports.

Alternate Hierarchy impact

As a next test, I created an alternate hierarchy in the company dimension. “C1360” has two parents: “C8115” and “C2355”.
Following that change, MUN included parent name (e.g. C8115) with the separator (^) as part of its definition. This means that C1360 was assigned two different MUNs in Cognos BI – one per parent.
[GA_EXPENSE].[company].[company]->:[TM].[company].[company].[@MEMBER].[C8115^C1360]
[GA_EXPENSE].[company].[company]->:[TM].[company].[company].[@MEMBER].[C2355^C1360]

Named Levels impact

I created named levels in TM1 in }HierarchyProperties control cube to analyze impact of levels on MUNs. I assigned some generic level names (from “Level0” to “Level5”). MUN definition has changed again; it now included Level Name as part of the MUN definition:
[GA_EXPENSE].[company].[company].[Level1]->:[TM].[company].[company].[@MEMBER].[C8115^C1360]

Same change was also applied to the attribute identifier:
[GA_EXPENSE].[company].[company].[local_currency]
It changed to:
[GA_EXPENSE].[company].[company].[Level1].[local_currency]

Measure Dimension

Measure dimension has to be defined in TM1 before publishing TM1 cube to Cognos 10. It is treated as a special dimension and behaves differently. In particular, no custom attributes are available for measures in Report Studio, even if they are defined in TM1. It is possible to select alias table to use with measures; however contrary to the regular dimensions’ behavior, measure MUN will use measure alias and not the element name.

Measure MUN with alias selected
[GA_EXPENSE].[ga_expense_m].[Input Amount]

Measure MUN with no alias selected
[GA_EXPENSE].[ga_expense_m].[INP_AMT]

Design Recommendations