Dynamic Reporting With Tokens and Member Unique Names

Tip or Technique

Dynamic Reporting with Tokens and Member Unique Names

Product(s): IBM Cognos ReportNet, IBM Cognos 8

Area of Interest: Reporting

Dynamic Reporting with Tokens and Member Unique Names 2

IBM Cognos Confidential Information

Copyright

Copyright © 2008 Cognos ULC (formerly Cognos Incorporated). Cognos ULC is an IBM Company. While every attempt has been made to ensure that the information in this document is accurate and complete, some typographical errors or technical inaccuracies may exist. Cognos does not accept responsibility for any kind of loss resulting from the use of information contained in this document. This document shows the publication date. The information contained in this document is subject to change without notice. Any improvements or changes to the information contained in this document will be documented in subsequent editions. This document contains proprietary information of Cognos. All rights are reserved. No part of this document may be copied, photocopied, reproduced, stored in a retrieval system, transmitted in any form or by any means, or translated into another language without the prior written consent of Cognos. Cognos and the Cognos logo are trademarks of Cognos ULC (formerly Cognos Incorporated) in the United States and/or other countries. IBM and the IBM logo are trademarks of International Business Machines Corporation in the United States, or other countries, or both. All other names are trademarks or registered trademarks of their respective companies. Information about Cognos products can be found at www.cognos.com

This document is maintained by the Best Practices, Product and Technology team. You can send comments, suggestions, and additions to [email protected] .



Contents

1 INTRODUCTION ............................................................................................ 4

1.1 PURPOSE ............................................................................................................4 1.2 APPLICABILITY .....................................................................................................4 1.3 EXCLUSIONS AND EXCEPTIONS ..................................................................................4

2 VALUES VERSUS TOKENS.............................................................................. 4

3 VALUES VERSUS MEMBERS........................................................................... 5

4 TOKEN PROMPTS .......................................................................................... 5

4.1 PROMPT SYNTAX...................................................................................................5 4.2 DYNAMIC COLUMN SELECTION ..................................................................................6 4.3 DYNAMIC HIERARCHY SELECTION............................................................................. 10 4.4 CHANGING LOGICAL OPERATIONS ............................................................................ 11 4.5 CUSTOM PROMPT CONTROLS................................................................................... 12

5 THE MEMBERUNIQUENAME PROMPT ......................................................... 13

5.1 PROMPT SYNTAX................................................................................................. 13 5.2 CONSIDERATIONS FOR DEFAULTTEXT ........................................................................ 14 5.3 CREATING AN OPTIONAL SLICER .............................................................................. 15

6 MAINTENANCE CONSIDERATIONS............................................................. 16

6.1 REPORT VALIDATION............................................................................................ 16 6.2 TOKEN PROMPTS DIRECTLY IN SQL STATEMENTS ......................................................... 17 6.3 MODEL AND REPORT CHANGES................................................................................ 17

7 SUMMARY ................................................................................................... 18



1 Introduction

1.1 Purpose

This document is designed to address advanced prompting techniques that go beyond the scope of regular data-driven prompting for reports. The techniques outlined below will cover dynamic column selection, conditional modification of filter conditions, and custom prompt controls for advanced

scenarios. Additional techniques will be outlined for using member references to satisfy an “optional” prompted slicer expression. However, the techniques are not limited to these applications and can be extended to other reporting

tasks.

1.2 Applicability

The information in this document applies to all versions of IBM Cognos ReportNet and IBM Cognos 8.

References to dimensional constructs such as members and hierarchies are only applicable to IBM Cognos 8.

1.3 Exclusions and Exceptions

The techniques outlined below are not part of a set of recommended standard reporting practices to be applied globally to all reports. The techniques should be considered only where standard reporting practices do

not meet the needs of a specific reporting task.

Note that some topics assume a basic familiarity with dimensional data

sources and concepts such as: dimensions, hierarchies, levels, members, and measures.

2 Values versus Tokens

With the default prompt syntax available in Report Studio the prompt will return a value to an expression. This value can be any of the regular data

types such as integer, varchar, decimal, date, etc. Value prompts work to act on the data that is sent to or retrieved from a data source.

Tokens on the other hand are metadata and rather than supplying values to a query they can supply the actual definition of what the query contains and

how it is to behave. This process occurs before a request is sent to the data source and in fact can be used to define what is sent to the data source for execution.

A token can take any form and does not represent any specific data type. The text defined within a token is just a series of characters until it is processed

by the query engine. For example, a token can define a model item reference such as:



[Namespace].[Query Subject].[Query Item]

Or a token can be just a portion of a model item reference that is combined

with other expressions to define the full item reference. For example a token may be used as a place holder in an item reference such as:

[Namespace].<token>.[Query Item]

The syntax above is used for illustration purposes and will be defined accurately later in this document.

A token on its own is not necessarily a valid expression and could also be part of an expression such as

[Calendar Year] <token> 2005

In such a scenario the token can be used to supply the operator for the expression. In a data item this could be a mathematical operation such as an addition or subtraction while in a filter this could be a logical operation such as greater than or less than symbol to produce a valid Boolean expression.

3 Values versus Members

When working with a dimensional package there is also an opportunity to

reference dimensional objects in expressions. One of the fundamental objects in a dimensional package is the Member.

A member isn’t a value but a member contains values. The values associated with a member can be attributes/properties or measure values.

Sometimes this can be a tough concept to grasp but it helps if you consider a member as an actual object or thing. For example, you could consider your left shoe (if you are wearing shoes right now) as a member. Your left shoe

has several attributes and measure values that may relate to it. For attributes values we might consider the following: size (11 ½ wide), colour (brown), and material (leather). Measure values that would relate to your left shoe might be: quantity owned (1) or number of times worn (42).

So, in short, a member is a distinct object reference rather than a single value on its own.

4 Token Prompts

4.1 Prompt Syntax

Normal prompt syntax in Report Studio takes the form of:

?Prompt Name?



This “smart prompt” syntax is excellent for value prompts as the query engine will automatically determine the data type (among other information) based on the context of the prompt in a given expression.

For token prompts this syntax cannot be used as a token does not fit with any of the standard data type definitions. In fact, there is no data association

for a token because the token is purely metadata supplied to the query definition.

So, to define and manipulate tokens the macro syntax must be used. The syntax of a prompt macro is as follows:

prompt ( prompt_name , datatype , defaultText , text , queryItem ,

trailing_text )

As with any macro syntax the expression must be surrounded by #

characters to identify the expression as a macro rather than part of the regular expression syntax. A token prompt named “Prompt1” would be defined as:

prompt ( 'Prompt1' , 'token' )

Further details on the remaining arguments can be found in the Framework

Manager or Report Studio User Guides. For the sake of this document we will be most concerned with the arguments: prompt_name and defaultText.

For prompt macros that are intended to satisfy value expressions the queryItem argument can also be used to obtain prompting information from a model query item reference. This information will help determine the type of prompt control and the single/multi-select behaviour of the control that will be automatically generated with the report author has not defined a prompt control for the parameter.

4.2 Dynamic Column Selection

With the power of a token prompt any expression can become subject to dynamic swapping of metadata references. By swapping model item references a single report can act as a template to satisfy multiple query

requests.

For example, a report can be designed to report sales figures by calendar year. With a token prompt the same report can be dynamically changed from reporting year by year to report the same sales figures by Customer.

This query can be designed using standard SQL expressions such as a CASE statement to display either Year or Customer in a given data item:

CASE ?Column_Prompt?



WHEN 'Year' then cast([Namespace].[Calendar Date

Dimension].[Year], character(4))

WHEN 'Customer' then [Namespace].[Customer Dimension].[Customer]

ELSE 'Invalid Selection'

END

However, with such an expression you must process the joins between the fact table containing the sales figures and both dimension tables, [Calendar

Date Dimension] and [Customer Dimension]. Considering that only one of the two dimensions is going to be displayed on the report at any one time, the extra processing for the second dimension table join may be considered

unnecessary.

Another way of achieving this same behaviour is to use a conditional block to render one list that uses Year for one condition and to render another list using Customer for a second condition.

When using the conditional block approach in IBM Cognos 8 the query engine will endeavour to minimize the SQL sent to the database. This minimization

will attempt to remove columns from the SQL that are not part of the rendered layout. In this way a conditional block can be used to change the displayed column on a report dynamically without the penalty of processing

unnecessary joins or calculations.

However, when using the conditional block approach in IBM Cognos

ReportNet the query will not be minimized as with IBM Cognos 8. In this case it would be preferable to base the lists in the conditional blocks on different

queries that would only contain the required subset of columns. i.e. Year and sales figures in one query and Customer and sales figures in a second query object.

Also, when using a conditional block the report layout becomes more complex and involves maintaining a set of duplicate information in each resulting

conditional block. Maintenance of this type of reporting practice can become impractical if it is extended too far.

As an alternative to these approaches, a token prompt can be used to swap the data item (column) references with relative ease. The CASE statement above would be replaced with the following macro:

#prompt('Column Prompt', 'token', '[Namespace].[Calendar Date

Dimension].[Year]')#



Here we can see the defaultText argument come into play for the prompt macro. The defaultText takes the form of a valid model data item reference so that when the query is validated in Report Studio there is a valid

expression available to complete the query definition. Without the model item in the defaultText argument there is the potential for an invalid query specification if the prompt is submitted with an empty value.

This prompt will now be displayed to the end users as a text prompt to supply a model data item to satisfy the query specification. However, end

users should not be expected to type in a full model item reference. To make this prompt usable to report consumers a prompt control should be created

to define the set of valid metadata references for the query.

To create this prompt a Value Prompt can be inserted from the Insertable

Objects pane in Report Studio. The prompt would be defined with a set of Static Choices as in the following table:

USE DISPLAY

[Namespace].[Calendar Date Dimension].[Year] Year

[Namespace].[Customer Dimension].[Customer] Customer

The resulting prompt will allow a user to select “Year” or “Customer” and will pass the appropriate model item reference to the query definition.

With this approach only one dimension table needs to be joined to the fact table to retrieve the required sales figures. The single join reduces some of the query complexity and can improve performance in most cases.

Another example of this type of application would be changing query subject references rather than full model item references. This would be applicable if the report needed to swap between a Fiscal Year and a Calendar Year where the model item names are the same, “Year”, but the query subject names are different.

In such a case it may be only necessary to switch a portion of the metadata reference such as:

# '[Namespace].[' + prompt('Column Prompt', 'token', 'Calendar

Date Dimension') + '].[Year]'#



Here the expression is a little more complex than the previous example but the syntax will become clear shortly. The portions of the statement in red serve to define the static portions of model item reference, i.e. the portions

that the Fiscal Year and the Calendar Year have in common. The prompt macro, in blue, will allow for dynamic replacement of the query subject name that completes the model item reference. The defaultText, in green, shows

the value required to complete the model item reference for validation purposes. The end result will be that the static portions of the reference will be concatenated with the dynamic input from the prompt to generate:

[Namespace].[Calendar Date Dimension].[Year]

Again, to make this usable for end users a Value Prompt would be defined with the following Static Choices:

USE DISPLAY

Calendar Date Dimension Calendar Year

Fiscal Date Dimension Fiscal Year

Here the user would be prompted for to select either “Calendar Year” or

“Fiscal Year” and the token prompt would supply the correct string to complete the require model item reference.

Another aspect of this approach is that it can allow a report column to be summarized rather than reporting individual details. To do so, a model item reference can be replaced by a constant text or numeric value. When using automatic grouping and summarization or applying grouping on this column this new constant value will roll up all the individual values to reflect a summary value instead of the detail values displayed with the original model item.

For example a value prompt could be defined with the following Static Choices:

USE DISPLAY

'Customer Roll-Up' Summarize

[Namespace].[Customer Dimension].[Customer] Details

When a user selects “Details” the Customer column will be used in the query and the fact data will be reported for each individual customer. When the “Summarize” prompt value is chosen then the Customer column will not be

included in the query and the report will display an aggregated fact value representing all the customers together.



To achieve a similar “summary” report some authors may attempt to use conditional formatting to suppress the display of the detail values on the report layout using the Box Type or other similar formatting properties. While

this may achieve the same result, in most cases the query must still include the detail values and process them as part of the output file before suppressing them with formatting.

Suppressing the details with formatting often means that a summary report could take as long to process as the detail report itself even though the

amount of data displayed is considerably less. Using a token prompt will remove the detail reference from the query itself and provide a more efficient

query for the summary data. This simplification of the query also means that the optimizers or materialization mechanisms of the underlying data source are more likely to assist in improving the query performance.

4.3 Dynamic Hierarchy Selection

As with selecting a data item in a relational package, the same method can be used to select a hierarchy or level reference from a dimensional package. For example, an author may wish to present a user with the ability to select

from one of three levels in a hierarchy to display on the report.

For example, if the levels were defined by:

� [Cube].[Dimension].[Hierarchy].[Level 1]



Then a token prompt could be set up as:

# '[Cube].[Dimension].[Hierarchy].' + sb(prompt('Level Prompt',

'token', 'Level 1')) #

The associated value prompt would then use the following to allow a user to select from the different levels in the hierarchy:

USE DISPLAY

Level 1 Level 1

Level 2 Level 2

Level 3 Level 3

As with the previous data item selection examples the query will be prepared at run-time with the appropriate level reference in the query. The token prompt eliminates the need for a complex result set involving the members from each level where most are conditionally hidden during rendering.



4.4 Changing Logical Operations

Modifying logical operators is much the same as changing model item references. The only difference is that instead of defining a data item the token prompt can be used to complete the rest of an expression.

For example, a token prompt can be used to give users to the option to include or exclude values from a list of valid options for a Boolean filter

expression. A lengthy list of customers would be an ideal case:

[Namespace].[Customer Dimension].[Customer Name] in (?Customer

Prompt?)

When the report needs to be executed for a large number of customers it may be very tedious to select all the customers except for the handful that

need to be excluded from the report. However if the filter expression were changed to:

[Namespace].[Customer Dimension].[Customer Name] not in (?Customer

Prompt?)

Then it becomes relatively easy to select just the handful of customers that need to be excluded. Unfortunately static filter expressions like the ones

above will not satisfy both prompting styles simultaneously.

However, with regular Boolean expressions it is possible to define a combined filter statement based on a second parameter to control the filter logic:

?Operator Prompt? = "Include" AND [Namespace].[Customer

Dimension].[Customer Name] in (?Customer Prompt?)

OR

?Operator Prompt? = "Exclude" AND [Namespace].[Customer

Dimension].[Customer Name] not in (?Customer Prompt?)

Unfortunately the additional complexity may cause some relational database engines to pass over using indexes to optimize query performance.

From the expressions above it is easy to see that the only difference between the Include and the Exclude scenarios is the addition of the “not” in the case of an Exclude filter.

The token prompt comes to the rescue again. Here the filter can be defined

as:

[Namespace].[Customer Dimension].[Customer Name] #prompt('Operator

Prompt', 'token', 'not')# in (?Customer Prompt?)

As with the dynamic column selection above a prompt is required to make the report friendly to consumers. Here the value prompt would be defined with the following Static Choices:



USE DISPLAY

Include

Not Exclude

When the report is executed the token prompt would be supplied with the

appropriate “not” or “” to satisfy the respective Exclude and Include filter scenarios.

Similar effects can be accomplished with any other Boolean operator (<, >, <=, >=, =, <>, starts with, contains, etc.) as long as the Value Prompt used

to drive the token prompt contains the appropriate Use value to complete a valid Boolean expression.

4.5 Custom prompt controls

The standard prompt controls will satisfy the majority of the reporting requirements when using token prompts. However, they do now allow for multiple selections or cases where a single prompt control must drive multiple different token prompts. For these types of applications it is possible to create custom prompts to make prompt selection easier for end users.

When defining a prompt control the key item to remember is the naming convention for prompts. Any custom prompt control must reference prompts by name with a “p_” prefix, i.e. p_<prompt name>. If you have defined a prompt with:

?PromptName?

or

prompt('PromptName', 'token')

then to submit values or tokens to this prompt you would define a custom prompt control with the name attribute set to “p_PromptName”1. Further details on syntax for HTML POST requests see the SDK Developer’s Guide.

Prompt pages are generated using standard HTML and with the “p_” naming convention in mind it is possible to generate nearly any custom prompt control with a combination of HTML and client side scripting. In the simplest case, an HTML object can be added to a prompt page from the Insertable Objects pane with the following HTML expression:

<input name="p_PromptName">

This would result in a text box prompt on the prompt page that would submit any defined value to the “PromptName” prompt used within a query.

1 If your corporate authoring guidelines suggest that you prefix all parameters in your query with “p_” to start with then the HTML-based prompt control for parameter “p_PromptName”

would need to use the HTML name attribute “p_p_PromptName”.



As a more complex example you can use other controls to set the values of multiple input prompts such as with an HTML object using the following:

<script>

function setPromptValues ()

{

document.getElementById("Prompt1").value =

"[Namespace].[Calendar Date Dimension].[Year]";

document.getElementById("Prompt2").value =

"[Namespace].[Customer Dimension].[Customer Name]";

}

</script>

<input type=hidden name="p_Prompt1" id="Prompt1">

<input type=hidden name="p_Prompt2" id="Prompt2">

<button onclick="setPromptValues()">Set Prompt Values</button>

This HTML will create two hidden input prompts that will submit values to prompts named “Prompt1” and “Prompt2”. A button will also be created that will call the scripted function to set the values for the two hidden prompts.

The ability to script and manipulate custom prompt controls adds considerable flexibility to reporting solutions as it greatly extends the built-in

capabilities of IBM Cognos 8 and IBM Cognos ReportNet. However, the creation of custom script and controls is outside the scope of IBM Cognos products. Development and debugging of these controls is the responsibility

of the report author.

5 The memberuniquename Prompt

5.1 Prompt Syntax

Thus far we have two types of prompts that we can create: value prompts for values with distinct data types and token prompts for portions of the query metadata. When we consider Member objects these do not fall into the

category of a value or directly as a simple token. Fortunately there is another prompt macro type, memberuniquename, which we can leverage to tell the query that we are working with Member objects.

Normally an author would use the prompted member syntax to define a prompt for a member. As a brief summary:

Prompting for a member from any level in a hierarchy:

[Cube].[Dimension].[Hieararchy]->?Prompt Name?



Prompting for a member at a specific level in a hierarchy:

[Cube].[Dimension].[Hieararchy].[Level]->?Prompt Name?

Prompting for a set of members from a hierarchy:

set( [Cube].[Dimension].[Hieararchy]->?Prompt Name? )

Defining a prompt macro for a member uses the same basic syntax that was used for the token prompt macro. The only difference is that the second

argument of the prompt macro becomes 'memberuniquename'.

#prompt('Prompt Name', 'memberuniquename')#

As with prompts for values, it is possible to leverage the queryItem argument

of the prompt macro to define the behaviour of the auto-generated prompt control for a prompt macro. By using a hierarchy reference a Tree Prompt will

be generated and by using a level reference a Value Prompt will be generated.

Tree Prompt:

#prompt('Prompt Name', 'memberuniquename', '', '',

'[Cube].[Dimension].[Hierarchy]')#

Value Prompt:

#prompt('Prompt Name', 'memberuniquename', '', '',

'[Cube].[Dimension].[Hierarchy].[Level]')#

While the level and hierarchy references are useful for validation and testing, most reports authored in Report Studio will leverage a prompt page with specific prompt controls. This ensures a consistent look and feel across many reports and allows for control of titles and text labels that cannot be manipulated with the auto-generated prompt controls.

5.2 Considerations for defaultText

A more important argument of the prompt macro for member prompting is the defaultText argument. This entry will allow an author to define the default Member that will be used for the parameter.

A member is defined by a “Member Unique Name”, MUN. The syntax of the MUN varies between vendors but is typically a rather lengthy string of information. For example, the following is the MUN for the “Camping Equipment” member from the Great Outdoors Company PowerCube sample provided with IBM Cognos 8.

[great_outdoors_company].[Products].[Products].[Product line]-

>:[PC].[@MEMBER].[1]



Before we get into using this type of construct it is necessary to point out that, unlike relational models, the structure of a dimensional source may change based on security applied within the model. For example, within a

PowerCube it is possible to apply an “Apex” to set the root of a hierarchy to a specific member based for a specific security group. This type of action will remove access to levels above the apexed member and the resulting level

and member references may differ between user groups. Authoring reports for that are intended to satisfy multiple groups in such a scenario requires a depth-based approach rather than targeting specific levels or MUNs to

reference members from a hierarchy.

For example, to identify the root member of a hierarchy when Apexing is in effect an author would leverage the rootMembers() function rather than referencing the full static MUN of a given member.

Given the lengthy nature of a MUN and the potential for complex expressions it is recommended that the defaultItem argument of a prompt macro for

members be abstracted within the query. So, instead of using the full expression within the prompt macro itself, a calculated query item would be created within the query that would encapsulate the MUN or expression and

the reference to this new calculated query item would be used within the prompt macro.

Returning to the “Camping Equipment” member, we would abstract the MUN by creating either creating a calculation with the MUN or using the aliased

data item created by dragging the member from the Insertable Objects pane into the query. Using this new calculation in a prompt macro would then look like:

#prompt('Prompt Name', 'memberuniquename', '[Camping Equipment]')#

5.3 Creating an Optional Slicer

Unlike detail filters, prompted member expressions in slicers do not have an optional setting. This means that a smart prompt leveraged in a slicer will always require a user to select a value.

For highly dynamic reports there will often be many prompts available to a user and many may go unused for a given report selection. In such cases a

mandatory prompt from a slicer will force users to select a member, such as the root member of a hierarchy, to proceed.

However, it is possible to use a prompt macro to select the root or default member of the hierarchy and effectively make the slicer optional so that no

user selection is required at the prompt control.

To accomplish this task we would first create a calculated member

expression, [Default Member], within the query for our default member using:



defaultMember([Cube].[Dimension].[Hierarchy])

This would then be used within the slicer expression as:

#prompt('Prompt Name', 'memberuniquename', '[Default Member]')#

For a multi-select prompt in the slicer expression we would use:

#promptmany('Prompt Name', 'memberuniquename', '[Default Member]',

'set(', '', ')' )#

The promptmany() macro function is the multi-select version of the prompt() macro function2. The ' set(' and ')' are included via the text and trailing text arguments to convert the list of members produced by promptmany() into a valid set expression for the slicer.

6 Maintenance Considerations

6.1 Report Validation

Report validation operates on the full query specification defined within a

report. When using prompt macros the query specification is no longer a constant and can change in ways that cannot be predicted by the query engine.

The validation process will only validate the current query specification as

defined by the default values of the parameters. With IBM Cognos 8 users will be prompted to supply values for prompts when the report is first validated. The values supplied will be reused for subsequent validation

operations. IBM Cognos ReportNet does not have this prompting mechanism during validation and will use the value specified in the defaultText argument of the prompt macro. If a defaultText argument is not specified then IBM

Cognos ReportNet will encounter an empty expression and will fail on validation of the report.

Using these default values for validation means that additional responses stored in the Static Choices list of a prompt control or submitted at run-time

will not be evaluated in the context of the query. The Static Choices exist as text fragments until they are used within the context of a query.

To ensure that all possible responses are valid for a token prompt it is necessary to test all possible selections that may be defined in a prompt control and made available to users.

2 Additional details on promptmany() can be found in the Framework Manager User Guide

and the Report Studio User Guide.



It is not recommended to use token prompts without a predefined set of prompt responses. Allowing type-in prompts for token prompts will open the possibility of malformed expressions being generated within the query.

6.2 Token Prompts Directly in SQL Statements

While it is possible to use token prompts within a SQL statement directly it is not recommended to do so. Allowing direct input to a SQL statement may allow users to bypass security applied within the Framework Manager model.

For example, if a security filter defines that the query should include a filter on a user account to restrict data access and a token prompt allows manipulation of a filter then it becomes possible for a user to manipulate the token text to change:

securityTable.accountID = 'user ID'

AND

FactTable.measure > #prompt('ParameterName', 'token', '42')#

so that the token produces:

securityTable.accountID = 'user ID'

AND

FactTable.measure > 1 OR 1 = 1

Because tokens allow more than simple values to be defined this means that additional expressions can be added on top of the single expected value for the measure filter. In the above example, adding “OR 1 = 1” will cause the Boolean expression to always be true and all data will be returned rather than the restricted data set for the specific user.

By ensuring that token prompts are not used within the SQL itself (by instead using them in regular queries in Report Studio or Model Query Subjects in Framework Manager) you ensure that the tokens submitted by the prompt control must conform to the listed objects within the model and their associated security restrictions.

6.3 Model and Report Changes

The Static Choices in a value prompt are considered text fragments without any linked association to data items or model items. If a Static Choice makes

reference to a data item in a report then any changes to the data item name will need to be replicated to the value defined in the list of Static Choices for

the prompt control. Because there is no link from text fragments to data items there will be no automatic update of the Static Choices value.

Similar effects will occur with model changes. The text fragments will not be evaluated during the analysis of the publish impact from Framework Manager. Any Static Choices that reference updated model items must be

modified within the report to reflect the changes in the model.



7 Summary

The ability to define and manipulate metadata within a query is a very

powerful tool. It provides a greater degree of control over the query definition and allows report consumers to interact with the query in ways that would be difficult to achieve or would perform poorly when accomplished

with other techniques.

However, maintenance of the reports and design complexity can increase

when using token prompts. Token prompts should be evaluated with these aspects in mind prior to implementing these techniques within a report.

Due to the added maintenance costs it is not recommended to adopt these techniques as an enterprise reporting standard. However, for specific

reporting tasks these techniques will add both flexibility and sophistication to reports that cannot be achieved in any other way.

Documents

Dynamic Reporting With Tokens and Member Unique Names