Peter Eb. : Authoring

HOWTO: Dynamic rows or columns with a dimension property filter

petereb — Mon, 12 May 2008 18:00:00 GMT

To filter rows and columns by a filter selection has previously been discussed here . But one thing you might not have noticed is that the list of property values (aka the filter scope) is static. If a new member property appears the form needs to be...(read more)

HOWTO: Filter rows and columns by selecting from a filter

petereb — Fri, 09 May 2008 18:00:00 GMT

(Sorry for the gap since my last post, things have been a bit busy lately in Peter Eb. land…) One simple way to do this filtering is to enable suppress blank rows or suppress blank columns. Then when there is no data (non-null) in the cube for those rows/columns...(read more)

HOWTO: Hide filters for dimensions that confuse users

petereb — Thu, 24 Apr 2008 18:00:00 GMT

For data entry forms (and even some reports) its pretty important to keep contributors focused on their specific task. Its especially easy for users who are not familiar with OLAP or PPS to be confused by some things: "TimeDataView" and "Business Process"...(read more)

HOWTO: Make 1 filter control more than 1 matrix

petereb — Mon, 21 Apr 2008 16:00:58 GMT

A common request by form authors is to create a "start here" worksheet page where contributors can change some global filters. Then they advance to other worksheets in the workbook to do their actual data entry. Other times authors just want to link multiple...(read more)

Why not use the "where clause" for filters instead of "on pages"?

petereb — Fri, 18 Apr 2008 17:00:00 GMT

Short answer: In SP1 the PPS Planning add-in will use the where clause and life for MDX experts will be back to normal.*

Long answer: Because of the extra properties needed for writeback. The CellSet returned by AdoMd.Net does not return member properties for members specified in the where clause. What additional properties the add-in needs is a topic for another post. In many cases nobody notices that by putting the filter selections on pages (which is more like a crossjoin of a single element than a where filter) that there is any difference in the filter. But everybody notices when they take try to run the Matrix query in most other MDX tools like SQL Management Studio:

Executing the query ...
Obtained object of type: Microsoft.AnalysisServices.AdomdClient.CellSet
Formatting.
Results cannot be displayed for cellsets with more than two axes.
Execution complete

(Trust me, that display error irritates me an awful lot, just so you know I feel your pain if you don't like this. It's definitely something I am very excited about in SP1 that won't impact many users. But for the troubleshooters I think it is a fantastic luxury to just cut and paste the query for a change...ok you will still have to search and replace $CurrentPeriod$...)

In the matrix itself we don't really render a multi-dimensional result, we just render the first slice so that it looks like a 2D result. (And for our query we try hard to make sure that the 3D result we produce only has a single slice returned which is equivalent a 2D result and no extra data is queried other than the member properties).

So in practice the "on pages" approach worked well to simplify the rendering engine at first. But crucially there are some cases we've found where it degrades performance of the MDX query. And at least in current builds of AS2005 that PPS depends on, the cost of running an extra query to retrieve the missing member properties is negligible. So we were able to make this change in SP1. There simply wasn't enough time for us to have made this change earlier - and I don't remember if when we were working with pre-release versions of AS2005 if the second query for properties was always of negligible cost.

Another convenient side effect of this change in SP1 is that the filter selection is now conveniently available in custom MDX scenarios...but that, of course, is another post.

* As of this writing I can't promise any dates for SP1. All I've seen is what it pretty commonly known: spring 2008. We of course have an internal schedule and targets, but software releases are not easy. When the date is known and "official", It will be posted quite widely, on clearly "official" microsoft.com sites, including the technet forums as soon as there's an official date. (Oh and don't worry, asfaik the core PPS dev/test/pm team is based in the northern hemisphere so spring isn't 6 months away.)

HOWTO: Show numbers as 1,000s in Excel

petereb — Thu, 17 Apr 2008 20:00:00 GMT

Bonus post that isn't specific to PPS. HOWTO use an Excel custom number format to display a number in thousands or millions etc. ...(read more)

HOWTO: Show actuals from the past while forecasting for the future

petereb — Wed, 16 Apr 2008 15:00:00 GMT

Also phrased: How can I create an "asymmetric crossjoin" without using custom MDX? MDX experts will probably recognize this issue right away and understand how to build a matrix from scratch for this. But not everybody recognizes that the add-in has specific support for this scenario. It's called "defining member intersections" and it can be done for both rows and columns. To activate the feature select your matrix in the action pane and choose the appropriate item in the available action drop down then click the green go button:

Anyway to use it we need a matrix. So to start with lets create a typical matrix with Account on rows and Scenario/Time on columns. I'm going to pick Actuals and Forecast for Scenario, and then all the months for 2008:

By default the add-in is doing a "symmetric crossjoin" and rendering too much data for our goal (I had to shrink the column width just to be able to get the image down to a reasonable size but clearly show Actuals and Forecast plus all 12 months duplicated. Obviously at this point we could simply hide rows and columns using Excel functionality but for a large matrix this is going to pull down a lot of extra data that we don't really need for this scenario. So let's go ahead and see what happens when we define member intersections for columns with the matrix so far:

Let me draw your attention to the rendering options images along the bottom of the dialog. They are meant to visually hint the difference between rendering all intersections and one by one. So now I switch to column by column. Now as the picture indicates I have to match each member in the Scenario column with the appropriate member in the Time column. To do this I click the appropriate "Edit..." area to invoke the member picker where I duplicate the selection (just click add extra times while highlighting actual. Then make sure the order is 3 Actual's followed by Forecast. Here is what Actuals looks like duplicated 3 times in the member picker:

Intuitively you might think I now have to duplicate Forecast 8 times for the remaining 9 months, but there is a special case for this: The last member in any dimension will automatically be applied/duplicated to match the other columns. So my final define intersections choices look like this:

(Those red lines I added just to be explict about where the "intersections" are) And the matrix renders like this:

(I added the red oval and removed the matrix style so it was easier to see the dividing line between Actuals and Forecast. Typically when we are showing data rather than blank and have a writable region this is much more clear...)

This technique works for more than 2 dimensions. Although I'll be one of the first to admit that while duplicating your selections can be a little tedious sometimes, defining intersections is a very powerful feature. I personally haven't seen a lot of OLAP front-ends that allow this. One popular alternative seems to be to start with everything and then cut out the intersections that you don't like. That frequently reverts the design to static selections which isn't necessarily as convenient. What I've shown so far is also static selection since we had to do some duplication and picked each month individually. That actually made this process more tedious than necessary... Let's go back to how I selected the time members originally:

I this case I know I want the first calendar quarter to be used for Actuals and the rest of the year for Forecast. So let's define that using some sets. I'll pick lowest of Q1, then lowest of Q2, Q3 and Q4:

Those more familiar with OLAP might notice that there are many more ways to have expressed this set...that's a topic for another post. For now I'll just point out that if you can describe your set carefully then the tedious part of duplicating selections for column by column or row by row becomes unnecessary. There's even clever ways to describe the set as "from the beginning of the year until now" or "from now until the end of the year"...but that is also a topic for another post.

So I'll leave you today with some final images. First you can see there was no need to duplicate Actuals after using a set for the first part. And since the last selection gets repeated as many times as necessary I also didn't have to duplicate Forecast. I really encourage you to explore the member picker to become familiar with the kinds of expressions and sets possible. It can really make your authoring life that much easier. My goal is to help PPS report/form authors avoid learning MDX for as long as possible! (The matrix image is the same as the first asymmetric image, I'll leave it as an exercise for the reader to confirm I didn't cheat when I reused the same image)

The process is the same for rows, with just "column" in the UI replaced by "row". So I won't go through that specifically. From what I've seen the most common question around this involves Time and Scenario - especially for data-entry form templates.

"Report" authoring and PPS Planning Business Client

petereb — Mon, 14 Apr 2008 14:00:00 GMT

Sorry this isn't a super technical post, most of this information should be pretty well known by now. Ah the glory of having your own blog: you get to say a lot of junk that everybody already knows but you repeat anyway just to sound important....

Off hand there are 6-ish ways I can think of to describe how to author a report on PPS Planning data. Not all of them involve the PPS Planning Business Client (aka the add-in) but I will spend the most time with the add-in based options. The first 2 and the last 1 are the most common based on my experience.

1. Use the Action Pane interface

This interface was inspired by the PivotTable authoring interface. The major difference is how members are selected in PPS vs native Excel. In PPS we try as much as possible to just render the output of an MDX query. PivotTable's have a lot of built in organization and sub-totaling. Partly this is because they are a general purpose tool and can connect to many data sources besides just OLAP cubes. The "member picker" is the common PPS dialog that allows for advanced searching and filtering of members. In the add-in we take the dynamic or static set that the user creates and generate the MDX for the query from that. This dynamic interface is probably where the biggest difference between a Matrix and a PivotTable stems from.

PPS action pane: PivotTable task pane:

With these 2 pictures creating similar reports you can see that the lower areas describing which members or fields are selected are pretty similar. PPS hides most of the details about how to connect to the cube from the user so creation of a matrix is simple compared to the steps needed to create a PivotTable and I'm not going to go into those differences. But as far as picking members for display there are very few similarities. The PPS Member Picker allows similar static selection like a PivotTable, but it also brings OLAP concepts out front and center. Here I've selected all the top level members by choosing the children of all in the Member Picker. In the PivotTable field selection there is no equivalent so I've selected all members...

PPS member picker: PivotTable field selector:

Since the PPS member picker was designed assuming OLAP and the PivotTable UI was designed assuming multiple data sources, it isn't too surprising that there are differences. In the future, I expect we'll see more specific BI/OLAP UI in the built-in Excel functionality and as it becomes available PPS will take advantage of it. The PPS UI I think gets a great advantage from the dynamic selection sets because of the assumption of an OLAP data model. In both of these shots when the calendar is extended and new year's data is available the reports will automatically update. But in the PivotTable example you will always be stuck with a grand total appearing which may not make sense since it the annual data may not be meant to be added together. How OLAP nicely does a lot of the hard work at aggregating data and providing natural query mechanisms is another post.

2. Use the Report Wizard

This is really handy when you want to to create custom calculations in your matrix. I didn't work on this authoring experience and sometimes it feels like I have to do a lot of clicks to finish a report. But many people love this interface, and in future versions it sounds like its capabilities and template will be expanded.

The main limitation with the Report Wizard vs the Action Pane is that under the hood the query definitions are stored differently. So you have to choose ahead of time which UI interface you want to use. (You cannot switch once the matrix is created.) But once the MDX is generated internally everything is rendered the same. So really this choice is a matter of authoring style. There's a lot more hand holding with the wizard and you get calculations, and it seems to be a popular choice based on the questions I've seen in the TechNet forums.

3. Use the Report Properties Editor

Generally people don't use this for basic authoring tasks. This is just where you come when its time to change a matrix property like "Allow data entry" or to connect a filter to multiple matrices. But it was actually the first fully functional authoring interfaces we had during development. All properties are exposed here and its a fairly "techie" interface. I trust our users to be smart and capable and disagree that its too difficult. But I don't disagree that there's not a lot of bells and whistles here in terms of making it super friendly.

4. Use custom/raw MDX and RDL

Finally, when all our UI fails you we let you enter straight MDX. Unfortunately we make you split the query up into 4 parts so you can't just cut-and-paste. That's probably the only limitation here. Every MDX feature is available here and we will parse the query and insert filter selections.

And to be even more extreme, we also have the RDL tab in the Report Properties Editor which shows you what the raw format of the report looks like. (It's XML using the Reporting Services 2005 schema, with some PPS extensions to store our extra metadata that doesn't fit in the RS2005 schema).

Working at both this low level RDL and using custom MDX is another post: there are some scenarios where the UI doesn't expose some functionality very conveniently but the rendering engine can support it.

5. There is no 5....yet

With apologies to Monty Python, it is very much possible to look at how the Alpine Ski House (ASH) sample gets installed and see how to use PPSCmd to populate reports and RDL. But this is even more tedious than #4. But for completeness sake I thought I would mention it since it might be a scenario partners are interested in. Using a framework like the ASH installation could be a quick way to get some template based or pre-generated vertical installations up and running quickly. But at this point in time I don't know of anybody who is doing anything like this...

Along these lines I also don't know of any 3rd party authoring tools with explicit PPS support, but am very much looking forward to them being created. The fact that the add-in rendering engine just needs to run an MDX query should make this pretty straightforward.

6. But...don't forget about other PPS and/or OLAP tools

Dashboards and scorecards created by the Monitoring & Analytics side of PPS are another kind of important report. Management Reporter is obviously another hugely important kind of report authoring environment. I just don't know enough about M&A and MR to speak with any authority about them yet...

Because when a PPS Planning model is deployed, it is deployed to an AS 2005 cube. So just about any OLAP client can work with a PPS model. The PivotTable in Excel is one of the better known clients in MS-land. But the general point I want to make is that just because there is such a term as "report" in the add-in doesn't mean that this is the only kind of "report" you can make using PPS Planning data. SQL Reporting Services can connect both to the SQL tables and to the OLAP cubes.

The primary goal of the add-in I worked on is to facilitate data-entry to planning models. The next goal is to support reporting. But you should realize that the possibilities for creating reports are nearly limitless...

If anybody has some good links to M&A or MR blogs or resources about reporting against PPS Planning models w/o using the add-in lmk and Ill edit this post with the links. In the meantime looks like I'm going to be alternating a HOWTO with a general post for as long as I can keep coming up with general post ideas...

HOWTO: Validate 2 filter selections match using a member property

petereb — Fri, 11 Apr 2008 14:02:00 GMT

A recent post by "abdulmohi" in the PPS Planning forums asked about linking or cascading filters. So that once one filter was selected, another filter would be updated to match the first. In abdulmohi's case it was obvious what the linkage should be because there was a member property in the first dimension. There is no way to do the linkage, the user of the form or report has to change 2 values. This is a common request, but its not something we directly support today.

But there are a number of scenario's where knowing what a member property is is useful. A critical one for data writeback in financial models is making sure that the default currency for an entity is used. For example, a US based entity probably needs its data submitted in US Dollars, while a Canadian entity probably needs to submit data with Canadian Dollars. I'm sure there are other non-financial scenarios as well. (Indeed abdulmohi's scenario was around Clients and Industries.) In the entity/currency scenario there is validation on the PPS Planning server to ensure that these match. But the metadata for these validation rules is not exposed in the writable region that the add-in uses. (And we've designed the add-in to work with metadata rather than hard-coding these kinds of rules.) There are other kinds of validation like rules about models with shares and such that also aren't exposed to the add-in, but that's another post.

Still it is possible for a form template author to do create this validation in a workbook manually. They can write formulas that compare the selected values for the currency dimension and the entity dimension and build a big long list in the formula to check that the validation is correct. But this buries a lot logic in a formula in the workbook that requires being updated manually if the data changes. (Possibly a macro could be created that would dynamically generate this validation formula but that is a topic for another post...)

In the ASH data there are a number of currency-related properties in the entity dimension: CurrencyMemberId, CurrencySymbol and DefaultCurrencyName. Using the cube formulas feature of Excel 12 its possible to provide this validation in the workbook without having to embed any logic about what combinations of entities and currencies is valid. How to implement this workaround in a fairly clean fashion is what follows...

I started by creating a simple matrix with the ASH data, here's the filter's I used at first (Account+Product on rows, Time+Scenario on columns) so that I could get to leaf-level data:

Now to retrieve the correct currency for entity "ASH" I added a workbook connection to the PPS cube. In my case I already had an .odc file created on my machine since I work with PPS and PivotTables and cube formulas regularly. If you aren't familiar with this UI, it might take some experimentation to set this up. You could either create this as an .odc file or as a WorkbookConnection. Probably the deployment story as an assignment is easier if a WorkbookConnection is used. Anyway, here's a screenshot of what I have as a prerequisite for using cube formulas:

Now we can create the CubeMemberProperty formula that shows the currency used by "ASH". There are 3 parameters to CubeMemberProperty. The first is just the name of the connection created above. Skipping to the third is the name of the property we want to use: "DefaultCurrencyName". Back to second and its' a litle trickier: it's a unique MDX name for the member selected in the filter. We have the dimension name and the hierarchy name and the member name is rendered in the worksheet so if the member names are unique we can generate a MDX unique name (if the member names aren't unique, well this approach won't work). I'll use an MDX name like this: [Dimension].[Hierarchy].[Member]. So for entity ASH we want "[Entity].[CorpMgmtEnt].[ASH]". The filter selection has an extra character appended to it (or prepended for RTL display) so we have to use some LEFT and LEN magic to get just the name out. What I used for the second parameter then is:

"[Entity].[CorpMgmtEnt].[" & LEFT(B3,LEN(B3)-1) & "]"

And then the entire formula I put in C3 and looks like this:

=CUBEMEMBERPROPERTY("Alpine_Ski_House_ASH_Corporate Corporate Mgmt Reporting", "[Entity].[CorpMgmtEnt].["&LEFT(B3,LEN(B3)-1)&"]","DefaultCurrencyName")

So now my filter area looks like this:

Oops you'll notice that "USD" is not the same as "US Dollar". So to fix this I change the property rendered for currency to "Name" instead of the default property (which is Label). Then I change the filter selection so that I can pick "US Dollar" and the matrix is rerendered:

So now the user can in theory check that the selections match, but I'll go ahead and take the extra step of providing more explicit feedback with a formula like this in C1:

=IF(C3=LEFT(B1,LEN(B1)-1),"","ALERT ALERT ALERT: mismatched currency and entity")

Basically if the text of the selected entity's DefaultCurrencyName property matches the selected currency nothing is displayed, otherwise a warning message is displayed in the cell. I actually will take it one step further and combine the formula's so I only have to display something extra when the error condition happens:

=IF(CUBEMEMBERPROPERTY("Alpine_Ski_House_ASH_Corporate Corporate Mgmt Reporting", "[Entity].[CorpMgmtEnt].["&LEFT(B3,LEN(B3)-1)&"]","DefaultCurrencyName")=LEFT(B1,LEN(B1)-1),"","ALERT ALERT ALERT: mismatched currency and entity")

You might not find that formula as readable, it all depends on what your matrix layout requirements are... All I did was replace C3 with the formula that retrieves the member property value. So now I'll show what happens for selecting "Canadian Dollar" vs "US Dollar"

And that's it! Hopefully you find the this technique of using the Excel CubeFormula's and some text extraction to show additional metadata that can't be rendered in the matrix. Then extending that technique to provide for some lightweight validation. Whatever kinds of additional bells and whistles needed to draw the users attention to the error like conditional formatting and such is left as an exercise for the reader.