Editors for Custom PerformancePoint Services Objects
Published: May 2010
In PerformancePoint Services in Microsoft SharePoint Server 2010, the primary function of a custom editor is to enable users to set properties on a custom object. A custom object is a native ReportView object, Filter object, or DataSource object that has custom values defined for its properties.
An editor runs within a PerformancePoint Services application instance on the front-end Web server, typically as an ASPX page. Web applications that run within a PerformancePoint Services application instance and in a SharePoint process are located in the /_layouts virtual directory and are installed by default to the LAYOUTS folder in the path %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE.
Applies to: PerformancePoint Services for SharePoint Server, Enterprise version
An editor is one component of a custom report, filter, or data source extension, and it is needed only if the extension requires a user interface to set properties. For information about other extension components, see Development Scenarios with PerformancePoint Services.
To enable users to set properties for custom objects, editors provide editing controls and interact with objects in the repository.
An editor defines properties for a custom object and exposes properties through editing controls. Your editor should expose the properties that you want to enable users to view and modify. For an example of a method that makes ASP.NET controls available to a report editor, see the CreateChildControls method in How to: Create Editors for PerformancePoint Services Reports.
We recommend that you use the custom objects sample as a template for your custom editor. The sample editors define ASP.NET controls in the HTML markup of an ASPX page, following the SharePoint development practice of defining business logic in a class that is compiled in a DLL instead of in the code-behind class used in ASP.NET development. The sample also shows how to call objects in the Microsoft.PerformancePoint.Scorecards.Client DLL.
Editors (and other custom web applications) run within a PerformancePoint Services application instance on the front-end web server and use the BIMonitoringServiceApplicationProxy object and SPDataStore object in the PerformancePoint Services API to perform Create, Read, Update, and Delete (CRUD) tasks, as follows:
For custom data source objects, use the BIMonitoringServiceApplicationProxy class to perform Create and Update tasks. This enables these tasks to be performed within the context of the PerformancePoint Services service application. Read (get) and Delete tasks can be performed by using BIMonitoringServiceApplicationProxy or SPDataStore. (Custom applications that run on the application server can call SPDataStore directly.)
For custom report and filter objects, use the SPDataStore class.
We recommend that you use the helper objects included with the custom objects sample to perform operations against the repository instead of calling the BIMonitoringServiceApplicationProxy and SPDataStore objects directly from your editor.
Calling PerformancePoint web services remotely is not an officially supported development scenario and is beyond the scope of this documentation.
Your editor does not need to provide logic for creating objects because Dashboard Designer is configured to create custom objects by default. However, it is possible to enable users to create objects without using Dashboard Designer. For more information, see Creating Objects Outside of Dashboard Designer. In addition, custom objects can be deleted from Dashboard Designer and from the repository, so providing logic to delete objects from your editor is also optional.
To integrate into the Dashboard Designer authoring experience, your editor must be able to open from a uniform resource identifier (URI), and the URI must be registered for the custom object in the PerformancePoint Services web.config file.
To create a custom object, Dashboard Designer retrieves the object's metadata from the PerformancePoint Services web.config file and then creates the object as a content type in the PerformancePoint Services repository. Data sources are created in a SharePoint document library, and report and filter objects are created in a SharePoint list. After creating the custom object, Dashboard Designer displays a link to the editor.
PerformancePoint Services uses the following process to open a custom editor:
When a user attempts to edit a custom object from Dashboard Designer (or a content type in the repository), a query string is passed to a Web server control. The query string provides the location of the object in the repository.
The Web server control interrogates the object to identify its type and subtype. The object's subtype indicates whether the object is native or custom.
If the object is custom, the Web server control looks up the URI of the object's editor in the PerformancePoint Services web.config file.
The Web server control appends query string parameters to the editor path and then opens the editor.
Users must refresh the Dashboard Designer session to see recent changes made in custom editors.
Query String Parameters
PerformancePoint Services appends the query string parameters to the editor URI when it opens a custom editor. The following table describes the parameters.
The operation for the editor to perform: OpenItem to retrieve an object from the repository or CreateItem to create an object in the repository.
The URL of the site collection.
The location of the first class object in the PerformancePoint Services repository. Data source objects are stored in a document library, such as the PerformancePoint Data Connections Library, and all other objects are stored in a list, such as the PerformancePoint Content List.
You can specify custom static parameters for your editor in the PerformancePoint Services web.config file. Static parameters pass a predefined value to the editor every time it is opened. For more information about registering an editor, see How to: Manually Register PerformancePoint Services Extensions.
Alternatively, you can refer to these parameters by their corresponding constants in the PerformancePoint Services object model instead of using the query string. These constants are represented by the LaunchOperation, SiteCollectionUrl, and ItemLocation fields in the ClickOnceLaunchKeys class (in the Microsoft.PerformancePoint.Scorecards namespace in the Microsoft.PerformancePoint.Scorecards.Client DLL).
PerformancePoint Services also appends the SiteLocation= parameter, but it is not relevant to custom extensions.
Creating Objects Outside of Dashboard Designer
By default, users can create custom objects from Dashboard Designer only. Because Dashboard Designer creates custom objects without using custom editors, it sends only OpenItem requests to custom editors.
To enable users to create objects outside of Dashboard Designer, you must provide the following functionality:
Logic in your editor code to create objects
An action that sends a CreateItem request to your editor
For example, to send a Create request from an item in the repository, you can add a menu item and action that sends a CreateItem request from the item to your editor. PerformancePoint Services stores its custom actions in the following path: %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\Template\Features\PPSWorkspaceCtype. For more information about adding custom menu items, see How to: Modify the User Interface Using Custom Actions.