Windows SharePoint Services Infrastructure for Project Server

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.

Microsoft Office Project Server 2007 is now a full member of a Windows SharePoint Services server farm. Each Project Web Access site collection can include subsites and an optional project workspace site for each project. A server farm with one Project Server installation can include multiple Project Web Access applications and Shared Services Providers (SSPs).

Project Server can import SharePoint task lists as project proposals. This article describes how Project Server and Windows SharePoint Services work together, as well as some of the ways to use SharePoint data. The article includes the following sections.

• Windows SharePoint Services Infrastructure

• PSI Methods and DataSets for Project Workspaces

• Using SharePoint Data

  • Resource Name Conflicts

  • Getting the Site ID for Impersonation

  • Problems with Importing SharePoint Task Lists

Windows SharePoint Services Infrastructure

Project Server middle-tier services are contained in an SSP virtual directory. You can see in Internet Information Services Manager that the Office Server Web Services application contains the name of the SSP virtual site (for example SharedServices1). Windows SharePoint Services manages the front-end Web sites in the associated content Web applications (Figure 1). The SSP manages shared services that are installed on the server. Windows SharePoint Services includes the Search, Incoming E-Mail, and Web Application services. Project Server includes the Project Application Service. Microsoft Office SharePoint Server 2007 includes Excel Calculation Services, Document Conversions services, and a higher-level Search service. When you provision a Project Web Access instance, the Shared Services Administration application creates a Project Web Access site that uses the Project Application Service.

The Project Web Access site is a Windows SharePoint ServicesSPSite object that is created under the top-level Web site of an extended SharePoint Web application.

Figure 1. Windows SharePoint Services infrastructure for Project Server

Project workspaces are Windows SharePoint ServicesSPWeb objects. You can choose to create a project workspace for a project when it is published. A project workspace functions as team collaboration Web site for the project, and contains the specialized SharePoint lists for project documents, issues, risks, and deliverables. A project workspace also includes other lists defined in the default team collaboration site definition, including announcements, events, project tasks, and so forth.

You can create a project workspace as a child of any site in the SharePoint content Web application. Project workspaces can be children of the Project Web Access site, other project workspaces, or even other SharePoint sites created from non-project site templates.

Note
While the design for workspace location is flexible, we recommend that you create project workspaces as children of the Project Web Access site to make it easier to locate related workspaces.

For example, suppose the URL of the default Web site of a Project Server installation is http://ServerName, and you extend the top-level Web site to host the project team site (http://ServerName/default.aspx). When you create an SSP, Windows SharePoint Services also creates the SSP administration site, with the Shared Services Administration: SharedServices1 home page (http://ServerName:11863/ssp/admin/default.aspx).

If you navigate to the Manage Project Web Access Sites page (http://ServerName:11863/ssp/admin/_layouts/managepwa.aspx) and provision a Project Web Access instance named ProjectServerName, the Project Web Access application is a subsite of the top-level Web site with the URL http://ServerName/ProjectServerName.

Sites created within the same site collection (that is, under the ProjectServerName site in the previous example) share the same SharePoint content database and can benefit from the cross-site aggregation features of Windows SharePoint Services. The Project Web Access site URL is the default path under which project workspaces are created. The default workspace URL helps to organize all of the collaborative data for projects in the Project Web Access instance. A Project Server administrator can change the default workspace URL in the Project Workspace Provisioning Settings page in Project Web Access (http://ServerName/ProjectServerName/_layouts/pwa/Admin/WorkspaceProvisioningSettings.aspx), or use an application that programmatically changes the default workspace with the Project Server Interface (PSI).

PSI Methods and DataSets for Project Workspaces

You expose all features of the Project Workspace Provisioning Settings page in Project Web Access by using the WebSvcWssInterop (http://ServerName/ProjectServerName/_vti_bin/psi/wssinterop.asmx). All project workspace programming begins with the creation of a WssInterop object. The WssInterop Web service defines the following three datasets:

• ProjectWSSInfoDataSet   Includes a reference to the server; name of the workspace subsite; and lists of issues, risks, deliverables, and other information for a project workspace. Use ReadWssData to get a ProjectWSSInfoDataSet for a specified project.

• WssSettingsDataSet   Contains one row in WssSettingsDataSet.WssAdminDataTable that includes all of the properties for provisioning a project workspace in the Project Web Access instance. Use ReadWssSettings to get a WssSettingsDataSet; use UpdateWssSettings to change the provisioning settings.

• WssServersDataSet   Contains a list of all Web applications known to the Project Web Access instance. Use ReadWssServerInfo to return a WssServersDataSet. You can choose a Web application in the list for project workspace provisioning and linking.

For a code sample that uses ReadWssServerInfo, ReadWssSettings, and UpdateWssSettings, see Extending the Project Workspace Template.

For a sample that uses ReadWssData, see How to: Use the OLP to Link an Object to a Task.

For more information about Project Web Access architecture and the SSP, see Project Server Architecture and Project Server Programmability. For more information about Windows SharePoint Services site definitions, see Working with Templates and Definitions in the Windows SharePoint Services 3.0 SDK.

Using SharePoint Data

Many methods in the Windows SharePoint Services API return data in XML format, which enables creation of applications or custom Web Parts that are integrated with SharePoint data for Project Web Access, project workspaces, and other sites in a SharePoint farm. All of the SharePoint field names start with ows_. You can use the Lists.GetListItems method to get information about items in any SharePoint list.

For example, set a Web reference to the project workspace such as http://ServerName/ProjectServerName/ProjectName/_vti_bin/lists.asmx, name the reference WssWebSvcLists, and then add the following code to get information about the Issues list.

WssWebSvcLists.Lists wssLists = new WssWebSvcLists.Lists();

wssLists.Url = "http://ServerName/ProjectServerName/ProjectName/_vti_bin/lists.asmx";
wssLists.Credentials = CredentialCache.DefaultCredentials;    
string webID = string.empty
XmlNode node = wssLists.GetListItems("Issues", null, null, 
    null, null, null, webID);
string issueData = node.InnerXml;

Following is an example of data returned by GetListItems in the issueData variable for all of the fields in one issue. The data is formatted here.

<rs:data ItemCount="1" xmlns:rs="urn:schemas-microsoft-com:rowset">
    <z:row 
        ows_Attachments="0" 
        ows_ID="1" 
        ows_LinkTitle="Test Issue" 
        ows_Status="(1) Active" 
        ows_Priority="(2) Medium" 
        ows_Category="(2) Category2" 
        ows_DueDate="2006-06-30 17:00:00" 
        ows_MetaInfo="1;#" 
        ows__ModerationStatus="0" 
        ows__Level="1" 
        ows_Title="Test Issue" 
        ows_owshiddenversion="1" 
        ows_UniqueId="1;#{2215ED1D-1A9F-4F96-9653-3161B117EF15}" 
        ows_FSObjType="1;#0" 
        ows_Created_x0020_Date="1;#2006-06-28 11:24:00" 
        ows_Created="2006-06-28 11:24:00" 
        ows_FileLeafRef="1;#1_.000" 
        ows_FileRef="1;#ProjectServer/PTool1/Lists/Issues/1_.000" 
        xmlns:z="#RowsetSchema" />
</rs:data>

For the attribute ows_Title, for example, the actual field name is just Title. When you search for fields in the XML data, you must search by using the added ows_ prefix.

If you use the viewFields parameter in GetListItems, you can specify the fields to return. The field names must not include the ows_ prefix in the Name attribute of the FieldRef elements.

For example, the viewFields parameter in the following code specifies the ID and Titlefields.

XmlDocument doc = new XmlDocument();
string namespaceURI = string.Empty;
XmlNode viewFields = doc.CreateNode(XmlNodeType.Element, "ViewFields", namespaceURI);
viewFields.InnerXml = "<FieldRef Name=\"ID\" /><FieldRef Name=\"Title\" />";

string webID = string.Empty;
XmlNode node = wssLists.GetListItems("Issues", null, null, 
    viewFields, null, null, webID);
string issueData = node.InnerXml;

The issueData variable shows the ID and Title fields, along with some metadata, when GetListItems uses the viewFields parameter.

<rs:data ItemCount="1" xmlns:rs="urn:schemas-microsoft-com:rowset">
    <z:row 
        ows_ID="1" 
        ows_Title="Test Issue" 
        ows_MetaInfo="1;#" 
        ows__ModerationStatus="0" 
        ows__Level="1" 
        ows_owshiddenversion="1" 
        ows_UniqueId="1;#{2215ED1D-1A9F-4F96-9653-3161B117EF15}" 
        ows_FSObjType="1;#0" 
        ows_Created="2006-06-28 11:24:00" 
        ows_FileRef="1;#ProjectServer/PTool1/Lists/Issues/1_.000" 
        xmlns:z="#RowsetSchema" />
</rs:data>

Resource Name Conflicts

Project Server uses the Windows SharePoint Services API to import SharePoint task lists as project proposals or activities. The server running Windows SharePoint Services containing a task list does not need to be located within the same server farm as Project Server.

There are limitations on resource names that you can assign to tasks when you import a SharePoint task list with assigned users into Project Server. If tasks in the SharePoint list are assigned to users, in some cases a SharePoint user name can be assigned to the wrong resource in Project Server.

To import a SharePoint task list, Project Web Access makes a SOAP call to the Windows SharePoint Services server by using the GetListItems method, which returns XML data to the client. The assigned user of a task is in the attribute ows_AssignedTo; for example, the following is a SharePoint user name attribute from GetListItems.

ows_AssignedTo="1;#Justin Thorp" 

After Project Server trims the index data, the name becomes "Justin Thorp". There is no other identifier for the SharePoint user; Project Server does not have the user's domain. For example, suppose tasks in a SharePoint list are assigned to the users in the domains listed in the following table.

Project Server enforces unique display names in the enterprise resource pool. The following cases show how name conflicts can occur.

• Task assigned to wrong user: DOMAIN_1\justint is in the Project Server enterprise resource pool as "Justin Thorp," and someone imports a SharePoint task list with an assignment to the "Justin Thorp" who is DOMAIN_2\jthorp. After import, Project Server sees only the name "Justin Thorp" and assigns the task to DOMAIN_1\justint.

• Assignments are merged to one local user: If tasks in a SharePoint list are assigned to both DOMAIN_1\justint and DOMAIN_2\jthorp, and there is no "Justin Thorp" in the enterprise resource pool, Project Server creates a local resource named "Justin Thorp" and merges the assignments to that one resource.

Note

To avoid resource name conflicts, make sure that Project Server resource names match the resource names in the SharePoint task list before you import. If they don't match, you must modify the resource names or modify the assignments after import. You can match the names manually or create a utility application that provides an intermediate file or display that compares SharePoint resource names with Project Server resources.

For more information about limitations of user assignments when importing SharePoint task lists, see CreateOperationsWorkFromWssList.

Getting the Site ID for Impersonation

To ensure an application calls the correct PSI method when using impersonation, it requires the Project Web Access site ID. You can use the SiteData Web service in Windows SharePoint Services to get the site ID. For more information, see SiteData Methods in the Windows SharePoint Services 3.0 SDK.

If you develop or install the application on the computer where Project Web Access is hosted, the SPSite.ID property in the Windows SharePoint Services API returns the site ID. Set references to both the Microsoft.SharePoint and Microsoft.SharePoint.Search assemblies.

using Microsoft.SharePoint;
. . .
private const string PROJECT_SERVER_URI = "http://ServerName/ProjectServerName";
. . .
Microsoft.SharePoint.SPSite site = new SPSite(PROJECT_SERVER_URI);
Guid siteId = site.ID;

If you plan to install the application on a remote computer, you can get the Project Web Access URL and site ID from a project workspace URL using the SiteData Web service in Windows SharePoint Services. For example, add a Web reference to http://ServerName/ProjectServerName/_vti_bin/sitedata.asmx, name the reference WebSvcSiteData, and then use the following code.

WebSvcSiteData.SiteData siteData = new WebSvcSiteData.SiteData();
siteData.Url = "http://ServerName/ProjectServerName/_vti_bin/sitedata.asmx";
siteData.Credentials = CredentialCache.DefaultCredentials;

string url = "http://ServerName/ProjectServerName/Workspace Name";
string pwaUrl;
string pwaId;

siteData.GetSiteUrl(url, out pwaUrl, out pwaId);

You can also get a lot of other Windows SharePoint Services information. For example, the following code uses the GetWeb method in the WebSvcSiteData Web reference to return information about project workspace sites, lists, security roles, users, and groups.

WebSvcSiteData._sWebMetadata wssWebMetadata = null;
WebSvcSiteData._sWebWithTime[] wssWebs = null;
WebSvcSiteData._sListWithTime[] wssLists = null;
WebSvcSiteData._sFPUrl[] wssUrls = null;
string wssRoles;
string[] wssUsers;
string[] wssGroups;

siteData.GetWeb(out wssWebMetadata, out wssWebs, out wssLists,
                out wssUrls, out wssRoles, out wssUsers, out wssGroups);

Problems with Importing SharePoint Task Lists

Project Web Access uses methods in the private PWA Web service to import a SharePoint task list in as a project proposal or activity. Importing SharePoint task lists has the following restrictions:

• Project Server can drop an assignment in a SharePoint task list in the following set of conditions:

  1. A Project Server user with a Windows account (for example, DOMAIN/UserNotResource) does not have the User can be assigned as a resource checkbox selected on the Edit User page in Project Web Access (http://ServerName/ProjectServerName/_layouts/PWA/Admin/AddModifyUser.aspx).

  2. A task (for example T1) in the SharePoint task list is assigned to UserNotResource.

  3. When you import the SharePoint task list to a new project proposal, the task T1 is no longer assigned to UserNotResource in the proposal.

• If a calendar view of a SharePoint task list does not contain any tasks in the current month, when you try to import the SharePoint task list, the import list does not show any tasks.

See Also

Tasks

How to: Create a Project Workspace and Link it to a Project

How to: Use the OLP to Link an Object to a Task

Concepts

Extending the Project Workspace Template

Project Server Architecture

Project Server Programmability

Other Resources

Using Impersonation in Project Server

Working with Templates and Definitions

Sites (How Do I... in Windows SharePoint Services)

SiteData Methods

SPSite Class

SPWeb Class

Lists.GetListItems