Sobald eine Service Application für den Excel Service angelegt wurde, versucht der SharePoint 2010 alle Excel Dateien (ab Excel 2007 aufwärts) im Browser zu öffnen. Für den SharePoint 2010 ist es irrelevant, ob die Enterprise Features für eine SiteCollention aktiviert oder deaktiviert sind. Falls die Features jedoch nicht aktiviert sind, bekommt der Benutzer eine Fehlermeldung.

Dieses Verhalten ist in einigen Szenarien hinderlich, wenn z.B. der SharePoint als Fileserver genutzt wird und es jedoch nur eine begrenze Anzahl an Enterprise Lizenzen für ausgewählte Benutzer gibt.

In diesem Fall muss der SharePoint Server 2010 daran gehindert werden, die „normalen“ Excel Dateien im Browser zu öffnen, indem die Websitesammlungs-Feature „Dokumente standardmäßig in Clientanwendungen öffnen“, aktiviert wird.

Sobald diese aktiv ist, werden alle Dokumente nur noch mit den lokal installieren Anwendungen geöffnet, z.B. Excel 2010 oder Word 2010.

Um dem ausgewählten Benutzer-Kreis dennoch das Öffnen von Excel Dateien über Excel Service im Browser zu ermöglichen, muss eine Dokumenten Bibliothek angelegt werden. In dieser Bibliothek werden nun die „speziellen“ Excel Dateien gespeichert. Die Berechtigung für diese Dokumenten Bibliothek sollte so eingestellt werden, dass nur Benutzer mit einer Enterprise CAL Zugriff haben.
Letztendlich muss in den erweiterten Einstellungen dieser Dokumenten Bibliothek noch die Funktion „Dokumente im Browser öffnen“ aktiviert werden.

Nachfolgend die detaillierte Beschreibung für beide Einstellungen:

Webseiten Einstellungen

1. Klickt in der SharePoint-Zentraladministration auf Websiteaktionen und anschließend auf Websiteeinstellungen.

2. Klickt auf der Seite Websiteeinstellungen im Abschnitt Websitesammlungsverwaltung auf Websitesammlungs-Features.

3. Klickt auf der Seite Features für das Feature Dokumente standardmäßig in Clientanwendungen öffnen auf Aktivieren (OpenInClient-Feature ist aktiviert), um Dokumente in der Clientanwendung zu öffnen. Klickt auf Deaktivieren (OpenInClient-Feature ist deaktiviert), um Dokumente im Browser zu öffnen.

Dokumenten Bibliothek

1. Klickt auf der Bibliothekssymbolleiste auf Bibliothekseinstellungen.

2. Klickt auf der Seite Dokumentbibliothekseinstellungen auf Erweiterte Einstellungen.

3. Wählt nun auf der Seite Erweiterte Einstellungen unter Öffnen von Dokumenten im Browser eine der folgenden Optionen aus:

In der Clientanwendung öffnen: Klickt ein Benutzer auf ein Dokument in dieser Bibliothek, wird das Dokument in der entsprechenden Clientanwendung geöffnet (sofern verfügbar).

Im Browser öffnen: Klickt ein Benutzer auf ein Dokument in dieser Bibliothek, wird das Dokument in der Webbrowserwebanwendung für diesen Dokumenttyp geöffnet. Wenn das Dokument in der Webanwendung geöffnet wird, kann der Benutzer auswählen, ob das das Dokument in der Clientanwendung geöffnet werden soll.

Serverstandardeinstellung verwenden: Klickt ein Benutzer auf ein Dokument in dieser Bibliothek, wird das Dokument gemäß dem Standardöffnungsverhalten geöffnet, welches für den Server vorgesehen ist, auf dem die SharePoint 2010-Produkte installiert sind.

 Wenn nun nur noch die Monate Januar-April im Month-Parameter ausgewählt werden, erscheint folgendes Chart:

Die Daten werden per MDX aus einem Cube gelesen und im Dataset mit einem Subselect oder in der WHERE-Bedingung gefiltert:

SELECT

 {[Measures].[Sales Amount]} ON 0,

 NON EMPTY

 {([Date].[Calendar].[Date].ALLMEMBERS )} ON 1

 FROM

 (SELECT ( STRTOSET(@DateCalendarYear, CONSTRAINED) ) ON 0

 FROM

 (SELECT ( STRTOSET(@DateMonthofYear, CONSTRAINED) ) ON 0

 FROM [Adventure Works]))

Der Kunde wünscht nun, dass die übrigen Monate aber dennoch (mit dem Wert 0) angezeigt werden sollen. Hierfür gibt es zum einen die Möglichkeit, dieses bereits im MDX-Query zu lösen. Dies geschieht über einen String-Vergleich in einem IIF-Block. Leider ist diese Methode recht unperformant.

Ein besseres Ergebnis kann man mit dieser Methode erzielen, vorausgesetzt man verwendet SQL Server ab Version 2008 R2:

Im Dataset werden zunächst alle Daten für das Jahr geholt:

SELECT

 {[Measures].[Sales Amount]} ON 0,

 NON EMPTY

 {([Date].[Calendar].[Date].ALLMEMBERS )} ON 1

 FROM

 (SELECT ( STRTOSET(@DateCalendarYear, CONSTRAINED) ) ON 0

 FROM [Adventure Works])

Dann wird ein zweites Dataset „GueltigeMonate“ erstellt, in dem die Monate anhand des Parameters gefiltert werden:

WITH

MEMBER [Measures].[ParameterCaption] AS [Date].[Month of Year].CURRENTMEMBER.MEMBER_CAPTION

MEMBER [Measures].[ParameterValue] AS [Date].[Month of Year].CURRENTMEMBER.UNIQUENAME

MEMBER [Measures].[ParameterLevel] AS [Date].[Month of Year].CURRENTMEMBER.LEVEL.ORDINAL

SELECT

{[Measures].[ParameterCaption], [Measures].[ParameterValue], [Measures].[ParameterLevel]} ON COLUMNS ,

[Date].[Month of Year].ALLMEMBERS ON ROWS

FROM

(SELECT STRTOSET(@Monate,CONSTRAINED) ON 0

FROM [Adventure Works])

Nun müssen beide Datasets miteinander verbunden werden. Hierzu werden die Eigenschaften der Serie geöffnet:

Im Feld für die Daten (Value) wird nun der Lookup gegen das Dataset „GueltigeMonate“  hergestellt. Hierfür wird die Funktion „Lookup“ benötigt. Die Syntax sieht so aus:

=IIF(LEFT(Fields!Month.Value,LEN(Fields!Month.Value)-5)=

LOOKUP(LEFT(Fields!Month.Value,LEN(Fields!Month.Value)-5), Fields!ParameterCaption.Value,Fields!ParameterCaption.Value,”GueltigeMonate”),

Sum(Fields!Sales_Amount.Value),0)

Diese Syntax bewirkt folgendes:

Wenn der Monatsname im Haupt-Dataset gleich einem Monatsnamen ist, der im gefilterten Monats-Dataset vorhanden ist, so wird der Wert angezeigt, ansonsten wird die Zahl 0 angezeigt.

Wenn nun im Bericht die gleiche Selektion wie am Anfang beschreiben durchgeführt wird, ergibt sich das gewünschte Bild: 

Die Anzeige-Geschwindigkeit konnte mit der Lookup-Methode gegenüber der Behandlung im Query halbiert werden. In einem der nächsten Blog-einträge werde ich die Lookup-Funktion dann nochmal näher beleuchten.

In my last post I wrote about using delta values instead of full snapshots. However, the amount of data is identical if we using a sparse snapshots instead. For this purpose, the source data from my last post has just to be converted to absolute values as shown below:

Only delta values		Only snapshots (changes)

So the amount of data is not really changed. But with the sparse snapshots the computations get a lot more difficult. If we have delta values (left table) we can simply sum up all deltas to a given date and this works for all of our related tables (for example products). With sparse snapshots (right table) we have to find out the last value per product and then add the results up to the total, so we have to do a calculation per product before.

Before we get to the calculation, here is the very simple source data model that I used:

It took me some time to figure out the following solution and I’m pretty sure that there must be an easier method. So feel free to experiment and write comments.

Here is the final code:

Stock:=
    SumX(
        Summarize(
            ‘Product’
            ,  ‘Product’[Product]
            , "LastStock"
            , calculate(
                Sum(‘Stock’[StockLevel])
                , dateadd(
                    LastDate(‘Date’[Date])
                    ,-floor(
                        LastDate(‘Date’[Date])
                        –
                        MaxX(
                            Filter(
                                Summarize(
                                    DatesBetween(‘Date’[Date], date(2000,1,1), LastDate(‘Date’[Date]))
                                    ,’Date’[Date]
                                    , "X"
                                    ,  calculate(Sum(‘Stock’[StockLevel]), ALLEXCEPT(‘Date’, ‘Date’[Date]))
                                )
                                , not isblank([X])
                            )
                            , ‘Date’[Date]
                        )
                        , 1
                    )
                    ,DAY
                )
            )
        )
        ,
        [LastStock]
    )

This is how are data looks like without the computation from above:

Since the data is sparse we only see the stock at dates where there are changes. For the aggregation I used the Sum function (which doesn’t make much sense here for the date aggregates) and you also see that the row total over the products only takes products into account when there are changes.

And here is the resulting Excel pivot table using the calculation from above:

As you can see the value for Quickerstill starts with 20 then drops to 18 at January 3, then to 15 at January 5 etc. Also the totals are correct now.

The remaining part of this post is about the formula from above, so it’s up to you to decide if you want to continue reading. The most important point here is that the calculation is much easier when working with delta rows or delta rows with intermediate snapshots (for example each first day of a month, quarter, year).

Details of the calculation

The first question is about the way we’re doing the calculation. Wouldn’t it be easier and faster to have them on the rows and therefore persisted (is ‘persisted’ the right term when talking about an in-memory database??)? Well, if you look at the screenshots above, the only reason we’re doing all this is because we need calculated values on “rows” that do not exist. In the last screenshot there is no row for January 31, but the value has to be computed: For Notate it’s the value of January 1 and for Quickerstill it’s the value of January 21. So we have to use a calculated measure in the model.

To makes things easier here, let’s start with a single product (Quickerstill). I want to calculate the last date for which I have a value. To do this I filter the date range from a very early date (2000/1/1 here) to the last date in the current context to those values, where the sum of the stock amount (any aggregate would do) is not blank, then take the biggest date (max function). This is the code:

Step1:=
    MaxX(
        Filter(
            Summarize(
                DatesBetween(‘Date’[Date], date(2000,1,1), LastDate(‘Date’[Date]))
                ,’Date’[Date]
                , "X"
                ,  calculate(Sum(‘Stock’[StockLevel]), ALLEXCEPT(‘Date’, ‘Date’[Date]))
            )
            , not isblank([X])
        )
        , ‘Date’[Date]
    )

If I include the original measure and this calculation in a pivot table, this is the result:

For each day our calculation returns the last date with data. For example the calculated date for January 12 is January 6 as this was the last day with data before January 12. It seems we are already close to the solution but please keep in mind that the calculation from above would not work for more than one product (for example if the products are not filtered) as the date for each product has to be different. If we filter the pivot table from above for product Notate, the results would look totally different. Here are the first rows:

But let’s ignore this for a second and keep the filter on Quickerstill. The next task would be to calculate the stock level at the calculated date. This sounds easy and the following formula was my first approach:

Step2 (with error):=
    calculate(
        Sum(‘Stock’[StockLevel])
            ,MaxX(
                    Filter(
                        Summarize(
                            DatesBetween(‘Date’[Date], date(2000,1,1), LastDate(‘Date’[Date]))
                            ,’Date’[Date]
                            , "X"
                            ,  calculate(Sum(‘Stock’[StockLevel]), ALLEXCEPT(‘Date’, ‘Date’[Date]))
                        )
                        , not isblank([X])
                    )
                    , ‘Date’[Date]
                )
    )

The code in blue is the exactly the code from above which gives the filter context for the calculation of the sum of the stock level values. However, this results in an error:

Semantic Error: A function ‘MAXX‘ has been used in a True/False expression that is used as a table filter expression. This is not allowed.

I love the ‘This is not allowed’ here. Actually there is no reason why it isn’t and I’m not feeling like I’m doing something illegal here. Maybe it’s also just a limitation of the CTP 3 beta release that I am currently working with. I also tried to wrap the MaxX function in a DateAdd with 0 days but this is also ‘not allowed’.

But there is a way which can be found after some time of experimenting. I take the number of days between the last date from the context and the date from the calculation in blue and use this result to correct my last date. Sounds confusing? Let’s start with the number of days. Here is the next step of the calculation:

Step2:=
    floor(
        LastDate(‘Date’[Date])
        -
        MaxX(
            Filter(
                Summarize(
                    DatesBetween(‘Date’[Date], date(2000,1,1), LastDate(‘Date’[Date]))
                    ,’Date’[Date]
                    , "X"
                    ,  calculate(Sum(‘Stock’[StockLevel]), ALLEXCEPT(‘Date’, ‘Date’[Date]))
                )
                , not isblank([X])
            )
            , ‘Date’[Date]
        )
        , 1
    )

Again the code in blue is the last date calculation from above (step 1). Let’s take a look at the result of this calculation:

As you see, the new calculation tells us, how many days we have to go back in time to find a value. For example for January 14 we get a value of 8 meaning we have to go back 8 days to January 6 to find a value. Now we can wrap this in the calculation of the stock value and for some reason that I don’t understand, this is not illegal anymore although I’m doing exactly the same as I did before. Here is the calculation:

Step3:=
    calculate(
        Sum(‘Stock’[StockLevel])
        , dateadd(
            LastDate(‘Date’[Date])
            ,-floor(
                LastDate(‘Date’[Date])
                –
                MaxX(
                    Filter(
                        Summarize(
                            DatesBetween(‘Date’[Date], date(2000,1,1), LastDate(‘Date’[Date]))
                            ,’Date’[Date]
                            , "X"
                            ,  calculate(Sum(‘Stock’[StockLevel]), ALLEXCEPT(‘Date’, ‘Date’[Date]))
                        )
                        , not isblank([X])
                    )
                    , ‘Date’[Date]
                )
                , 1
            )
            ,DAY
        )
    )

Again the code from the last step is colored blue (step 2). Now we’re pretty close to the final formula. Let’s check the result when including both products:

Now the result for each product is already working correctly. But the total is still not correct as you can see from the line marked in red. For January 2 the last date with data is the same for both products (January 1), therefore the value is correct. But for January 3 there are different days for the last stock value, so we only see one product in the total.

However, the remaining part is not difficult. We simply summarize (group) by product and take the sum. Again, the code in blue is the last code from the step before (step 3):

Stock:=
    SumX(
        Summarize(
            ‘Product’
            ,  ‘Product’[Product]
            , "LastStock"
            , calculate(
                Sum(‘Stock’[StockLevel])
                , dateadd(
                    LastDate(‘Date’[Date])
                    ,-floor(
                        LastDate(‘Date’[Date])
                        –
                        MaxX(
                            Filter(
                                Summarize(
                                    DatesBetween(‘Date’[Date], date(2000,1,1), LastDate(‘Date’[Date]))
                                    ,’Date’[Date]
                                    , "X"
                                    ,  calculate(Sum(‘Stock’[StockLevel]), ALLEXCEPT(‘Date’, ‘Date’[Date]))
                                )
                                , not isblank([X])
                            )
                            , ‘Date’[Date]
                        )
                        , 1
                    )
                    ,DAY
                )
            )
        )
        ,
        [LastStock]
    )

Now, this does the trick and we end up with the final screenshot as shown at the beginning of this post.

If you like you can play with the formula by downloading the sample work book here (right click on the link, then choose ‘Save as…’). You will need the PowerPivot Add-In CTP 3 or later in order to open the workbook.

Die wohl auffälligste Änderung in SharePoint 2010 zu den vorherigen Versionen, ist die Integration der bereits aus den Office Produkten bekannten Ribbon Leiste. Wie so vieles im SharePoint kann auch diese von Entwicklern erweitert und angepasst werden.

Im Folgenden wird ein Beispiel gezeigt, um eine eigene Schaltfläche in die Ribbon Leiste zu integrieren.

Zur Anpassung der Ribbon Leiste wird ein neues Feature mit Visual Studio 2010 erstellt. Dies vereinfacht das spätere Deployment durch die Erstellung einer wsp Datei.

Es empfiehlt sich immer mit einem Projekt vom Typ “Empty SharePoint Project” zu beginnen. Dieses ist flexibel und ermöglicht es, mehrere Features, Webparts etc. zu bündeln.

Bei der Erstellung fragt Visual Studio ab, ob eine Sandboxed Solution oder eine Farm Solution erstellt werden soll. Für dieses Beispiel ist eine Sandboxed Solution vollkommen ausreichend. Eine Farm Solution sollte nur dann erstellt werden, wenn die Möglichkeiten der Sandboxed Solution nicht mehr ausreichen.

Mit dem Visual Studio 2010 wurde das Entwickeln von SharePoint Solutions um ein Vielfaches vereinfacht. Es gibt mehr Templates und eine sehr gute Integration von Standard-Aufgaben in die Oberfläche. So wird beim Erstellen des neuen Projektes z.B. direkt ein “Feature” Verzeichnis angelegt. Mit einem Rechtsklick auf dieses Verzeichnis kann ein neues Feature erstellt werden.

Die nun erstellte “Feature1.feature” Datei ist eine Art grafische Oberfläche für die Feature.xml Datei. Diese muss also nicht noch zusätzlich erstellt werden, im Gegensatz zur Elements.xml Datei, welche noch immer selbst geschrieben werden muss. Ein Template für die Elements.xml bekommt man z.B. durch das Hinzufügen eines “Empty Elements”. Ich empfehle an dieser Stelle die Elements.xml Datei immer über diesen Weg einzubinden, das macht die Solution übersichtlich.

Ein Blick auf das Feature zeigt, dass die Elements.xml Datei automatisch referenziert wurde.

Nachdem nun alle für das Feature erforderlichen Dateien vorhanden sind, muss die Elements.xml Datei noch mit Leben gefüllt werden.

In der MSDN findet man viele Beispiele zum Anpassen der Ribbon Bar. Darunter auch diese einfache Elements.xml Datei:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction
  Id="DemoHelloWorldButton"
  RegistrationType="List"
  RegistrationId="101"
  Location="CommandUI.Ribbon">
    <CommandUIExtension>
      <CommandUIDefinitions>
        <CommandUIDefinition
         Location="Ribbon.Documents.New.Controls._children">
          <Button
           Id="Ribbon.Documents.New.Controls.DemoHelloWorldButton"
           Alt="Hello World Ribbon Button"
           Sequence="10"
           Image32by32="/_layouts/images/PPEOPLE.GIF"
           Command="Demo_HelloWorld"
           LabelText="Hello World Demo"
           TemplateAlias="o2"/>
        </CommandUIDefinition>
      </CommandUIDefinitions>
      <CommandUIHandlers>
        <CommandUIHandler
         Command="Demo_HelloWorld"
         CommandAction="javascript:alert('Hello World!');" />
      </CommandUIHandlers>
    </CommandUIExtension>
  </CustomAction>
</Elements>

Das CustomAction Element zeigt an, dass eine neue CustomAction hinzugefügt werden soll. Als CustomAction werden z.B. die Erweiterung der SharePoint Oberfläche mit Schaltflächen oder neuen Links in den Settings Seiten bezeichnet.

Über die Attribute RegistrationType und RegistrationId wird bestimmt, für welche Elemente die Custom Action (in diesem Fall die Schaltfläche) sichtbar sein soll. Das Attribut RegistrationType kann die folgenden Werte enthalten:

• None
• List
• ContentType
• ProgId
• FileType

Damit wird der Typ angegeben, an den die CustomAction gebunden wird. Die RegistrationId bestimmt dann das konkrete Element. In obigem Beispiel wird die Schaltfläche nur in Dokumentenbibliotheken angezeigt (Typ List und RegistrationId 101).

Eine sehr gute Übersicht über die verschiedenen Registration IDs findet sich z.B. in Mike Smith Blog unter http://techtrainingnotes.blogspot.com/2008/01/sharepoint-registrationid-list-template.html.

Im CommandUIExtension Element wird die eigentliche Schaltfläche definiert. Das CommandUIDefinition Element beinhaltet hierbei die Definition der Darstellung und das CommandUIHandler Element beinhaltet die eigentliche Funktionalität hinter der Schaltfläche.

Das Location Attribut im CommandUIDefinition Element gibt an, an welcher Stelle die Anpassung in der Oberfläche dargestellt werden soll. Im obigen Beispiel wird die Schaltfläche in der Ribbon Leiste auf dem “Document” Tab in der Gruppe “New” angezeigt. Der folgenden MSDN Seite können einige Standardpfade für die Ribbon Elemente entnommen werden: http://msdn.microsoft.com/en-us/library/ee537543.aspx

Das Id Attribut im Button Element muss immer einen eindeutigen Wert haben. Hier empfiehlt sich eine GUID oder eine Mischung aus der Location der Schaltfläche und dem Namen des Features.

Das Sequence Attribut gibt an, in welcher Reihenfolge die Schaltflächen innerhalb einer Gruppe auf der Ribbon Leiste dargestellt werden sollen.

Über die beiden Attribute Image32by32 und Image16by16 werden die Grafiken definiert, welche für die Schaltfläche angezeigt werden sollen. Diese Bilder müssen im Verzeichnis /_layouts/images auf dem Server vorhanden sein (z.B. C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\1033\IMAGES bei einer englischen Standardinstallation).

Das Command Attribut im CommandUIDefinition Element identifiziert später die im CommandUIExtension/CommandUIHandler Element definierte Funktion, welche von der Schaltfläche aufgerufen wird. Es ist wichtig, an beiden Stellen den selben Wert für das Command Attribut einzutragen.

Der LabelText ist der Text, der unterhalb der Schaltfläche auf der Ribbon Leiste angezeigt wird. Es empfiehlt sich diese Texte von vornherein zu lokalisieren.

Das TemplateAlias Attribut definiert die Größe und Darstellung der Schaltfläche.

Die Definition des CommanUIHandler Elements ist sehr einfach. Über das Command Attribut wird die Verbindung zur Schaltfläche hergestellt. Daher muss dieses den selben Wert enthalten wie das Command Attribut des Button Elements. Im CommandAction Attribut wird z.B. eine Javascript Funktion angegeben, welche beim Anklicken der Schaltfläche ausgeführt werden soll.

Mehr braucht es nicht. Das Feature kann nun deployed werden. Dies kann auf einer Entwicklungsumgebung direkt aus dem Visual Studio heraus, oder mit Hilfe der Power Shell erfolgen.

Soll das Feature über die Power Shell deployed werden, so muss zunächst eine wsp Datei erstellt werden. Auch dies kann nun über das Visual Studio 2010 selbst geschehen, es sind keine zusätzlichen Tools mehr nötig. Dazu aus dem Kontextmenü des Projektes den Punkt “Package” auswählen.

Ist die wsp Datei erstellt, erfolgt das Deployment über die folgenden PowerShell Befehle:

1. Add-SPSolution “<Pfad>\CustomRibbonButton.wsp”

2. Install-SPSolution –Identity CustomRibbonButton.wsp –GACDeployment

Das Feature kann dann wie gewohnt über die Site Features (Site Settings –> Site Features) oder über den PowerShell Befehl “Enable-SPFeature” aktiviert werden.

Die neue Schaltfläche ist jetzt in der Gruppe “New” auf dem “Documents” Tab aller Dokumentenbibliotheken vorhanden und führt wie gewünscht ein einfaches Java Script aus.

A common way to compress large amounts of snap shot data is to store delta values instead of each snapshot value. This makes sense, if the data does not change every day. But for a good query performance you might not want to aggregate data over long periods.Therefore it makes sense to have a regular absolute snapshot value in the data and to use deltas between those snapshots. The work needed to create the periodic snapshots is usually done in the ETL process.

For my example, I’m using the following data table with absolute snapshot values as the first row of the month and deltas afterwards:

For example, for our product Quickerstill we start with a stock level of 20 boxes at the beginning of January 2011. Then, at January 3, 2011 we sold two of them (-2) and again on January 5 another 3 boxes (-3).

The goal is to create a measure that gives us the current stock level at each date (also on the dates between the delta rows).

In order to do so, we need a ‘real’ date dimension, so we have a separate date table that is linked to our facts. This is how this simple model looks like:

The measure DeltaStock is the original stock value from our table above (mixture of snapshots and deltas).

In order to perform the desired computation we can simply use the month-to-date formula as each day’s value computes as the sum from the first day of the month to the current day (including all deltas).

This is the simple formula we’re using to compute the stock at each day:

Stock:=TOTALMTD(SUM([DeltaStock]),’Date’[Date])

It’s amazing how simple this calculation is. Let’s take a look at the result. In order to see the effect, I added the original stock column together with the new computed column.

As you can see, we now have a stock for each day that computes correctly from the mixture of snapshot and deltas values.

Of course we could also do the calculation without the absolute snapshot values in between. In this case we have to aggregate the values from the very beginning up to the current date. First let’s take a look at the source data without the absolute snapshots:

The data is pretty much the same as in the first approach. Only the rows for the absolute snapshots are missing (apart from the first initial values).

In this case the calculation would look like this:

Stock:=
  SumX(
     DATESBETWEEN(
        ‘Date’[Date]
        , date(2000,1,1)
        , lastdate(‘Date’[Date])
     )
     ,calculate(
         Sum(‘Stock’[DeltaStock])
         ,ALLEXCEPT(‘Date’,'Date’[Date])
      )
  )

The calculation is still pretty simple. However I would prefer the option with the snapshot values in between for performance reasons and because these snapshots can be easily created in ETL (if they are not delivered from the source system).

Just two more remarks before I finish this post. The first one is about the DatesBetween range in the formula above. I’m using 2000/1/1 as the start date. However if you take a look at the returned dates only the existing rows from our date table are returned if they are matching this date range. So we could also write 1900/1/1 without risking to end up with a lot of rows.

The other remark is about the future time. Since our calculation takes the last value as the value for all the future, you will find values for all entries of the date dimension. This might not be wanted. In this case you can wrap the calculation from above inside an if statement to check the date:

StockClipped:=
  if(
    firstdate(‘Date’[Date])>Now()
    , Blank()
    ,SumX(
       DATESBETWEEN(
          ‘Date’[Date]
            , date(2000,1,1)
            , lastdate(‘Date’[Date])
         )
         ,calculate(
           Sum(‘Stock’[DeltaStock])
           ,ALLEXCEPT(‘Date’,'Date’[Date])
       )
     )
  )

With this modification (which also works with the formula for the absolute intermediate snapshots from above) values are only shown for periods that are over or have at least started. So the formula would return a value for the full year 2011 once the year has started. If you only want to see values for periods that have ended, you can replace the function ‘firstdate’ with a ‘lastdate’.

In Reporting Service lässt sich die Gruppierung einer Tabelle, einer Matrix oder eines Charts extrem dynamisch gestalten. Als Grundlage für dieses Beispiel dient die Datenbank „AdventureWorksDW2008R2“.

Das Ergebnis sollte in etwa so aussehen:

1. DataSet mit folgendem Query anlegen:

SELECT

PC.EnglishProductCategoryName AS Category

,PSC.EnglishProductSubcategoryName AS Subcategory

,P.EnglishProductName AS ProductName

,G.EnglishCountryRegionName AS Country

,G.StateProvinceName AS State

,FIS.SalesAmount

FROM dbo.FactInternetSales FIS

INNER JOIN dbo.DimProduct P

ON FIS.ProductKey = P.ProductKey

INNER JOIN dbo.DimProductSubcategory PSC

ON P.ProductSubcategoryKey = PSC.ProductSubcategoryKey

INNER JOIN dbo.DimProductCategory PC

ON PSC.ProductCategoryKey = PC.ProductCategoryKey

INNER JOIN dbo.DimCustomer C

ON FIS.CustomerKey = C.CustomerKey

INNER JOIN dbo.DimGeography G

ON C.GeographyKey = G.GeographyKey

2. Matrix aus Toolbar hinzufügen

3. Feld „Category“ auf RowGroups ziehen

4. Feld „Country“ auf ColumnGroups ziehen

5. Feld „SalesAmount“ in Data-Feld der Matrix ziehen

6. Feld „Subcategory“ auf RowGroups unter Gruppe „Category“ ziehen

7. RowGroup „Category“ umbenennen in „ParentRowGroup“

8. RowGroup „Subcategory“ umbenennen in „ChildRowGroup“

9. ColumnGroup „Country“ umbenennen in ColumnGroup

10. Die Textboxen der Matrix entsprechend benennen

11. Parameter „ParentGroupParam“ anlegen:

12. Zwei weitere Parameter anlegen:

NAME	PROMPT
ChildRowGroupParam	Select Child Row Group
ColumnGroupParam	Select Column Group

13. Eigenschaften von „ParentGroupParam“ öffnen und unter „Available Values“ folende Einträge vornehmen:

14. Auf gleiche Weise werden die Einträge in „ChildGroupParam“ vorgenommen:

LABEL	VALUE
Country	Country
State/Province	State

15. Im Parameter „ChildRowGroupParam“ wird eine Anzeige-Logik hinterlegt. Dabei wird dieser Parameter in Abhängigkeit zum Parameter „ParentRowGroupParam“ gebracht:

LABEL	VALUE
=IIF(Parameters!ParentRowGroupParam.Value= "Category","ProductSubcategory",Nothing)	=IIF(Parameters!ParentRowGroupParam.Value= "Category","Subcategory",Nothing)
Product Name	ProductName

16. Eigenschaften von „ParentRowGroup“ öffnen und den Expression-Button neben „Group on:“ drücken und folgende Expression eingeben:

=Fields(Parameters!ParentRowGroupParam.Value).Value

17. In gleicher Weise werden auch die anderen Gruppen behandelt:

GROUP	GROUP ON EXPRESSION
ChildRowGroup	=Fields(Parameters!ChildRowGroupParam.Value).Value
ColumnRowGroup	=Fields(Parameters!ColumnGroupParam.Value).Value

18. In den Textboxen werden die gleichen Expressions wie in der „Group on“ – Expression verwendet:

TextboxName	Expression
ParentRowGroup	=Fields(Parameters!ParentRowGroupParam.Value).Value
ChildRowGroup	=Fields(Parameters!ChildRowGroupParam.Value).Value
ColumnRowGroup	=Fields(Parameters!ColumnGroupParam.Value).Value

Der Bericht kann nun nach verschiedenen Kriterien gruppiert werden.

Early this year I stumbled across a very interesting Windows desktop gadget, that is capable of showing an Excel Services element on the Windows desktop. Here, element can be a certain named region, a pivot table or a chart in an Excel Services document. The technology for showing this element is the Excel Services REST API (REST stands for Representational State Transfer).

You can find the article about the desktop gadget as well as the download link for the gadget itself here. Installation and configuration of the gadget is pretty well explained on the linked site, so I can keep this short here.

After adding the gadget to your desktop, the gadget still needs to be configured.

By clicking on the gadget configuration icon, the configuration dialog is displayed:

So the simple idea is to create a nice pivot table and to use this as the basis for the gadget. For my example I created a simple pivot table based on the Finance perspective of the Adventure Works OLAP cube. For the pivot table I have the year on the filter, the sales amount and the operating profit KPI as the data and the departments on the rows.

If we use this large table in our gadget, the thumbnail view gets pretty much “microscopic”:

So, for the thumbnail (default) view you should choose a much smaller area. The flyout (detail view) is much better, but the KPI indicators and the filters are not shown:

So, here are a few tips and tricks you can use to make the gadget look nicer.

1. Use time filters for current year, current month etc.

Of course we want our gadget to always show the latest values. Because of the auto refresh interval, we don’t have to care about this. But usually we will also use a time filter to restrict the data to a specific week, month etc. Since we don’t see the filter, the idea is to have this set automatically to the current time.

This can be easily done in the Excel Pivot Table by using date filters. Unfortunately, these filters don’t work in the filter area, so we have to place the time hierarchy on the rows or columns. Then we can apply a filter (for example current year) as shown here:

For Adventure Works this would not result in any data since the sample date is only available for the years shown in the screenshot. However, in real life scenarios, this would be a good choice for the filter.

2. For thumbnail view, convert the pivot table to formulas

Formulas are much easier to handle and to format, compared to a pivot table. Remembering the very narrow available space for the thumbnail view, having full control of the layout is important. You may even want to hard-code the thumbnail view. Let me explain what I mean. In order to have the connection name at a single place, we start in a blank sheet by putting the connection name in a named cell called “OLAPConnection” (feel free to choose a different name):

As the next step, let’s construct the current date member. From Management Studio, we can see that the MDX name of the time members looks like this (may be different in your cube, this example is taken from the Adventure Works sample database):

• [Date].[Calendar].[Calendar Year].&[2001]
• [Date].[Calendar].[Month].&[2001]&[1]
• [Date].[Calendar].[Date].&[20010101]

Here we have January 1, 2001. This is easily constructed using Excel’s time functions. So we simply add these fields to our Excel sheet

Of course you could also add fields for the previous month, the week etc., just depending on the needs of your scorecard. I named the cells B4 as MDXYear, B5 as MDXMonth, B6 as MDXDay. This is how the result looks like:

I had to fake the current date in order to see some values. Therefore I replaced the formula for today with this one:

=Date(2004, Month(Now()), Day(Now()))

Of course, you won’t want to do this in a real life scenario but since the sample dataset contains no data for 2011 I had to use this “time machine formula”.

Before you start wondering what all this is good for, let’s query some data. For example, let’s assume that we want to see the operating profit (which is on the account ‘Operating Profit’) for the current year. So this would by our Excel formula:

=CUBEVALUE(OLAPConnection,"[Measures].[Amount]","[Account].[Accounts].[Operating Profit]",MDXYear)

In order to show this value in our gadget, I placed it on a new sheet and adjusted the column width and height a little bit.

In order to get a nice flyout, I also created a simple pivot chart in the Excel sheet, showing the operational profit during the year. After saving the Excel file, our gadget now looks like this:

And here is the flyout:

3. (Conditional) background colors and fonts are preserved in the REST API

In order to include a kind of traffic light approach, we already found out that Excel indicators are not yet supported in the REST API. However, conditional formatting is supported, so you can easily create a scorecard like the follow:

Also KPI indicators can be created using special characters, for example from the WingDings font as shown in the following example:

For this example, I used a separate table of banding ranges and an Excel VLookup to find the appropriate color for the indictor. Here, 1=green, 2=yellow, 3=red. In the Excel cell I used conditional formatting to choose the text color appropriately. But as we always want to display a certain element (here, the diamond from the WingDings font), I used a custom format for each of the cells, so the number (1, 2 or 3) is not shown but only one character. The corresponding character for the diamond is “u”, so the custom format looks like this:

And of course, there is a lot more you can do with all these formatting, cube functions etc.

3. Make changes to the source code of the gadget

You can extract the gadget or modify the source code of the gadget yourself. After installing the gadget, the extracted sources can be found here:

%LOCALAPPDATA%\Microsoft\Windows Sidebar\Gadgets

After modifying the sources, the gadgets need to be switched off and on in order for the changes to apply. The main file is the gadget.html here. For example you could change the link “By Excel Services” to point on your SharePoint server. To do so, a simple change in the source is needed:

Before:
<tr><td id="dockedTitle" width="100%">
<a id="leftDockedTitleLink" href="http://blogs.msdn.com/cumgranosalis/pages/excel-services-windows-7-gadget.aspx">By Excel Services</a>
</td><td>

After:
<tr><td id="dockedTitle" width="100%">
<a id="leftDockedTitleLink" href="http://srv1/PowerPivot/Forms/AllItems.aspx">All reports</a>
</td><td>

I also changed the background color here, so this is how the result looks like:

As you can see, you can do a lot of interesting things with this simple but very powerful desktop gadget.

4. Use parameters

If you want to use the same Excel Services file for more than one user you may want to pass parameters from each individual instance of the desktop gadget to the Excel Services file. This is also possible, however there are some things to take care of.

The syntax for passing a parameter is

Ranges(‘cellname’)=value

Here, cellname is a named cell in Excel that we want to pass the value to. This is how it is entered in the desktop gadget, if our named cell is named ‘value1’ and we want to pass ‘xyz’:

Multiple parameters may be passed by separating them with an ampersand, for example

Ranges(‘value1′)=xyz&Ranges(‘value2′)=42&Ranges(‘value3′)=01

This could be our corresponding view in the desktop gadget:

I just added a field that concatenates all three parameters to show that the Excel Services sheet is recomputed based on the passed values.

As you can see, all parameters are passed to the gadget. However, numeric parameters are considered as numbers in Excel, so 01 was changed to 1. If you want to prevent this, add a ‘ in front of each text.

This is how the parameters should look like when you want to make sure, text is passed as text (and not converted to a number or date) in Excel:

Ranges(‘value1′)=‘xyz&Ranges(‘value2′)=42&Ranges(‘value3′)=‘01

You should also be aware, that this string is passed to the URL “as it is”. So you have to encode all characters that are not allowed in a URL.

For example, if you want to pass the year 2006 from AdventureWorks, the unique name of the date member would be:

[Date].[Calendar].[Calendar Year].&[2006]

In order to pass this to the gadget, you have to encode blanks, the square brackets and the ampersand. So the result would look like this:

Ranges(‘parDate’)=%5BDate%5D.%5BCalendar%5D.%5BCalendar%20Year%5D.%26%5B2006%5D

This is very difficult to read. Therefore I recommend just to pass the key (2006 in this case) as the parameter and to construct the unique name in Excel using a formula like

="[Date].[Calendar].[Calendar Year].&[" & parDate & "]"

Of course, there are a lot more things you can do with this simple, yet powerful Windows desktop gadget. Like with most other gadget you may also place more than one instance of the gadget on your desktop, so you can have different scorecards. You can also add links to your Excel sheet, so that you can jump directly to a dashboard for a specific key performance indicator. Just start playing with the gadget and see how powerful und useful it is.

Bislang war ich Nutzer eines iPhone 4 und durh das Gerät auch ziemlich verwöhnt. Gerade im privaten Bereich unterstützt mich das iPhone bei vielen Dingen des Alltags.

• Meine Musik verwalte ich über iTunes. Es ist mir möglich die Musik über verschiedene Geräte im Haus abzuspielen (AirPort und Apple TV).
• Die zahlreichen Apps lassen einen immer wieder auf das Gerät schauen, ob Nachrichten, Sportergebnisse oder die neusten Facebook Nachrichten.

Dem neuen HTC Gerät mit Windows Phone 7 wollte ich eine Chance geben, also setzte ich die SIM Karte ein und legte los. Der erste Eindruck war durchaus positiv. Die Bedienung per Touch ist mindestens genauso folgsam wie beim iPhone. Sicher braucht man zunächst eine kurze Zeit, um sich an die geänderte Navigation zu gewöhnen. Die Startseite macht einen sehr guten Eindruck. Die neuen Kacheln des Metros Designs gefallen mir sehr gut. Inhalte werden direkt auf den Kacheln dargestellt, Dokumente oder Internet Seiten können auch direkt als Kachel auf der Startseite angebracht werden.

Interessant war für mich vor allem die Integration der Microsoft Programme. Hier sehe ich für mich die eigentliche Stärke gegenüber dem iPhone. Hier die Vorteile im Überblick:

• Mails lassen sich mit der Kennzeichnung flaggen. Durch diese Kennzeichnung lassen sich Mails im Outlook dann später leichter wiederfinden und nachbearbeiten.
• Es lassen sich Aufgaben darstellen und bearbeiten. Das ist im iPhone leider gar nicht möglich.
• Bei Aufgaben lässt sich ein Erinnerungsdatum hinterlegen. Dann wird die Aufgabe auch im Kalender angezeigt.
• Dokumente (Word, Excel und OneNote) lassen sich direkt im Gerät bearbeiten. Ideal ist das vor allem in Verbindung mit SharePoint oder dem eigenen Live Account. Die Dokumente werden übersichtlich dargestellt und können auch direkt auf einer Kachel dargestellt werden. Bei der Dokumentation der Beiträge der Partnerkonferenz wurden so meine Notizen direkt in unserem SharePoint gespeichert. Zurück am Arbeitsplatz waren so die Inhalte direkt verfügbar.
• Aufgaben lassen sich auch als “Privat” kennzeichnen. Eigentlich selbstverständlich, aber im iPhone leider nicht möglich.
• Abgesagte Termine lassen sich kommentieren. Auch das ist beim iPhone nicht möglich.
• Bei Teilnehmern eines Termins lassen sich auch optionale Teilnehmer hinzunehmen.
• Das zusammenlegen der Kontaktinformationen aus allen verfügbaren Konten (Outlook, Windows Live, Facebook) ist ein tolles Features. Insgesamt ist die Integration der Social Media Daten sehr gelungen.
• Die Kamerataste an der Seite erlaubt das Fotografieren auch bei gesperrtem Gerät.
• Auch die Sync Software Zune macht einen prima Eindruck.
• Apps im Marketplace sind noch nicht ganz in der Fülle verfügbar, können aber die wichtigsten Themen auch sehr gut abdecken.
• Bing Suche hat mich positiv überrascht. Vor allem die Musiksuche und die Möglichkeit Texte einzuscannen und diese unmittelbar zu übersetzen. Das kann sicherlich im nächsten Urlaub von großem Nutzen sein.

Insgesamt macht das Telefon und das Betriebssystem einen sehr guten und gelungenen Eindruck. Ich habe Spaß an dem Gerät und werde es in Verbindung mit meinem iPhone (eher privater Nutzen) weiter nutzen. Bei dem Gerät steht eher der geschäftliche Einsatz im Vordergrund.

This post combines two ideas

1. The calculation of a moving average (last 30 days) as shown in a previous post
2. Custom aggregations

What I want to show here today, is how we can influence the way our calculation works on higher levels. For this purpose I’m showing three different approaches:

1. The monthly (quarterly, yearly) total is defined as the last day’s moving average of the given date range.
   This corresponds to the original approach from my post about moving averages
2. The monthly (quarterly, yearly) total is defined as the average of all the moving averages on day level.
3. The monthly (quarterly, yearly) total is defined as the average of the sales amount of all days of that period (the moving average is only to be calculated on date level)

Of course, there are many more possibilities but I think the methods shown here, can be used for many other aggregation requirements.

Here are the three aggregations side by side.

Although the values on higher levels of aggregation differ a lot, the daily values are identical (we just wanted to change the rollup method, not the calculation on a detail level).

Let’s start with the first one:

1. The monthly (quarterly, yearly) total is defined as the last day’s moving average of the given date range

This is shown here for our measure “Sales Amount(30 avg)”:

As shown in my previous post, the formula may look like this:

Sales Amount (30d avg):=
AverageX(
  Summarize(
    datesinperiod(
       ‘Date’[Date]
       , LastDate(‘Date’[Date])
       , -30
       , DAY
    )
    ,’Date’[Date]
    , "SalesAmountSum"
    , calculate(Sum(‘Internet Sales’[Sales Amount]), ALLEXCEPT(‘Date’,'Date’[Date]))
  )
  ,[SalesAmountSum]
)

Since we use the expression LastDate(‘Date’[Date]) the last date of each period is used for the moving average – exactly what we wanted.

Average at month level as the average of the moving averages (day level)

In this approach, the monthly aggregate has to be calculated as the average of all the daily moving averages of that month. The picture shows what this means:

This might look pretty difficult. However, for our calculation we simply have to wrap the existing calculation in another Summarize – function.

This is the formula I used:

Sales Amount (30d avg 2):=
AverageX(
  summarize(
    ‘Date’
    , ‘Date’[Date]
    , "DayAvg"
    AverageX(
      Summarize(
        datesinperiod(
          ‘Date’[Date]
          ,LastDate(‘Date’[Date])
          , -30
          , DAY
        )
        ,’Date’[Date]
        , "SalesAmountSum"
        , calculate(Sum(‘Internet Sales’[Sales Amount]), ALLEXCEPT(‘Date’,'Date’[Date]))
      )
      ,[SalesAmountSum]
    )
  )
  ,[DayAvg]
)

The blue part of the formula is exactly the same is in the first calculation. We’re just wrapping this in an additional Average function. Why does this still work on a day-level? Simply because the outer average computes the average of a single value in this case.

So, with just a minor change to the formula, we changed the method of aggregation quite a lot.

3. The monthly (quarterly, yearly) total is defined as the average of the sales amount of all days of that period

This sounds quite simple but in this case we have to distinguish two calculation paths:

• day level
• month level and above

The following picture shows the calculation for the monthly aggregate:

In order to split our computation paths we need to find out if we are on day level or not. Usually the IsFiltered(…) DAX function can be used for this purpose. However, since we have some columns with date granularity (date, day of month, day of year) in our date dimension, we would have to write something like IsFiltererd(‘Date’[Date]) || IsFiltered(‘Date’[Day of Month]) || …

To simplify this, I simple used a count of days in the following code. If we count only one day, we’re on day level. Of course, the count is the more expensive operation, but for this example, I leave it that way (the date table is not really big).

Sales Amount (30d avg 3):=
if (
  Count(‘Date’[Date])=1,
  AverageX(
    Summarize(
      datesinperiod(
        ‘Date’[Date]
        ,LastDate(‘Date’[Date])
        , –30
        , DAY
      )
      , ‘Date’[Date]
      , "SalesAmountSum"
      , calculate(Sum(‘Internet Sales’[Sales Amount]), ALLEXCEPT(‘Date’,'Date’[Date]))
    )
    ,[SalesAmountSum]
  )
  , 
  AverageX(
    Summarize(
      ‘Date’
      ,’Date’[Date]
      ,"SalesAmountAvg"
      , calculate(Sum(‘Internet Sales’[Sales Amount]), ALLEXCEPT(‘Date’,'Date’[Date]))
    )
    ,[SalesAmountAvg]
  )
)

Again the blue part of the formula is exactly the same as in our first approach. This part is taken whenever we’re on a day level. On higher levels, the aggregate is computed as a simple (not moving) average of all daily values.

So, using the concepts of my previous post we were able to change the aggregation method to meet very sophisticated requirements.

Custom aggregates can be created using cube scripts in BISM multidimensional (SSAS OLAP cubes). How can we do this with BISM tabular? In many cases, simple DAX calculations can solve this for us.

I’m referring to the example of my previous post about semi additive measures. Let’s say we’re monitoring the stock of two products we’re selling. For the totals we want to see the average stock over time. At least once a month we’re taking a snapshot of the stock. If we have more than one snapshot per month, the monthly total computes as the average of those snapshot. For aggregation above the month level we want to take the average of the monthly averages. At first, this looks like we only have to use average as the aggregation function. But the average of averaged values is not identical to the average of all values. Let’s take a look at this source data table:

For product Notate we have a single measurement of 50 pieces in February. For product Quickerstill we have 8 distinct measurements with an average of 50 pieces in February. However, when we look at the total average for Quickerstill, the 8 distinct measurements in February result in a higher weight of the February average and therefore in a higher total average of 44 instead of 30:

The Average Stock measure in this example is the same semi additive measure as in my previous post and computed like this:

AVG Stock:=Sum([Stocklevel])/DISTINCTCOUNT([Date])

The requirement for the custom aggregate means, that we also want to see a total average of 30 for product Quickerstill (20+50+20=90, 90/3=30). This requirement is somewhat unusual as the computation above gives the “correct” average of all values. One interpretation is that the weight for computing the average of two or more months is not influenced by the number of measurements within the month.

We can achieve this in a way that is very similar to the semi additive calculations from my last post. Here is the resulting formula:

Special AVG Stock:=AVERAGEX(SUMMARIZE(‘Stock’,[Year],[Month],"AvgStock",AVERAGE([Stocklevel])),[AvgStock])

This formula simply summarizes the average stock at a grouping level of year and month. Then, in a second step, it takes these values and computes the average of them. By doing so, we have broken the aggregation into two layers. First we average by month, then we take the average of those values.

Here is the resulting table using the new aggregate:

And after expanding the February values (2nd month) we clearly see the how our custom aggregate works:

Of course, this is just a simple custom aggregate but it is remarkable that we didn’t need any kind of cube script with scope-statements to achieve this but only a very simple DAX expression.