Request for comment: Global filters linked to different models

Tue, 05 May 2009 12:38:27 Z

We've found a way of implementing global filters (we use dimension property filters) for different models... and we'd like to know pitfalls of our approach (for the moment I can guess 2 :-))

Task: Apply global "Entity - Office" filter to Operations and Salary models

Approach:

1. Create all matrices and filters needed and apply corresponding filters to matrices.

Matrix 1: Model - Operations. Columns - Entity:Business unit Leaves. Rows - Account. Dimension property filter: Entity - Office.

Matrix 2: Model - Salary. Columns - Account. Rows - Entity:Employees. Dimension property filter: Entity - Office

2. Edit RDL

2a. Find filter definitions

<ReportParameter Name="PerformancePoint_ebb03fb2_b6f8_4298_91cf_ceb94ee473ff"> ' Filter from Operations Model to be applied to Salary model

…

</ReportParameter>

<ReportParameter Name="PerformancePoint_ef581824_8178_4b6b_a743_59a26f740964"> ' Filter from Salary Model to be "skipped"

…

</ReportParameter>

2b. Replace Name and Value for QueryParameters using appropriate name of one of the filters (ReportParameter) you want to use for different models:

<QueryParameter Name="PerformancePoint_ef581824_8178_4b6b_a743_59a26f740964"> ' to be replaced with see bellow

<Value>=Parameters!PerformancePoint_ef581824_8178_4b6b_a743_59a26f740964.Value</Value> ' to be replaced with see bellow

<Value>=Parameters!PerformancePoint_ebb03fb2_b6f8_4298_91cf_ceb94ee473ff.Value</Value>

</QueryParameter>

</QueryParameters>

3. That's it.

If I select Office for Operations matrix, it's also applied to Salary Matrix :-)

Guessed pitfalls:

1. Forms and reports created using this approach can't be migrated to other application - this is hardcode! :-(

2. Any change to report definition will destroy our filters override - this is hardcode! :-(

Any thoughts re other difficulties we'll meet?

Regards, Vasily

Request for comment: Global filters linked to different models

Tue, 05 May 2009 15:58:39 Z

Probably the forms and reports will migrate fine. Only the application is updated, so in a staging/production environment where all models are named the same etc it probably will work.

Probably you can make many changes to the report definition and the filters will still work. Most of that RDL only gets written when the filters are created.

Have you double checked that you can achieve writable regions in an assignment with this approach? I think you should be able to, but its worth double checking.

More pitfalls aka why this isn't supported:
3. No clear way to determine for form authors which dimensions/hierarchies are appropriate (identical) for this purpose. All that information is only exposed to the modeler.
4. No way for the end user to know what to do if the models are out of date. All relevant error messages are for the modeler.
5. If/When you have problems with this report or form you will probably have to revert the changes so that you can rule out this change as the root cause. :(

-Peter Eb.