Developing PSI Extensions
Applies to: Office 2010 | Project 2010 | Project Server 2010 | SharePoint Server 2010
The Project Server Interface (PSI) for Microsoft Project Server 2010 can be extended with custom services by using the Windows Communication Foundation (WCF) interface. PSI extensions tightly integrate with Project Server, can call other PSI methods, and can use the same security infrastructure that the rest of the PSI uses.
In Microsoft Office Project Server 2007, a PSI extension requires creating an ASMX-based web service. After installing it in the global assembly cache (GAC), you make the web service discoverable through an .asmx file on the front end, and a .disco file and a .wsdl file on the Project Server shared services back end. For more information, see Walkthrough: Creating a PSI Extension for Project Server 2007.
In Project Server 2010, the web services are available only on the Project Web App front end. In addition, web services are based on the WCF infrastructure and generally use .aspx files rather than .asmx files. Authentication is by claims processing, which requires using a WCF service. Calls to WCF-based PSI services go through the ProjectServer service in Project Web App, which acts as a router to the back-end services. Consequently, a PSI extension for Project Server 2010 is written by using WCF and is also installed in the GAC. The extension is made discoverable through a .svc file that is installed in the shared web server extensions for Project Web App.
Following are some scenarios that can benefit from PSI extensions:
Pulling data from the Reporting database (RDB): A PSI extension can directly query the RDB from the server. For example, third-party applications that are deployed outside a firewall cannot do a direct query of the RDB on Project Server, but can use a PSI extension service to query the RDB.
Consolidating information from several PSI calls: Save bandwidth; make one call to the server instead of many calls.
Manipulating and formatting data for a third-party application: Save client-side processing by doing work on the server and returning only data that the application uses.
Integrating better with third-party applications and line-of-business (LOB) applications: Extend the functionality of Project Server with PSI extensions for client applications and middleware components for LOB applications such as human resources, finance, or customer relationship management (CRM).
PSI extensions, and applications that use them, should include appropriate security checks. People without the relevant global permissions or category permissions should not be able to access Project Server data through a PSI extension. However, you should not overdo the use of PSI extensions; use them efficiently to reduce the negative effect on server performance.
Tip
The RDB user views include many useful collections of data. Before you write a PSI extension that simply reads and consolidates data from within your corporate firewall, investigate using a simple query of the RDB.
In This Section
Creating a PSI Extension for Project Server 2010
How to: Create a PSI Extension to Read Custom Fields in the RDB
See Also
Concepts
Other Resources
Walkthrough: Creating a PSI Extension for Project Server 2007
Blog Article: How to Make PSI Extensions in Project Server 2010—Part I