PerformancePoint Services
Throughout this book, we have explored how the SharePoint platform can be used to provide a user interface for business intelligence (BI) and data analysis. Up to now, we have examined individual technologies such as Excel Services, Visio Services, and SQL Server Reporting Services as isolated solutions for specific needs. In this chapter, you will discover how PerformancePoint Services allows you to build integrated business intelligence solutions that bring these capabilities together into powerful interactive dashboards.
What Will You Learn?
By the end of the chapter, you’ll learn about
Software Prerequisites
To get the most out of this chapter, you’ll need the following software:
Introduction to PerformancePoint Services
In the early years of this century, the “scorecard” became a popular business metaphor for bringing together related pieces of information from throughout the enterprise to provide decision makers with a high-level view of the business. Special-purpose scorecards like the “Balanced Scorecard” became popular, but there were no good tools available to deliver them. After a few attempts at getting Excel and web-based templates deployed, Microsoft published the Office Business Scorecard Manager 2005.
In 2006, Microsoft purchased ProClarity Corporation, thereby acquiring one of the premier business intelligence software companies. Microsoft immediately began integrating features of ProClarity’s rich server-based and client-based data analysis tools into its products.
When MS PerformancePoint Server was released in 2007, it contained two major modules: monitoring and analysis (M&A) and planning. The M&A component combined the features of the Business Scorecard Manager product with new capabilities brought in from ProClarity and saw good adoption. Use of the planning module, however, was sparse and in 2009, Microsoft dropped it due to lack of market interest. What remained of PerformancePoint was then rolled into the enterprise license of Microsoft Office SharePoint Server (MOSS) 2007. In fact, at that point, the MS PerformancePoint Server 2007 product could be loaded onto a MOSS server farm (with Enterprise Client Access Licenses, or CALs) without additional licensing.
In SharePoint 2010, PerformancePoint became a fully integrated service within the SharePoint environment. This has been carried forward to SharePoint 2013 as well. You get all of SharePoint’s administration and content-management tools along with the analytic abilities of PerformancePoint.
PerformancePoint Services Architecture
PerformancePoint Services is implemented using service application framework of SharePoint Server. In the same way that Excel Services and Visio Services run as separate service processes, so does PerformancePoint.
Service Components and Interfaces
Figure 6-1 shows the primary components that cooperate to provide the business intelligence experience PerformancePoint Services makes possible.
Figure 6-1. PerformancePoint services and related components
The PerformancePoint end-user experience is designed to be very simple. A PerformancePoint dashboard is deployed as nothing more than a folder containing one or more web pages within a SharePoint library. These pages contain all of the user interface elements necessary to perform complex business analysis on the underlying business data. This user interface is designed to require very little specialized training. With some experience, most users find the scorecards, charts, and reports very easy to interpret and manipulate. All of this content is delivered via a web browser, of course, but there are also many opportunities to take data offline into office applications such as Excel for deeper ad hoc analysis.
To deliver this sophisticated user interface, the key performance indicators (KPIs), scorecards, dashboards, and other BI components must first be defined and deployed to SharePoint. The tool for accomplishing this is the Dashboard Designer, a Windows application for defining BI components and deploying them to SharePoint. This tool does not need to be separately downloaded and installed. It is automatically installed as a “one-click” application when needed. See “Authoring and Publishing PerformancePoint Solutions” later in this chapter for a tour of this tool. Note that this is a development tool and is not designed for use by most end users. With a little bit of training, end users can build fully functional dashboards.
At the application layer, PerformancePoint conforms to the typical design of a SharePoint service. It is made up of a service process and a proxy component. The proxy component provides code running within the IIS application pool process with access to the functionality of the PerformancePoint service application. The service runs as an independent process in the operating system and is often deployed on a separate tier of application servers that sits between the web front-end server and the database servers, as shown in Figure 6-1.
Other application-level services commonly employed as part of a PerformancePoint solution include the Secure Store Service (SSS) and SQL Server Reporting Services (SSRS). SSS provides a location for logon credentials to be securely stored within the SharePoint environment. For more details on the purpose and configuration of the Secure Store Service, see Chapter 5. Although it is not part of SharePoint Server, the SSRS component of SQL Server is frequently leveraged in conjunction with PerformancePoint solutions due to the ease with which it allows complex reports to be created and delivered.
On the database layer of the architecture, there are several data sources you’ll have to become familiar with.
SharePoint Content Lists and Libraries
As you are probably aware, SharePoint stores its web site contents in content databases. These databases contain the site collections, sites, lists, libraries, and pages that make up the sites served by SharePoint. In the context of PerformancePoint, most of the business intelligence objects, including the dashboards themselves, are also stored in lists and libraries within SharePoint’s content databases.
PerformancePoint Service Databases
Like the other service applications in SharePoint Server 2013, PerformancePoint Services needs to store data that does not fit well into the usual format of lists and libraries in SharePoint. This data is stored in a separate database that’s created when a new instance of the PerformancePoint service application is created. The tables in this database, like all SharePoint databases, should never be manipulated directly but only through PerformancePoint Services. These tables contain various parameters used by PerformancePoint Services (PPS), as well as dashboard annotations and comments entered by users.
SQL Server Analysis Services (SSAS) Cubes
Because of the types of analysis normally performed with PerformancePoint Services, perhaps the most common data source for key performance indicators (KPIs), scorecards, and dashboards is SQL Server Analysis Services (SSAS). The cubes stored in SSAS contain the raw business information that PPS will “slice and dice” to perform the analysis required by the user. For a full description of using SSAS cubes to store and manipulate multidimensional data, see Chapter 1.
While SQL Analysis Services is the most common source of information for PPS dashboards, it is far from the only option. Any data store from which you can read data is a potential data source for PerformancePoint. Additional data sources supported out of the box include SQL Server relational tables, Excel spreadsheets (either file-based or via Excel Services), and SharePoint lists.
With a little more effort, you can expand the available data sources to include any Open Database Connectivity (ODBC) - compliant relational database and even data accessed via custom code written and deployed by the user’s organization. For details on creating custom data source providers for PerformancePoint Services, see msdn.microsoft.com/en-us/library/bb836514.aspx. To access other non-Microsoft databases, you can use either Business Connectivity Services (discussed in Chapter 4) to expose the data as a SharePoint list or a SQL linked server to expose the data as a SQL Server table (msdn.microsoft.com/en-us/library/ms188279.aspx).
Securing PerformancePoint Solutions
Much of the security for a PerformancePoint solution is handled by the SharePoint Foundation component. The dashboards exposed by PerformancePoint Services are stored as ASPX pages in a folder within a SharePoint document library. The permissions associated with the libraries, folders, and dashboard pages will control who is allowed to access which pages.
However, the page itself is not usually what is most important. It is the data that we want to protect. Security can become problematic when we have to access data sources outside of SharePoint. PerformancePoint Services provides three authentication methods for accessing back-end data sources: per-user identity, an unattended service account (USA), and a custom connection string for SQL Server Analysis Services.
Per-user identity allows a PPS dashboard to impersonate the user’s credentials when accessing back-end data. This is a very secure way to access data because it provides a second check before allowing the user to access not just the dashboard, but the data underlying the dashboard. However, this form of authentication requires Kerberos delegation to be in place between the PerformancePoint server and the data source, so it’s not always possible to use this type of authentication. See “Planning Considerations for Services that Access External Data Sources” at technet.microsoft.com/en-us/library/cc560988.aspx#ConsiderationsForAccessingExternalData.
The most commonly used form of authentication with PerformancePoint Services is the unattended service account. This is an account that is configured in the Secure Store Service and used to access a back-end data source. The data source will see only the service account’s credentials, so it will not be able to filter the data it returns based on the identity of the user accessing the dashboard. The service account must be given access to all necessary data within all data sources in order for PerformancePoint to function properly. It is a best practice to use a service account with the least permissions that will allow it to access the needed data.
The last option, called “Custom Data,” uses the unattended account but also includes the user’s login name on the connection string. This option works only with SQL Server Analysis Services 2006 or later. In SSAS, this is known as “Dynamic Security.” The idea is to allow the SSAS server to filter the query results when full Kerberos delegation is not possible. The user’s login can be used in MDX queries and SSAS role assignments to limit the data returned by the cube.
The most important thing to note when choosing among these authentication options is that the choice can now be made for each data source that is configured. In PerformancePoint Server 2007, it was necessary to configure a single authentication mode for the entire server application. It was not possible to configure one data source using per-user identity and another to use an unattended service account. In SharePoint 2013 and 2010, if multiple types of authentication are required, you don’t need to configure multiple PerformancePoint service application instances. Creating separate data sources is sufficient. However, the unattended account is configured for a PPS application instance so that all data sources running against the USA in that instance will use the same account. See “Setting Up PerformancePoint Services” and “Creating a Data Source” later in this chapter for details.
Business Intelligence Solution Components
A PerformancePoint solution is built by creating a set of business intelligence components that work together to control how business data is aggregated and displayed. This section will introduce the concepts behind these components and how they are deployed to a PerformancePoint service environment. For a step-by-step guide to creating a real-world PPS solution, see “Authoring and Publishing PerformancePoint Solutions” later in this chapter.
BI Component Types
The components that go into a PerformancePoint solution are described at a conceptual level in this section. Later, we’ll describe how these components are represented and stored in SharePoint.
A dashboard is a set of web pages displayed by SharePoint to allow the user to view and analyze data. Figure 6-2 shows a sample dashboard.
Figure 6-2. A typical PerformancePoint dashboard
A dashboard page consists of several parts. Typically, a page contains a navigation area at the top of the page, as shown in Figure 6-3. In this case, the pages of the dashboard, “Sales Summary” and “by Sales Territory,” are presented as links in the header of the page. Clicking on an active link takes the user to a new page in the dashboard while preserving the filters used on the current page. This allows multiple pages to act as a single dashboard.
Figure 6-3. Dashboard navigation links
Note The latest AdventureWorks sample database from Codeplex has sales data from year 2005 to 2008. We will use these date ranges in our examples.
The rest of the page is separated into zones, similar to the web part zones used in SharePoint pages. The difference is that dashboard zones can be added, modified, and removed from a dashboard page after it is created. These zones allow dashboard components—including filters, scorecards, and reports—to be stacked and connected in the same way web parts can be manipulated on a web part page. Figure 6-4 highlights the zones and direction (vertical vs. horizontal) of the default dashboard page layout.
Figure 6-4. Default dashboard zones
The BI components that make up the page are assembled, arranged, and connected using the Dashboard Designer. When the dashboard is deployed to SharePoint, the various object definitions control the page’s behavior. A common pattern, as shown in Figure 6-4, is to place visible filters in the header zone of the page and then to fill the other zones with scorecards and reports as needed.
The connections created between components allow them to act together. For example, when the user changes the Date filter on the sample dashboard, each of the scorecards and reports on the page are updated to reflect data only from those periods. When a row is selected in the scorecard shown on the left, the data on the reports in the right column are filtered to match. We will be creating this dashboard and its connections later in this chapter.
Indicators and Key Performance Indicators
A Key Performance Indicator is a definition of business-relevant measurements (or “metrics”) used to display easy-to-understand conditions as shown in Figure 6-5.
Figure 6-5. A key performance indicator
KPIs are defined in PerformancePoint as a set of metrics that are either “actual” or “target” metrics. Actual metrics are the values that are calculated from the underlying business data. In the example in Figure 6-5, “Reseller Sales” is an actual metric. Target metrics, in contrast, define a desired goal for the actual metric, based on some condition or formula specified as part of the KPI’s definition. The “GPM” column is a target metric in this example. Target metrics can be displayed in several ways but include three basic components: the indicator and a value before and/or after the indicator. The meaning of these values can be defined wherever the KPI is displayed. In this case, the highlighted line shows an actual value of “62.6%”, a green circle indicator, and an attainment value of “–37%” based on the scoring pattern defined.
The definition of the KPI specifies where the actual and target values come from as well as what type of indicator to show. PerformancePoint comes with a large set of indicators to choose from, as Figure 6-6 shows. Through Dashboard Designer, you can also create your own custom indicators using custom images.
Figure 6-6. Some common indicator types
The first components to be created in a PerformancePoint solution are data sources. These define the locations and parameters to use when accessing the data that will be used by the dashboard. PerformancePoint supports two major categories of data sources: tabular list and SSAS BISM Models (Tabular and Multidimensional). More details on Tabular and Multidimensional model can be found at http://msdn.microsoft.com/en-us/library/hh212940.aspx.
Tabular List data sources are those that provide PPS with a relational table of data to work with. It is important not to confuse this with the Tabular Model. The most commonly used data sources of this type are SQL Server tables. Other options include cells retrieved from Excel spreadsheets, either through Excel Services or directly from a file, or the items in a SharePoint list. It is also possible to use SharePoint’s Business Connectivity Services (BCS) or SQL linked servers to pass data from other relational database management system (RDBMS) or line-of-business applications into a PerformancePoint dashboard.
Multidimensional data sources are the most common type used in PerformancePoint solutions. They use SQL Server Analysis Services (SSAS) cubes to furnish and process data. Analysis Services is the only currently supported OLAP data source.
Filters are components that let users select parts of the data set to examine while excluding the rest. For example, you can use a filter to examine data only for certain time periods, as Figure 6-7 shows.
Figure 6-7. A multi-selectable member-selection filter
In SharePoint 2013, filters allow users to search for a particular value from the text box. Filters also highlight the items in bold font if there are any items selected in that hierarchy. This feature allows the users to identify the selected items when the tree view is in a collapsed state.
When creating a filter, there are two primary considerations: the type of filter and the display method to be used.
The types of filters available are
Once the type of filter has been selected, it can be displayed in three different ways:
When a filter is placed on a dashboard, it is not just a user-interface control that controls the data displayed on that page. The selections made are written to PerformancePoint’s database for later use. If the user returns to that page days later, that selection will still exist. The number of days the selection is retained can be configured in SharePoint Central Administration. See “Setting Up PerformancePoint Services” later in this chapter. Because the filter is part of the dashboard, not just the page, that same filter selection will also be transferred to any other page that is part of the same dashboard. Therefore, if a selection is made on one page and then the user navigates to another page on the same dashboard, all of the filter selections made on the previous page apply to the new page as well.
A PerformancePoint scorecard, shown in Figure 6-8, is used to display a set of key performance indicator metrics. You can configure the KPIs to display differently depending on what you need the scorecard to reflect. For example, the designer might choose to use a background color for a KPI cell instead of displaying the indicator image.
Figure 6-8. A PerformancePoint scorecard
In addition to the KPI metrics, scorecards generally also include one or more sets of dimension attributes that are used to drill down or roll up the KPIs.
A report in PerformancePoint refers to a component that displays business data other than KPIs. Reports are authored separately and then connected to the filters and scorecards on a dashboard to filter the data returned in the report. Our sample dashboard contains two of the most common reports used in PerformancePoint Services: the analytic grid and the analytic chart (which are shown in Figure 6-9).
Figure 6-9. Analytic chart and graph reports
PerformancePoint generates some reports entirely within itself, but some reports are created in cooperation with other technologies. Here are the report templates supported:
Each of these reports is rendered on the dashboard page using a web part that manages the connection with other parts of the dashboard.
PerformancePoint SharePoint Components
Now that you’re familiar with the basic concepts of a business intelligence solution, let’s take a look at how these pieces are put together in a SharePoint site.
A content type in SharePoint defines all of the metadata about how a particular type of list item or library document will be handled by SharePoint. This includes a list of the fields associated with the object and any custom actions it might support. In the case of PerformancePoint, the following content types are defined to enable its functionality:
With the exception of data sources, all of these content types define items in a SharePoint list. Data sources are stored as documents in a library because they are stored as Office or Universal Data Connection (UDC) files or as PerformancePoint data source files. Bear in mind that these items represent the definition of the object, not an end-user-viewable object. These items can be edited using the Dashboard Designer but don’t display any content on their own. Only when a dashboard is “deployed” is it compiled into a set of ASPX pages that can be viewed by users.
A major advantage of PerformancePoint Services over PerformancePoint Server 2007 is the use of content types. With content types, all of the functionality of SharePoint is now available for use with PerformancePoint artifacts. This includes participating in workflows, using information rights management policies, and including PPS objects in any list or library where the PPS features and content types are active. You are no longer constrained to using a special site definition with a predefined structure for your PPS solutions.
PerformancePoint defines list and library templates designed to store PerformancePoint artifacts:
Dashboard pages are created as ordinary web part pages. The various components of a page are created as connected web parts. The web parts used by PerformancePoint are
Business Intelligence Center Site Template
PerformancePoint defines a sample site template to help designers begin using the service. (See Figure 6-10.) This template is nothing more than an ordinary site with some prepopulated content to introduce the user to PerformancePoint features. The content is contained in a Content Editor Web Part and can be deleted when no longer needed. You can also add the PPS lists, libraries, and content types to any existing site instead of using the template. All that’s required is for the PPS features to be activated.
Figure 6-10. The Business Intelligence Center Home Page
In addition to this home page, the site template contains an instance of each of the lists and libraries described in “List and Library Templates” earlier. This makes the site a good location for one or more complete solutions to be stored. Additional content can be added to the site as needed.
To use enterprise features, your SharePoint site collection must have the SharePoint Server Enterprise Site Collection Features feature activated under the Site Collection Features.
The PerformancePoint functionality is enabled using two additional features. The first is the PerformancePoint Services Site Collection Features feature. This feature can also be found under Site Collection Features. The second feature is activated at the site level and is named PerformancePoint Services Site Features. See “Deploying the Business Intelligence Center” later in this chapter for step-by-step instructions for enabling these features.
Setting Up PerformancePoint Services
Like the other services we have examined in this book, PerformancePoint Services are configured using Central Administration or PowerShell commands (cmdlets). Let’s take a look at the settings for PerformancePoint Services, along with the procedures for setting up a PPS instance.
The default, wizard-based installation of SharePoint Server 2013 includes an instance of the PerformancePoint Services application, so creating a new instance is not normally necessary. If you do need to create one, however, this can be easily accomplished through SharePoint Central Administration:
Figure 6-11. The Manage Service Applications page
Figure 6-12. New PerformancePoint Service Application dialog
It is now time to configure the application. If you are working with the default PPS instance, you should review the default settings, paying particular attention to the unattended service account, which should have the minimum privileges. See “Securing PerformancePoint Solutions” earlier in this chapter to review why the USA is important.
To begin configuring the service application, click on the name of the service “PPS Application” in our case) to be taken to the Manage PerformancePoint Services page as shown in Figure 6-13.
Figure 6-13. Manage PerformancePoint Services page
On the Manage PerformancePoint Services page, there are various settings to configure, which we’ll discuss now. Although most of the settings can be left to their default values, some need to be configured in order to address specific requirements.
The PerformancePoint Service Application Settings page (shown in Figure 6-14) contains a variety of settings that control the performance and behavior of PPS. These settings apply only to sites associated with this instance of PerformancePoint Services.
Figure 6-14. PerformancePoint Service Application Settings page
Secure Store and Unattended Service Account
The purpose of this section is to configure the unattended service account. Recall that this is the Active Directory domain account that will be used when accessing data sources without using the user’s own identity (Kerberos). The credentials for this account are stored in the Secure Store Service. See “Securing PerformancePoint Solutions” earlier in this chapter.
This section of the page has three entry boxes. The first text box is used to identify the SSS application to be used for the account’s credentials. The second and third boxes allow for the entry of the user name and password of the account, respectively. Remember that this account should have minimal permissions but provide access to all necessary data.
Each dashboard user can be given permission to add comments to the cells in a PPS scorecard. These comments are then available to other users when they view that scorecard. The comment functionality also uses the term “annotation.” Technically, a scorecard cell can have one annotation, and each annotation can have multiple comments.
This section of the page contains a check box that can be used to enable the annotation feature within the PPS instance. There is also a setting that limits the number of annotations that can exist on a single scorecard. The default is 1,000 annotations per scorecard.
There is also a “Delete Comments by” Date button shown in Figure 6-15 that displays a dialog box. This dialog can be used to start a background job that will clean up comments older than a given date, which can use useful if it becomes necessary to reclaim space in the SQL database associated with this PPS instance. The name of this database is based on the name of the PPS application and a unique GUID, like “PPS Application_d6430dcfa6de4086a84dcb1b0c39f78e.”
Figure 6-15. The “Delete Comments by Date” dialog
The cache section of the page contains a single entry that sets how long (in seconds) the images associated with KPIs should remain in memory before the memory is reclaimed. The default is 10 seconds, which should allow the image to be reused several times during the rendering of a single page. If your site makes heavy use of only a few unique indicators, it might make sense to extend this value to keep from frequently reloading them from disk.
Analysis Services EffectiveUserName
This setting enables PPS to pass in the current user name in the connection string (;EffectiveUserName=domainUserName) when making a connection to SSAS data source. SSAS filters the data based on the user name passed in the connecting string. For this setting to work, the managed service account used for PPS should have administrative rights in the SSAS server.
This section allows the administrator to set a standard timeout on a data source, preventing pages from becoming unresponsive when a data source becomes slow or unavailable. The default is 300 seconds, which should be sufficient in most cases. If data access is consistently over 5 minutes, either the data source is not responding properly or the queries being used to access the data should be reconsidered. When data access for a dashboard page takes a very long time, two major problems result.
First, system resources are consumed processing and returning large amounts of data that will, most likely, never be used. The thread, table, memory, and I/O locking and contention created by executing very large queries can quickly diminish system performance for all users.
Second, users are not going to wait for several minutes each time they interact with the dashboard. A user viewing a dashboard is trying to avoid information overload, so loading 1,000 or more records defeats this purpose. Long wait times degrade the user experience and lead to having dashboards that aren’t used.
Filters are used on dashboards to set how the data is “sliced.” PerformancePoint dashboards have the ability to remember the last filter values used by each user. This is valuable when moving from one dashboard page to another or when returning to a dashboard on a future visit.
To avoid storing this data forever, this configuration section allows the administrator to set a time out (in days) for how long to retain unused filter values.
The maximum number of members that can be loaded into a filter tree (shown in Figure 6-16) is configured here as well. Each time you use a filter, you are selecting a set of values to apply with the filter. For example, if you select the year 2010 at the Months level of the date hierarchy, you are selecting 12 values that must be stored for the filter. If you are selecting at the Day level, there are 365 values that must be stored. Each of these values is called a “member” of the filter. This setting prevents very large selection lists from slowing down the server for all users.
Figure 6-16. Sample filter tree control
This setting is similar to the Filters section except that it applies to the selection of measures on a dashboard.
The Show Details feature allows an end user to drill into a value that is derived from Analysis Services. The functionality of the drill-through is controlled by Analysis Services, but it is rendered by PerformancePoint Services. (See Figure 6-17.) These settings limit the performance impact that this feature can have on the server hosting the PPS application.
Figure 6-17. Sample Show Details report
The “Initial retrieval limit” limits the number of rows that can be retrieved on the first page of the details report. The default of 1,000 is generally sufficient without creating too great a load on the server. The “Maximum retrieval limit” is used to prevent excessively large datasets from being returned on subsequent pages of the report. You can either choose a fixed number of rows or leave control of this setting with Analysis Services. To reduce page load times and unnecessary server traffic, consider reducing this value to one in line with the expected use of the report.
The Decomposition Tree feature is a very powerful analytical tool, with an interface designed to be simple and intuitive to an untrained user. (See Figure 6-18.) The Decomposition Tree leverages the dimensions already built into the solution to drive the analysis. It allows users to do a complex analysis without involving a developer.
Figure 6-18. Decomposition Tree
However, because of the large number of members that a dimension might contain, it can become a performance drain on the system.
Each item listed in a vertical column of the decomposition tree is counted against this limit. Note that this limit applies to only one column of items as highlighted in Figure 6-18. The total number of items in all columns might well exceed this value. This limit should not be set higher than is needed for the users to perform the analysis required.
PerformancePoint Services stores its metadata in SharePoint lists and libraries. These locations must be listed as “trusted” before PPS will consider them valid locations from which to read its objects. By default, all locations within SharePoint are automatically considered trusted, as Figure 6-19 shows.
Figure 6-19. Trusted data source locations (default setting)
Note that just because the location is trusted by PerformancePoint, it is not necessarily accessible by any particular user. The SharePoint permissions on those items still control access to them. The fact that they are in a trusted location only allows PPS to use them if the user has access to them.
If there’s a need to restrict the locations from which a PPS application can load data sources, switch this setting to “Only specific locations” and click Apply. This will enable a new set of options for adding specific locations, as shown in Figure 6-20.
Figure 6-20. Trusted data source locations (specific locations enabled)
To add a location with this dialog box
Figure 6-21. Creating a specific trusted data source location
Trusted content locations are configured in the same way as trusted data source locations with the following exception. PPS content items created by the Dashboard Designer application—such as KPIs, Scorecard, Reports, and so on—are stored in SharePoint lists instead of in document libraries. Therefore, when selecting trusted locations, the options are Site, Site Collection, or List.
Authoring and Publishing PerformancePoint Solutions
In this section, we will create all of the PerformancePoint content objects necessary to implement a typical business intelligence dashboard using data from the AdventureWorks sample database. Our solution will include the KPIs, scorecards, filters, reports, and dashboards necessary to provide the user with a rich data analysis environment. We will deploy this solution to SharePoint and explore the resulting user experience.
In the following section, “Advanced Report Types,” we will then expand on this solution by adding reports to the dashboard based on Excel Services and Strategy Map report types.
Note This tutorial will make extensive use of the AdventureWorks SSAS solution. You can download the AdventureWorks database from http://msftdbprodsamples.codeplex.com/. Take a look at Chapter 1 for details about deploying the solution as an SSAS database.
PROBLEM CASE
Author and publish a BI solution that allows a marketing manager at AdventureWorks to analyze the effectiveness of his marketing campaigns by product and sales channel.
Solution
The solution for this case will be created in the following sequence:
Before attempting to follow this tutorial, you should already be familiar with basic BI and PPS concepts such as dimensions, measures, KPIs, scorecards, etc. If not, please refer to “Business Intelligence Solution Components” earlier in this chapter for PPS components and Chapter 1 for dimensional-modeling concepts.
Deploying the Business Intelligence Center
We will create a work area for our solution by deploying the PerformancePoint Business Intelligence Center site template. First we must verify that the necessary features are activated at the site-collection level. You will need site-collection administrator rights in order to enable features and create the site:
Figure 6-22. Click on the settings icon from the top right corner
Figure 6-23. Select “Site settings” from the drop-down menu
Figure 6-24. Selecting site-collection features
Figure 6-25. Activating SharePoint Server Enterprise site-collection features
Figure 6-26. Activating PerformancePoint Services site-collection features
Figure 6-27. Selecting the Business Intelligence Center site template
The site created has all of the lists and libraries needed to deploy a complete PerformancePoint solution. It also contains informational content describing the site’s purpose, which you can delete when you no longer need it.
Creating a Dashboard Designer Workspace
All of the objects we create for our solution will be stored in a Dashboard Designer Workspace file, which is stored on your local desktop with a DDWX file extension. This file acts as an offline store for these objects until you are ready to publish them to SharePoint. The workspace file is similar to a Visual Studio solution file in that it allows you to organize, edit, and manage all of the components of your solution in one place.
Because the Dashboard Designer is a one-click Windows application, there is no executable to download and install on the desktop. The easiest way to install it is simply to use it and then save a file. We will do this as part of the next section.
Now let’s create a data source from which to retrieve business data for our dashboard:
Figure 6-28. Adding a PerformancePoint data source
This will launch the Dashboard Designer. If this is the first time you’ve used it, you’ll see messages and progress bars indicating that it’s installing. The Web browser might ask you to authorize the installation. Finally, the designer will be shown with an empty workspace and the “Select a Data Source Template” dialog displayed, as shown in Figure 6-29.
Figure 6-29. Selecting a data source template
Figure 6-30. The New Data Source screen
Take a moment to find your way around the Dashboard Designer application—you’ll spend a lot of time here! At the top is a ribbon menu system that works like any Office 2013/Office 2010 application. The options that appear in the ribbon will change as the context of the central window changes.
On the left side of the window is the Workspace Browser , which is a tree listing the contents of the workspace. Currently, this list shows one workspace file called Untitled Workspace, one SharePoint list called Data Connections, and one item within that list—a data source currently named New Data Source.
The editor for the item selected in the list on the left is displayed in the center window where changes can be made. This window will have a set of tabs across the top based on the type of object being edited. The Properties tab is common to all objects and is used to name and organize objects within the workspace.
To the right of the center window are panels that list the objects within the workspace that are related to the current item:
Figure 6-31. Selecting a time dimension
Note Depending on when you downloaded the AdventureWorks sample databases, the actual dates available in your cube might be different from those shown. The sample database used here has data from FY 2006 to FY 2009.
Figure 6-32. The time dimension hierarchy
At first glance, it might seem strange to enter all of this information about the time dimension in the editor you’re using to create a data source. The reason for doing this is that it allows the use of Time Intelligence filters. These very powerful tools will help when it comes time to present data to the user. See “Creating Filters” later in this chapter for details. Now that the data source is set up, let’s go back and finish setting up the workspace itself:
Figure 6-33. Saving the workplace
If you go back to the Data Connections library in your BI Center site, you’ll see that there’s one data source there. Why is it called New Data Source? The answer is that you haven’t yet published the data source you created to SharePoint. You’ve only saved it to the workspace file.
Tip You can tell that an item hasn’t been published because there is a pencil superimposed on its icon in the Workspace Browser.
Figure 6-34. Saving the PerformancePoint data source to the Data Connections Library
Now that we have set up our data source and started our workspace file, let’s get ready to retrieve data for analysis.
Creating Key Performance Indicators
Our dashboard will contain one set of KPIs. We will create a set of actual and target metrics that will allow the marketing department to track the effectiveness of their promotions in terms of their effect on Gross Profit Margin.
Our workspace is currently connected to the Data Connections Library, but that area can be used only to store data sources. To create the KPI, you need to connect your workspace to the PerformancePoint Content list in the BI Center site:
Figure 6-35. Selecting the PerformancePoint content
Figure 6-36. Creating a new KPI
Figure 6-37. Choosing a blank KPI template
Figure 6-38. Setting the Display Folder
Figure 6-39. The Profit Margin KPI in the Workspace Browser
Note The use of display folders within the Dashboard Designer is entirely optional. Their purpose is only to help keep the solution organized. They have no effect on anything other than how items are displayed in the Workspace Browser. Workspace folders do not get reflected in the folder structure of the content list in PerformancePoint or anywhere else outside of Dashboard Designer. Typically, they are used to separate items by type (KPIs, Filters, Dashboards, etc.) or functionally by the part of the solution with which they are associated. Folders can be nested as needed by separating folder names with a backslash () character. For the rest of this chapter, items will be placed into such folders but the directions won’t mention it each time from here on out.
Figure 6-40. Editing the KPI
Figure 6-41. Changing the data source
Figure 6-42. Selecting a measure
Figure 6-43. Mapping to the Gross Profit measure
Figure 6-44. Creating a breakeven metric for Gross Profit
Figure 6-45. Selecting the scoring pattern
Figure 6-46. Choosing the indicator
Figure 6-47. Threshold values
Figure 6-48. Setting the number format
Figure 6-49. Creating a filter
Figure 6-50. Selecting the filter criteria
Figure 6-51. Setting the thresholds
The thresholds used in the last target created might not seem to make sense at first. The default banding pattern used by PerformancePoint is “Band by normalized value of Actual/Target.” In this mode, a calculation is performed on each actual and target value for the KPI. A percentage is assigned based on the distance the actual and target are from the “worst value” set in step 3 of the scoring pattern wizard. By default, the “worst value” is set to 0. The worst value is somewhat arbitrary because it is quite possible for actual values to be below it. The percentages calculated in that case are simply negative.
In our case, 0% indicates that the gross profit margin for the selected promotion is exactly the same as for the No Discount promotion. If it’s lower, the percentage value is negative. If it’s better, the value is positive. AdventureWorks management has decided that our profitability goal for these promotions is to be within 20 percent of the non-discounted value (green indicator). A value worse than 100 percent below the standard indicates a serious problem, so the indicator turns red. Anywhere between –20 percent and –100 percent, the indicator will show a slight problem or a yellow indicator.
Creating a Scorecard
On our dashboard, we want to display a list of the promotions we’ve run and the values of our KPIs for each promotion. This is called a scorecard (shown in Figure 6-52), which we will create as a separate component in our workspace (inserted using the text markup feature):
Figure 6-52. An empty scorecard
The empty scorecard shown in Figure 6-52 has two main areas. The center window is where you design the scorecard; you will be able to arrange and format items in this window. To the right are panels that provide the elements to go on the scorecard. First, we identify the KPIs to be shown, and then we identify the rows and grouping to use in calculating the KPIs:
Figure 6-53. The Profit Margin KPI
Figure 6-54. Adding the KPI to the scorecard
Figure 6-55. Choosing Adventure Works as the data source
Figure 6-56. The Promotions hierarchy
Figure 6-57. Selecting members
Figure 6-58. Confirming member selection
Figure 6-59. The scorecard with added elements
Figure 6-60. Target settings for Breakeven
At this point, the scorecard will automatically be processed. It should look something like the one in Figure 6-61. The rows show the promotion hierarchy, including rolling up to parent levels. The columns show our KPIs as they are currently configured. Notice that rows are appearing for promotions even though there were no sales for those promotions.
Figure 6-61. The processed scorecard
Figure 6-62. Empty rows are red, indicating they will be filtered at runtime
Creating Filters
Our dashboard will contain two filters. The first filter will control the date range for the figures displayed. The second will allow us to select from among our sales territories.
Figure 6-63. Creating a date filter
Figure 6-64. Selecting a data source for the filter
For the “Enter time formula” step, we will define the options the user will have for selecting time periods. The formulas are entered on the left, and the name displayed to the user is on the right. The formulas are designed to output a list of members of the cube’s time dimension as specified in the data source. For a good overview of these formulas, go to blogs.msdn.com/b/performancepoint/archive/2010/01/21/time-intelligence-formula-quick-reference.aspx.
Figure 6-65. Adding date formulas
Figure 6-66. Selecting a display method for the date filter
Now we’ll create a filter for selecting from the Sales Territory dimension. This filter will display a tree for the territory hierarchy and allow us to select one territory or higher-level region.
Figure 6-67. Selecting the data source for the filter
Figure 6-68. Selecting members for the filter
Figure 6-69. Choosing the dimension
Figure 6-70. Selecting Sales Territory members
Figure 6-71. Confirming the members
Figure 6-72. Choosing a display method for the Sales Territory filter
Creating Reports
KPIs and scorecards allow you to compare business data against goals. Once you have identified the problem areas in the enterprise, you need to be able to understand the conditions that are causing problems. A “report” in PerformancePoint is a generic term referring to a window of information that has been sorted out based on the filters and scorecard selections made in the dashboard.
The two most common types of reports in PerformancePoint are Analytic Charts and Analytic Grids. We will create one of each for our dashboard.
Figure 6-73. Choosing a report template
Figure 6-74. Choosing Adventure Works as the data source
Figure 6-75. The empty “Margin by Sales Channel” report
The empty grid report window is divided into several areas. The draft view of the report appears in the center window. Beneath the center window are panels labeled Rows, Columns, and Background that will be used to specify the contents of the report. In the report designer, “background” refers to the ways in which the data in the report can be filtered.
To the right is a Details tree from which we’ll select items to add to the report by dragging them onto one of the panels at the bottom of the window.
Now that we have defined the rows and columns for the report (as shown in Figure 6-76), it will automatically display a default view. In our dashboard, we want to see the product categories by default. We also want to be able to filter this report by date, territory, and promotion.
Figure 6-76. Defining the report’s rows and columns
Figure 6-77. Selecting members for the report’s default view
Figure 6-78. Adding dimensions to the report’s default view
Now let’s create an Analytic Chart report. This report will compare the gross profit margin across product categories.
At this point, the chart report looks almost exactly like the grid report. The difference is that the panels across the bottom are Series, Bottom Axis, and Background. (See Figure 6-79.)
Figure 6-79. The empty analytic chart report
Figure 6-80. Adding dimensions to the Background panel
The Information Bar is a useful feature on reports. When this is turned on, it shows the user exactly how the data in the report is being filtered. In the designer, the bar shows “No background selections exist” because there are no filters applied until the report is embedded in a dashboard. (See Figure 6-81.)
Figure 6-81. The Information Bar turned on
Creating a Dashboard
We have created all of the components for our dashboard. Now we’ll put it all together and make it work as an integrated package.
Figure 6-82. The default page template
This will create an empty dashboard page with three zones. (See Figure 6-83.) At the top of the center window is a list of the pages in the dashboard. Beneath the pages is the Dashboard Content panel. This is where the selected dashboard page will be assembled from the components we’ve created. At the right, the Details panel contains the components that can be used.
Figure 6-83. The empty dashboard page
The components are now on the page (as shown in Figure 6-84), but they are not integrated with one another.
Figure 6-84. The dashboard page with components
By dragging fields from one component to another, data is passed to synchronize or filter data throughout, or between, dashboard pages. The behavior we want is as follows:
Now we will create the connections to create this behavior:
Figure 6-85. Creating connections between dashboard items
Figure 6-86. Connecting to the Sales Territory filter
Figure 6-87. Connecting to the Promotion field
Figure 6-88. The completed dashboard
Deploying the Solution to SharePoint, and Exploring
We are now ready to deploy our dashboard and start analyzing data. Remember that the dashboard we created in the previous section is only the definition for a dashboard. That definition is stored in our PerformancePoint Content list. When we deploy the dashboard, the definition is converted into a folder of ASPX pages that implement our dashboard.
Note that PerformancePoint uses Silverlight controls to render some of the UI controls. Now would be a good time to download and install the latest version of Silverlight from www.microsoft.com/silverlight.
Figure 6-89. Deploying to SharePoint
Figure 6-90. Putting the dashboard in the Dashboards library
Figure 6-91. The Sales Summary page
Figure 6-92. Text in the information window
Figure 6-93. Values from the previous session are remembered
Figure 6-94. Click a row on the scorecard to modify the reports
Figure 6-95. Exporting data to Excel
Figure 6-96. Decomposing a cell into multiple levels
Advanced Report Types
Now let’s extend our sample dashboard to include data from two external sources: Excel and Visio. The data will be integrated using the Excel Services and Strategy Map report types, respectively.
PROBLEM CASE
Extend the marketing dashboard to allow users to analyze data by sales territory and promotion hierarchy.
Solution
We will add two additional pages to our dashboard, one using Excel Services reports and another using a Strategy Map report.
Create an Excel Services Report
Microsoft Excel is one of the most widely used packages for doing numerical analysis. As a file-based desktop application, however, it is limited in its ability to reach a large audience and integrate with other solutions. As you saw in Chapter 5, SharePoint Server 2013 incorporates Excel Services to address these issues by creating a server environment for storing, processing, and delivering Excel content. With PerformancePoint Services, you have the opportunity to leverage Excel’s analytical abilities and familiar user interface to integrate rich reports into your PPS solutions.
In this section, we will create a simple Excel Services spreadsheet and deploy it to SharePoint. Then, we will integrate the elements of that spreadsheet into our existing dashboard as a pair of new reports on a new page. The new page will allow us to view a grid and a chart with a breakdown of our sales figures by Sales Territory. Be prepared, there ar quite a few steps.
Figure 6-97. Selecting the database server to connect to
Figure 6-98. Entering a name for the data connection file
Figure 6-99. Choosing how to view data in the workbook
Figure 6-100. The Pivot Table Field List
Table 6-1. Pivot Table Fields
Field | Panel |
---|---|
Date Fiscal Date.Fiscal | FILTERS |
Promotion Promotions | FILTERS |
Sales Territory Sales Territory | ROWS |
Sales Summary Sales Amount | VALUES |
The spreadsheet should now look like the image in Figure 6-101.
Figure 6-101. The pivot chart
Figure 6-102. Selecting the Chart type
Figure 6-103. Entering the chart name
Figure 6-104. Entering the name of the pivot table
Figure 6-105. Selecting a style for the data bars
Figure 6-106. Setting up conditional formatting for the Date filter
The Excel spreadsheet is now ready to be published to SharePoint. For simplicity, we will store it in the Dashboards library in our BI Center site (though it could be stored in any location trusted by Excel Services). First, we’ll create a copy of the data connection we’re using.
Figure 6-107. Copying the data connection
Figure 6-108. Naming the data connection file
Figure 6-109. Selecting the content type of the data connection file
Before we publish the spreadsheet to SharePoint, we need to identify the objects and parameters to expose to Excel Services. The objects we’ll use are the SalesChart and SalesTable objects. We will declare the Date and Promotions cells as parameters, which PerformancePoint will use to pass in dashboard filter selections.
Figure 6-110. Saving to SharePoint
Figure 6-111. Selecting the “Browser View Options”
Figure 6-112. Choosing the items that will be displayed in the browser
Figure 6-113. Adding parameters
Now that we have a spreadsheet published to SharePoint, we will add the PivotTable and PivotChart as reports in a new page on our dashboard.
Figure 6-114. Adding a new Sales Table report
Figure 6-115. Selecting the All Promotions member
Figure 6-116. Creating a filter
We now have the new filter and reports created for our new page. Next we’ll create the new dashboard page and deploy the dashboard.
Table 6-2. Connections for the Dashboard
The dashboard page should now resemble the image in Figure 6-117.
Figure 6-117. The dashboard page
Notice that all of the formatting from Excel is displayed on the dashboard, including the pie chart and data bars. (See Figure 6-118.) Now any changes made to the Excel spreadsheet will automatically be reflected in the dashboard. This allows users who are more comfortable with Excel to author reports that can be integrated with the rest of a PerformancePoint solution.
Figure 6-118. Excel reports displayed in the browser
Microsoft Visio is a powerful desktop visualization tool. As you saw in Chapter 2, the Visio Services component in SharePoint Server 2013 allows Visio diagrams to be brought to life with real data. With PerformancePoint Services, you can take that integration one step further. A Visio diagram can be created that visually represents the KPIs on a scorecard. Those KPIs can then be connected to the Visio diagram to create a graphical representation of the status of the enterprise. In PerformancePoint, this type of report is called a “strategy map.”
In this section, we will create a simple Visio diagram that we’ll deploy to PerformancePoint as a Strategy Map report. The term “strategy map” refers to a particular type of diagram often used in conjunction with the “balanced scorecard” methodology. While this feature in PerformancePoint is ideally suited for implementing that type of map, any Visio diagram can be used as long as it contains only simple shapes that don’t involve sets or groupings within Visio.
Note Readers who are not familiar with Visio or Visio Services should review Chapter 2 before proceeding with the rest of this section.
Figure 6-119. A simple Visio diagram
Figure 6-120. Creating a strategy map report using the Promotion Scorecard
Figure 6-121. The Strategy Map Editor
Figure 6-122. Connecting the Reseller Promotions shape to the scorecard
Figure 6-123. Values for the data graphic
Figure 6-124. The shapes with the data graphic applied
Table 6-3. Components for the New Page
Component | Zone |
---|---|
Date Filter | Header |
Sales Territory Filter | Header |
Promotion Scorecard | Left Column |
Promotion Map Report | Right Column |
Table 6-4. Connections for the New Page
Figure 6-125. The Marketing Dashboard
Try selecting different values for the Date and Sales Territory filters. (See Figure 6-126.) Both the scorecard and the map are updated simultaneously.
Figure 6-126. Trying out the strategy map
There are several features of the map to note:
There is an important limitation when using strategy maps that can be handled with a little additional planning. In our example, if we select a different date range and sales territory, we might see rows on the scorecard that don’t appear on the map, or we might see rows on the scorecard disappear due to a lack of data. These shapes still appear on the map, but they don’t show a color. When we connect shapes to the scorecard, that connection is static. We can’t change that association as needed to fit how the scorecard is filtered. We also can’t add shapes as new rows appear in the scorecard.
There are different strategies for handling such situations. One way is to include every possible shape on the map. You could also limit the filtering of the page to prevent unwanted rows from appearing in the scorecard. Regardless, the shapes on the map and how they are associated are fixed at runtime.
Strategy maps are a versatile way to add visualization to your solution. They can be used to provide a user-friendly means of interpreting your key performance indicators.
Summary
In this chapter, you explored PerformancePoint Services as outlined in Figure 6-127, including
Figure 6-127. PerformancePoint Services Road Map