다음을 통해 공유

Editors for Custom PerformancePoint Services Objects

  • 아티클

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.

In this article
Providing Editing Controls for Object Properties
Interacting with Repository Objects
Integrating with Dashboard Designer

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: SharePoint Server 2010

Note

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.

Providing Editing Controls for Object Properties

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.

Note

PerformancePoint Dashboard Designer provides controls for the Name property, Description property, and Owner (Person Responsible) property of a custom object in its Properties tab.

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.

Interacting with Repository Objects

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:

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.

Note

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.

Integrating with Dashboard Designer

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:

  1. 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.

  2. 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.

  3. 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.

  4. The Web server control appends query string parameters to the editor path and then opens the editor.

Note

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.

Table 1. Query string parameters

Parameter

Description

Operation=

The operation for the editor to perform: OpenItem to retrieve an object from the repository or CreateItem to create an object in the repository.

Example: ?Operation=OpenItem

SiteCollection=

The URL of the site collection.

Example: &SiteCollection=http://ProductionServer

ItemLocation=

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.

Example: &ItemLocation=/Lists/PerformancePoint%20Content/39_.000

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).

Note

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.

See Also

Other Resources

Create Custom Objects for PerformancePoint Services

Fundamentals of PerformancePoint Services Development

Code Samples for PerformancePoint Services in SharePoint Server 2010