Creating MDX metrics for MSTR
Tips and tricks
When one use MDX cubes as a data source for MSTR project, one must remember that all attributes
and metrics are not available as a standard objects in MSTR. To be able to create
level/condition/derived metrics one must use MDX Cube Catalogue and write formula using MDX
syntax and functions.
1) Level metrics
In most cases it is enough to write simple formula like:
“([Measure].[Metric ID from cube], [Atribute Name from cube].CurrentMember)”{~}
This work fine but one must have the attribute that one want to use for level in the Report
Objects. CurrentMember function can make the report run slower and Metric ID can change
during cube update.
2) Condition metrics
The easies method to create condition metric with a static filter is to ask the MDX
administrator to add it to the cube on SAP side. Sometimes it’s not an option and one must
create filtered metric on his/her own. To do so one must use ApplySimple function with the
MDX function IFF function in it.
The second case when one have to create condition metric is metric based on prompt. There
are 2 ways to create such a metric. First is to create level metric like in previous point and then
create second metric which will calculate the level metric for the value of attribute given in the
prompt with use of MDX Aggregate() function. This method is good but CurrentMember and
Aggregate functions can make the report run very long. The second approach is to create
function using ApplySimple and calculating the basic metric directly for the prompt value.
Syntax will look like this:
ApplySimple(“( #0, #1)”, ?[Prompt name] ,[MSTR metric name]) – For prompted metric
ApplySimple(“Sum( {#0:#1}, #2)”, ?[Prompt name1], ?[Prompt name2] ,[MSTR metric
name]) - For sum of metric for some range
The important thing is to use only the Element Prompts for this king of metrics and the answer
should be required.ux
3) Transformations
To make any transformations one can use simply the Lag function:
[Atribute Name from cube].CurrentMember.Lag(12) – Such syntax will return the value of the
element that is 12 places before the current one.
This syntax works fine if we have elements in some kind of order and can be used for any
attribute.
In case of Date elements like days/weeks/months/years it is better to use the ParallelPeriod
function. This function will help us with 2 problems:
1. If we don’t have full list of elements or elements are stored in strange order.
For example we have Dates in order 2/22/2012, 2/22/2011, 2/22/2010, 2/23/2012,
2/23/2011, 2/23/2010, 2/24/2012 ….
If we use [Dates].[2/23/2012].Lag(1) we will get [Dates].[2/22/2010] which is incorrect
but if we use ParallelPeriod([Dates],1,[Dates].[2/23/2012]) we will get
[Dates].[2/22/2012] which is what we would like to get for day-1.
2. If we have time hierarchy and want to make something like previous year date.
Hierarchy: [Calendar].[Year], [Calendar].[Quarter], [Calendar]. [Month],
[Calendar].[Day]
To get last year from the Day element normally we would have to do something like
[Calendar].[Day].[2/23/2012].Lag(364) but it would only work for years that have 364
days and with assumption that days are properly ordered and none date is missing.
The better way to do such a thing is
ParallelPeriod([Calendar].[Year],1,[Calendar].[Day].[2/23/2012])
Some Examples:
ApplySimple("sum({ParallelPeriod([0CALDAY],7,#0):ParallelPeriod([0CALDAY],1,#0)
},#1)", ?[Elements of Calendar Day], [Revenue]) – Metric will return the revenue for the
week before the date given in the prompt
ApplySimple("sum(MTD(ParallelPeriod([0CALDAY],365,#0)), #1)", ?[Elements of
Calendar Day], [Revenue]) – Metric will return the Month to date revenue for the date –
365 days.
More about MDX syntax and functions can be found on:
http://msdn.microsoft.com/en-us/library/ms145595