Introduction to the PSI Web Services

Article
05/05/2014

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The Project Server Interface (PSI) provides a managed code API for Microsoft Office Project Server 2007. The PSI is implemented as a set of Web services for remote access by all Microsoft Windows and Web clients, and components of other applications. Microsoft Office Project Professional 2007 and Project Web Access, as well as third-party applications, use the PSI exclusively as the Project Server API.

PSI Fundamentals

The PSI is the interface for developers to programmatically access the middle-tier Project Server business objects. In earlier versions of Project Server, developers frequently needed or preferred to access Project Server data directly through the database. In Project Server 2007, we strongly advise developers to use only the PSI so that data processing is scheduled by the Project Server Queuing Service and processed by the business objects to help maintain consistency and validity.

User access to the Web services follows the Project Server authentication and authorization settings.

For information about what the PSI is designed to do, and what it does not do, see Project Server Programmability.

Interface Constancy

The PSI methods are designed to remain as a standard API across future Project Server versions. PSI methods may be added, and there may be cases where a PSI method must be deprecated if the nature of a feature fundamentally changes. In that case, the PSI method will follow a deprecation path through a "cross-over version" of Project Server that allows time for developers to modify applications that consume the deprecated method.

The WinProj and PWA classes in the PSI Web services are designed for use only by Project Professional and Project Web Access. Web methods and signatures in those classes may change in service packs or later versions.

Type Checking

Each PSI method is implemented in a separate interface. All parameters in PSI methods, and all return values, are strongly typed data. For example, the ReadCalendars method accepts two parameters: filter of type string and autocheckout of type bool. ReadCalendars returns an object of type CalendarDataSet.

Typed parameters and return values make programming with the PSI easier and safer with the IntelliSense feature in Microsoft Visual Studio and the type-checking mechanism in the .NET Framework.

Groups of Web Methods

The PSI methods are grouped, or factored, in a set of Web services that share related functionality or interact with specific Project Server business entities (business objects in the middle tier). For example, the Project, Resource, and Calendar business entities have associated classes named Project, Resource, and Calendar in PSI Web services of the same names.

Each PSI Web service has an associated .asmx page on the Project Server computer that lists all of the public PSI methods for that business entity. Figure 1 shows the view of Calendar.asmx in Internet Explorer. If you click ReadCalendars, you can see the SOAP XML request and response along with the parameter and return types.

Figure 1. PSI methods in the Calendar Web service

PSI methods in the Calendar Web service

For documentation of all PSI Web services, methods, properties, events, and related datasets, see the PSI Reference Overview.

DataSet Parameters and Return Values

Many PSI Web methods use a DataSet object as a parameter or a return value. A DataSet object is essentially an in-memory database that can include multiple tables and relationships. For example, the CreateResources method of the Resource Web service uses a ResourceDataSet parameter; the ReadResource method returns a ResourceDataSet object.

In Microsoft ADO.NET 2.0, DataSet objects have high performance and provide standard ways to read, write, and manipulate data. Developers who are familiar with the ADO.NET DataSet class already know how to program with PSI datasets.

PSI Architecture

Project Server 2007 has a multitiered architecture. The application tier consists of two sub-tiers; the Web services tier and the business logic tier. The Web services tier contains the PSI Web services that invoke the private business objects hosted in the business logic tier (Figure 2). The business objects in turn reference project data through the data access layer (DAL). All applications, including Project Professional and Project Web Access, read and write Project Server data through the application tier by making PSI calls.

Figure 2. Simplified Project Server architecture

Simplified Project Server architecture

With the exception of the Reporting database, developers should not directly access the Project Server databases. The PSI methods and business logic components provide a common set of semantics for all applications, so that different applications do not implement similar business logic in different and competing ways.

The business logic layer abstracts the physical implementation of how data is stored and provides an interface that can stay the same from version to version. Schema changes in future versions of Project Server would likely break applications that directly access the Draft, Published, or Archive database.

The Project Server application tier implements business logic, data validations, security validations, and data transformations, all of which are needed to ensure data consistency and validity. If other applications access the database directly, they can introduce data inconsistencies and corrupt the data. For more information about Project Server architecture, see Project Server Architecture and Programmability.