What's New: PerformancePoint Services in SharePoint Server 2010
Learn about changes in the PerformancePoint Services object model, architecture, and development scenarios.
PerformancePoint Services in Microsoft SharePoint Server 2010 is a SharePoint Server 2010 service application. PerformancePoint Services enables users to create interactive dashboards that display key performance indicators (KPIs) and data visualizations in the form of scorecards, reports, and filters. The PerformancePoint Services API enables developers to extend the built-in functionality of PerformancePoint Services. For more information about supported extensibility scenarios, see Development Scenarios with PerformancePoint Services.
Applies to: SharePoint Server 2010
Programmability Changes in PerformancePoint Services in SharePoint Server 2010
The integration into SharePoint Server 2010 drives many of the programmability changes for PerformancePoint Services. The following lists describe these changes:
What’s New and Changed in PerformancePoint Services in Microsoft SharePoint Server 2010 Service Pack 1
Filters can be connected to filters to create cascading filters. The following API items are added to support this functionality:
Custom data source providers can use the SecureCredentialProvider object to impersonate the credentials for the Unattended Service Account in a data source connection.
The name of the pageFilterOverrides parameter is changed to pageFilters in the BIMonitoringServiceApplicationProxy.GenerateView method and in the IBIMonitoringServiceApplicationProxy.GenerateView method.
What’s New and Changed in PerformancePoint Services in Microsoft SharePoint Server 2010
First class objects (FCOs) are stored as content types in the PerformancePoint Services repository, which is made up of SharePoint document libraries and lists. Data sources are stored in document libraries and all other FCOs (dashboards, scorecards, reports, filters, KPIs, and indicators) are stored in lists. The FCO definition is stored as serialized XML in the content type. Although you can use SharePoint APIs to access FCO definitions, you should use only PerformancePoint Services APIs to modify them. For more information, see the "Interacting with Repository Objects" section in Editors for Custom PerformancePoint Services Objects.
Note
Dashboard FCOs that are stored in the repository represent dashboard page definitions. Published dashboards are stored in a separate Dashboards document library.
FCO definitions are not extensible: you cannot add properties or methods to an object. To create a custom object that can be managed from PerformancePoint Dashboard Designer, you create a native PerformancePoint Services object and then define custom values for its properties. Only objects of type ReportView, Filter, and DataSource can be customized, and only custom tabular data sources are supported. Information that is required by a custom object is typically stored as a string or serialized object in the CustomData property.
The unique identifier of an FCO is represented by a location in the repository instead of a GUID.
ReportView, Filter, and DataSource objects inherit new properties for extensibility support:
The RendererClassName property references the class that defines a custom report renderer or a custom filter control. (This property does not apply to custom data sources.)
The SubTypeId property defines the unique identifier for the object. PerformancePoint Services uses this property to determine whether an object is custom.
Filter objects are FCOs. They are added to dashboards by reference, and they can be reused in multiple dashboards. In the earlier version, filters are child objects that are defined within dashboard objects.
Dashboard Designer cannot be extended. However, new functionality enables Dashboard Designer to display and interact with custom objects and to open custom editors. For more information, see Editors for Custom PerformancePoint Services Objects. The key benefits of this change are support for thin editors and easier deployment of extensions that are developed by multiple third parties.
PerformancePoint Services provides the BIMonitoringServiceApplicationProxy service application proxy and the SPDataStore object on the front-end web server. Custom applications should call these objects to author and process content instead of calling PerformancePoint web services.
The PerformancePoint Services developer documentation is based on a sample that contains examples of supported extensions. The sample contains a repository-helper layer that simplifies the common tasks that custom editors perform to create, retrieve, and update objects. For more information, see Code Samples for PerformancePoint Services in SharePoint Server 2010.
SharePoint list security is used to authorize users' permissions to access an FCO and its definition. However, list security does not secure access to the underlying data that is shown in dashboard content. For information about how PerformancePoint Services helps secure data, see Plan for PerformancePoint Services Security (SharePoint Server 2010).
PerformancePoint Web Parts (scorecards, reports, and filters) use Microsoft SharePoint Foundation 2010 connection interfaces. This enables PerformancePoint Web Parts to send or receive values from other Web Parts that use compatible connection interfaces.
The Preview website was removed. Instead of using this site, dashboard authors can publish dashboards directly to SharePoint Server 2010 to design and test in private mode before they make the dashboard available to other users.
As a result of these significant architectural changes, migrating custom PerformancePoint Monitoring Server extensions to PerformancePoint Services is not supported.
See Also
Concepts
PerformancePoint Services in SharePoint Server 2010
Troubleshooting and FAQs for PerformancePoint Services Development