Development Scenarios with PerformancePoint Services
Learn about supported PerformancePoint Services development scenarios and the components of custom report, filter, and data source extensions.
For PerformancePoint Services in Microsoft SharePoint Server 2010 development, you can use the API to extend the native functionality of PerformancePoint Services. For example, you can create a custom report visualization that is optimized for the medical industry and then integrate it into a reusable vertical solution.
Applies to: SharePoint Server 2010
Supported extensions run within a PerformancePoint Services application instance, either on the front-end web server or on the application server, as shown in the following diagram.
Figure 1. PerformancePoint Services extensibility architecture
PerformancePoint Services supports the following development scenarios.
Creating PerformancePoint Report, Filter, and Tabular Data Source Extensions
You can create extensions for custom PerformancePoint Services objects, which are native ReportView, Filter, or DataSource objects that have custom values defined for their properties. Custom extensions typically include three components: a renderer or provider, an editor application, and extension metadata.
Renderers and Providers in PerformancePoint Extensions
Your extension type determines whether it uses a renderer or a provider. Report and filter extensions use renderers, and filter and data source extensions use providers.
Report extensions require a renderer for the report visualization.
Filter extensions require a data provider to connect to the underlying data source and a renderer for a selection control. The renderer can be a custom or native PerformancePoint Services renderer.
Data source extensions require a provider to connect to the underlying data source.
Editor Applications in PerformancePoint Extensions
Custom editors enable users to define properties for a custom object. An editor can be opened from PerformancePoint Dashboard Designer or from an item in a repository such as the PerformancePoint Content List or PerformancePoint Data Connections Library. Custom editors (and other supported custom applications) run on the server within a PerformancePoint Services application instance, and they call the BIMonitoringServiceApplicationProxy object or SPDataStore object to author or process content. For more information about editors, see Editors for Custom PerformancePoint Services Objects.
Using PerformancePoint web services for remote access is not an officially supported scenario. To enable client applications to access PerformancePoint Services, you can create a custom web service that runs on the server. The web service can receive calls from the client application and make calls to the PerformancePoint Services API.
Extension Metadata in PerformancePoint Extensions
You must specify metadata for your extension in the PerformancePoint Services web.config file during the installation process. The metadata includes type, subType, RendererClass, EditorURI, and Resources attributes. For more information, see How to: Manually Register PerformancePoint Services Extensions.
Creating PerformancePoint Scorecard Transforms
Transforms change the appearance, contents, or functionality of scorecards before querying the data source, after querying the data source, or before rendering the scorecard in the Web Part. For more information, see Overview of PerformancePoint Services Scorecard Transforms.
Getting Started with PerformancePoint Services Development
Setting Up the Development Environment for SharePoint 2010 on Windows Vista, Windows 7, and Windows Server 2008
Create Custom Objects for PerformancePoint Services
Code Samples for PerformancePoint Services in SharePoint Server 2010