Introduction to PDS - PSI Parity
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) is the managed code interface for Microsoft Office Project Server 2007. The Project Data Service (PDS) is an XML message interface for earlier versions of Project Server. This topic explains the difference between the PSI and the PDS. Subsequent topics in this section list the equivalent PSI methods for developers who need to migrate applications or integration components to Project Server 2007.
The PDS is an XML-based API for Microsoft Office Project Server 2003 and Microsoft Project Server 2002. The PDS includes methods for much—but not all—of Project Server functionality. Microsoft Office Project Professional 2003 and Microsoft Office Project Web Access 2003 gained access to some Project Server functionality through the PDS, and some functionality through direct database access. Third-party developers sometimes had to create PDS extensions with direct access to the Project Server database to create custom solutions, such as a solution to integrate Project Server with line of business (LOB) applications.
The PSI includes methods that are functionally equivalent to the PDS methods, but does not address PDS functionality that is obsolete in Project Server 2007. The PSI provides functional parity with the PDS, not a 1:1 method or parameter equivalence.
For documentation of the PSI Web services, see the PSI Reference Overview. For a general explanation of using PSI methods and datasets, see Project Server Interface (PSI) Overview.
Programmability Issues in Project Server 2003
The database is an important part of programmability in Project Server 2003. Because the PDS does not provide comprehensive functionality, developers must sometimes directly access the Project Server database for data not available through the PDS, or they must write PDS extenders. PDS extenders usually access the Project Server database directly.
Direct database access has several shortcomings:
Multiple applications frequently need to implement similar business logic. When different applications implement different semantics for the same business logic, the changes each application makes to the database can cause the implementations to conflict. That is, a change from Project Web Access uses the Project Server business logic through the PDS, and a change from a third-party application can create a conflicting change through a different set of business components using direct database access.
Because developers have to write PDS extensions when the required functionality is missing, the Project Server database must be documented. This makes it difficult to change the Project Server database schema in later versions.
Schema changes can break applications that worked with earlier versions of Project Server.
Direct database access uses a different security model than Project Server. Applications with direct access either circumvent the built-in Project Server authentication and authorization, or developers have to reimplement access using the Project Server security API.
Other programmability issues in Project Server 2003 include the following:
The Project Server 2003 security object model is COM-based and awkward to use in a Microsoft .NET Framework environment.
Project Professional uses ODBC to directly access the Project Server database. Project Server does not throttle (limit) Project Professional calls, which can lead to performance and scalability issues. When Project Professional sends a large amount of data to the server, for example when saving a large project, Project Server 2003 must synchronously process all of the data. Multiple concurrent Project Professional sessions can significantly degrade the server performance.
The interaction between Project Professional and Project Server is very sensitive to network issues. Network latency can adversely affect the performance even on high-bandwidth connections.
The lack of a server-side scheduling engine requires you to use Project Professional for some actions, such as accepting timesheets and applying updates to the project plan. This limits server-side automation and integration.
The Project Server 2003 object model exposes no events. Developers must implement actions based on simulated events using SQL Server triggers.
Key Programmability Features of Project Server 2007
Project Server 2007 solves the programmability problems in Project Server 2003 in the following ways:
A business object layer provides reusable business logic components that all applications can access. Different applications use the same semantics for the same business logic.
The PSI provides a complete API. Developers do not need to directly access the Project Server Draft, Published, or Archive database. Accordingly, those databases do not need comprehensive documentation.
The business logic abstracts the physical implementation of data storage and implementation of business processes. A business logic layer provides an interface that can stay the same from version to version.
The Project Server 2007 API and security model are based on the Microsoft .NET Framework 2.0. Project Server security can provide a single sign-on for all applications that integrate with Microsoft Office SharePoint Server 2007. Windows SharePoint Services 3.0 manages Project Server authentication and authorization permission sets.
Project Professional 2007 uses a local cache and the PSI to interact with Project Server. The Project Server Queuing Service enables asynchronous publishing for improved performance and scalability. Applications can avoid hanging while publishing or doing updates.
Project Server 2007 includes a scheduling engine that enables server-side automation of timesheets and project updates.
The Project Server 2007 Eventing Service enables many new kinds of applications and new ways to integrate with other applications.
Server-side Events
Server-side events provide a mechanism for developers to extend Project Server by adding new business logic. Project Server raises events whenever units of data change on the server. If you associate an event handler with an event, then the handler is executed when that particular event occurs.
There are two types of events: pre-events and post-events. Pre-events are raised before data is saved to the database. These events can be canceled by event handlers. Post-events cannot be canceled; they are raised after the data changes are saved to the database.
Reporting Database and OLAP Cubes
The Reporting database (RDB) is fully supported and documented for direct access and also has a programming interface. The RDB contains near real-time data from the Published database. The RDB is designed to be an optimized data source for reporting applications. The Project Server OLAP cubes are built from the OLAP views in the RDB. For more information, see Using the Reporting Database.
See Also
Tasks
How to: Write and Debug a Project Server Event Handler
Reference
Concepts
Project Server Architecture and Programmability