PerformancePoint

PerformancePoint Filter Query suggestions

James Rogers — Wed, 04 Nov 2009 19:14:52 GMT

As I have moved forward with PerformancePoint I have made extensive use of queries for filter building. This approach has a couple of distinct advantages over the other options.

Allows filters to be dynamic and pick up new data as it becomes available. One good example of this is a date filter. We use it to keep our filters as a dynamic set of n time periods from the current time period back (i.e. lastperiods(52,exists([Date].[Week].[Week].members,[Date].[Current Date].&[1]).item(0)))
It allows the query to be tuned or tweaked to exclude empty members (there are some pitfalls here, noted later).

If you need to build a tree filter based on a hierarchy, a good query is as follows: HIERARCHIZE([Dimension].[Hierarchy].members).

A couple of things to keep in mind.

Keep your query results below 500 members. PerformancePoint doesn't seem to handle more than that very well, although I have seen cases where we have gone above that.
Be careful using MDX funtions that require cell inspection (such as NONEMPTY, filter, etc). This is problematic if you have a large cube/measure group. This can cause a scan of the measure group partitions to evaluate your query. NONEMPTY is especially bad about this and is compounded because you cannot chain filters (i.e. I can't pass a date filter into an item filter).
1. Use an additional member filter in the query that causes the query to be more specific (i.e. nonempty items for the current week's sales)
  1. NONEMPTY(HIERARCHIZE([Dimension].[Hierarchy].members),(exists([Date].[Week].[Week].members,[Date].[Current Date].&[1]).item(0),[Sales Amount]))
1. Use a very small measure group (at the query's required granularity) to satisfy the request. This requires cube changes and may not be an option. I don't recommend this as a first option because those measure groups would have little usefulness to other analysis being done in the cube as well as the down stream impact on the ETL process and cube processing.

PerformancePoint Dashboard Performance, KPI Properties and Parameter Passing - Issue Found - Solved in SP1

James Rogers — Wed, 13 Aug 2008 03:45:09 GMT

In PerformancePoint 2007 you have the capability to setup custom properties and pass them into dashboard objects. This is especially useful for simplifying dashboards where you are linking scorecard KPIs to report views. Alyson Powell Erwin outlines how to do this in the PerformancePoint MSDN blog:

http://blogs.msdn.com/performancepoint/archive/2007/12/21/passing-context-from-scorecards-to-other-report-views.aspx

This is very handy. By setting up a custom property that contains measure names for the KPI you can use one report for each data source and pass the value of the custom property into the [Measures] endpoint on the report view. If you have a scorecard with 20 KPIs from the same data source and each KPI displays two report views it trims the number of reports required from 40 to 2.

Issue Found - Solved in SP1

However, I noticed something going awry when doing my performance testing while running Profiler against the Analysis Services database. Each time I clicked on a KPI it would execute the query for the two report views as expected AND submit a query for the scorecard with NO FILTERS. This basically amounts to running the scorecard query for all time because we pass the org and date filters in from the dashboard filter selections. This obviously has a negative effect on overall query performance from the Analysis Services server. However, in testing PerformancePoint 2007 SP1 I found that this problem has been addressed although I saw no mention of it specifically in the SP1 release notes. It is easy for this issue to go unnoticed because of the good caching done by Analysis Services - provided there is sufficient CPU and memory on the Analysis Services server.

Filtering PerformancePoint Reports and Scorecards by Dimensions Different Than the Filter

James Rogers — Wed, 26 Mar 2008 02:09:04 GMT

In my earlier post NON EMPTY Filtering on PerformancePoint Scorecard, I mentioned that you may be able filter scorecards and/or reports by dimensions that are not the same as the filter by using a cross join or other MDX querying technique. This is true if the other dimension is in the same cube as the query or member selection used by the filter. Consider the following:

Cube: Sales

Dimensions: Organizational Hierarchy (lowest level is Site)

Site (this contains attributes that only apply to the site)

Filter: Org (Member Selection of Organizational Hierarchy)

Report: Sales by State/Province

Approach 1: We could put the Organizational Hierarchy dimension into the Sales by State/Province and pass the Org filter value directly into that. However, this may limit the flexibility of the report and its applicability to other dashboards. Additionally, if we were to use the report without passing a value into it we may complicate the resulting query and unnecessarily degrade the report’s query performance.

Approach 2: We apply a MDX function to the filter when it is mapped to the report filter to only show States/Provinces that apply to the Organizational Hierarchy (which are often geographically defined). The resulting Filter Formula would look something like the following:

NONEMPTY([Site].[Geography].[State].members,<<SourceValue>>)

A key cube design reminder here – make sure your cubes have a high performing default measure if you do not specify a specific measure in the NONEMPTY filter expression like the following:

NONEMPTY(NONEMPTY([Site].[Geography].[State].members,<<SourceValue>>),[Measures].[Site Count])

I like to use something that only returns one row in the base fact table per granular dimension value (i.e. one row per site). I generally set aside a measure group just to support this type of filtering or I set up a cube just to support PerformancePoint filters (to be discussed in a later post). This requires additional education on the part of publisher so they understand that the measure group or cube has very little analytical value. At a bare minimum our aggregation design needs to support the dimensions involved in the filter expression unless we have very small cubes.

One thing that would be nice would be if we could filter filters (no that is not a typo). Ideally, if we had a date filter, we would want to filter a MDX query or Member Selection filter (such as org) to only show members that have values for the applied date filter. This has value in industry Same-Store or Comparables dashboards.

Performance, Named Sets, Calculated Measures, PerformancePoint and ProClarity

James Rogers — Thu, 14 Feb 2008 04:15:46 GMT

Many legacy Analysis Services (or OLAP Services) implementations use ProClarity as a querying tool and publishing framework. The server infrastructure of ProClarity allows crafty implementers to push much of the customization in KPI’s and additional measures into the “Presentation” layer of the infrastructure. This is easier to manage and change in many cases than creating named sets and calculated members in the cubes as this generally takes a SSAS administrator.

With Microsoft purchasing ProClarity and its inclusion into PerformancePoint leads to a quandary for many solution designers. While ProClarity still works well as it was designed and is available as a report type in PerformancePoint, the ProClarity views have a very different look and feel than the native PerformancePoint report views. Also, due to the fact that the report views are basically ProClarity Web Standard views, the drill-from-anywhere-to-anywhere capabilities are not available directly though the PerformancePoint interface for these views. Additionally, the library of calculated measures and sets created and published in ProClarity are not available to PerformancePoint and thus cannot be used in scorecards and report views.

In many cases, the optimum solution here is to build these ProClarity sets and measures into their respective cubes as named sets and calculated members. CAVEAT – this is not a silver bullet solution. There is a cost in terms of SSAS processing and resources for named sets and calculated measures so this should not be done without ample testing prior to implementation in production environments.

Let’s first talk about calculated measures. Existing ProClarity solutions may have a laundry list of calculated measures in their libraries. Many times these may contain nested measures (i.e. a calculated measure that uses another calculated measure) and as these get more they tend to not perform as well as desired. First, it is important to identify which measures will get heavy use in other applications such as PerformancePoint (both scorecards and reports) and Excel. Those that have a wide range of applicability justify their creation and maintenance as calculations in their respective cubes. These calculation (and set) definitions can be extracted from the ProClarity repository database for those of you who are familiar with it. This is not a “recommended” approach in much the same way as using the “sys” tables in production code for SQL Server is discouraged. As a rule, I like to take these calculations and run through extensive performance analysis using Query Analyzer and Profiler. For instance, let’s convert a calculation that reflects sales growth over the prior week:

[Measures].[Sales]/paralleperiod([Date].[Week].[Week],1,[Date].[Week].currentmember)

The query would look something like:

With member [Measures].[Sales Growth] as ‘[Measures].[Sales]/paralleperiod([Date].[Week].[Week],1,[Date].[Week].currentmember)’

Select [Org].members on rows

,[Date].[Week].&[01/01/2007 – 01/07/2007] on columns

From sales

Where [Measures].[Sales Growth]

Make sure to test the query using dimension that can take advantage of your cube partitioning strategy (in this case [Date]). Test the query with the measure as a filter, on rows and on columns. Checking profiler to make sure that the query does not cause a scan of all process partitions or excessive subcubing. Once you have settled on a calculation formula that performs well in these cases it is now time to create the calculated member through Business Intelligence Studio. When you create the calculated member in the cube, make sure you define the format and especially the non-empty behavior. If the calculation involves division, I tend to use one of the measures from the denominator as the non-empty behavior measure. I realize that this may not always be feasible if the resulting non-empty behavior is not correct so do not do this thoughtlessly.

Next, let’s talk about named sets. Many times users and/or publishers have created dimensional sets in ProClarity to ease reporting and facilitate exception-based metrics (I will talk to this in a later post). Putting these into the cube involves much the same process as the calculated measures. First I test the named set through Query Analyzer watching with Profiler. Let’s consider a named set for a dimension Sales Type that identifies gift card sales:

{[Sales Type].[Sales Type].&[Gift Card], [Sales Type].[Sales Type].&[Vendor Card]}

Next we use this in the query:

With set [Gift Card] as ‘{[Sales Type].[Sales Type].&[Gift Card], [Sales Type].[Sales Type].&[Vendor Card]}’

member [Measures].[Sales Growth] as ‘[Measures].[Sales]/paralleperiod([Date].[Week].[Week],1,[Date].[Week].currentmember)’

Select [Org].members on rows

,[Date].[Week].&[01/01/2007 – 01/07/2007] on columns

From sales

Where ([Measures].[Sales Growth], [Gift Card])

Move the set around in the query to test it from all angles and try using it as part of an aggregate measure as well:

With set [Gift Card] as ‘{[Sales Type].[Sales Type].&[Gift Card], [Sales Type].[Sales Type].&[Vendor Card]}’

member [Measures].[Gift Card Sales] as ‘sum([Gift Card],[Measures].[Sales])’

Select [Org].members on rows

,[Date].[Week].&[01/01/2007 – 01/07/2007] on columns

From sales

Where ([Measures].[Gift Card Sales])

If the results are satisfactory then create the set in the cube through Business Intelligence Studio. Keep in mind that sets are cached in memory for each connection so extremely large sets are not recommended in some cases as are too many sets.

I tend to define the named sets at the top of my calculations definition so they can be used in all the subsequent calculations, if necessary. The sets and calculations created in Business Intelligence Studio are appended to the cube definition as an MDXScript so order of creation in the Studio is important as you must define parent sets and calculations before their dependent sets and calculations. Adding and modifying these generally does not require cube reprocessing but I have seen it happen in rare instances. Make sure you test the cube modifications first in a non-production environment to make sure that they do not require reprocessing. You wouldn’t want to do something that would cause reprocessing the cube partitions as the source data may have been purged and unrecoverable (hopefully you have planned for this with a good archive process). Since named sets are cached in memory and calculated members are generally resolved in memory, often the combination of these results in better query performance. Using named sets in calculated measures often requires aggregate functions (such as SUM) which have a higher CPU requirement so consider the calculation mdx definition carefully to find the correct balance of query performance and scalability considering your server resources. On last advantage of calculated measures is that the mdx definition is static so you lessen the likelihood of the same measure being calculated multiple, different ways which can not only end up with different results but vastly different queries and performance.

With these high-use sets and calculations defined in the cube(s) in an optimum way they are now available to all applications that connect to the cube such as PerformancePoint, Excel and Reporting Services as well as ProClarity and the resulting query performance should be more predictable than when they were in the ProClarity repository and assembled on the fly by ProClarity.

NON EMPTY Filtering on PerformancePoint Scorecard

James Rogers — Mon, 08 Oct 2007 19:13:13 GMT

For those who are familiar with PerformancePoint scorecards and dashboards, you have probably run into a problem where empty dimension values cannot be dynamically filtered on scorecards if you map the dimension to the rows or columns on the scorecard in the dashboard designer. One simple way around this is to use the NONEMPTY MDX function along with an EXISTS function call. Consider the following example:

Scorecard: Sales
Filters: Org, Time (Site is the lowest level of the Org dimension)

Requirement: Only show Sites that have values for the time selected and are Descendants of the Org selected

To solve this, create a link to the Org filter from the Scorecard (columns or rows). In the filter link formula (button on the filter link editor in dashboard designer) enter the following (with your particular dimension/hierarchy identifiers, of course):

NONEMPTY(EXISTS([Org].[Hierarchy - Org].[Level 08].members,<<SourceValue>>,'Sales'))

'Sales' is the measure group from the cube being used by the scorecard. This approach should work as well for using dimensions that may not be the same as the applied filter, though a cross-join may be required. I have not tried that yet so I will follow up on whether or not my theory is correct.