Overview of the Synchronization Process for Team Foundation Server and Project Server Integration

Artikel
08/13/2012

You can manage the integration of Visual Studio Team Foundation Server 2010 and Project Server 2007 with Service Pack 2 (SP2) or Project Server 2010 more effectively if you understand how the synchronization engine manages the flow of data between the two server products. The synchronization engine supports the independent workflows of project managers who work in Project Professional and team leads and team members who work in Team Foundation. Deliverables and tasks can evolve independently in each area.

In this topic

Three Types of Synchronization
Data That Is Subject to Synchronization
Data Validation That Is Performed During Updates and Upon Submission
Mirror Fields and “Two Sets of Books”
Permissions That Are Required to Support Synchronization
Error Notification, Event Logging, and Traceability

Three Types of Synchronization

The synchronization engine performs three types of synchronization. This process captures and updates task-related and resource-related data in both Team Foundation Server and Project Server while respecting the ownership of data by the project manager in the project plan. Project managers make changes by using Project Professional and approve updates through Project Web Access or Project Web App (PWA). Development team members submit updates to Project Server by using a client of Team Foundation.

As the following illustration shows, data synchronization consists of seven main steps.

Synchronization Process for Team Foundation Server and Project Server Integration

PS-TFS Synchronization process

The synchronization engine consists of a single job service that runs on a regular schedule and not when each work item is updated. The synchronization job performs the following three processes in the order indicated:

Publish synchronization:

Step 1 A project manager defines or updates tasks or deliverables and sets the Publish to Team Project value to Yes for each task that they want to synchronize.

Step 2 The project manager publishes the enterprise project plan by using Microsoft Project Professional. Changes are automatically saved to the database for Project Server.

Step 3 The synchronization engine pulls data from Project Server and determines what data to update based on the data that is configured for synchronization. Only those objects, tasks, and work items that are configured for synchronization are updated.

Step 4 The synchronization engine either creates or updates work items in Team Foundation and defines a link that binds the task in Project to the work item in Team Foundation.

Status synchronization:

Step 5 A team lead or team member either modifies a work item in Team Foundation that is linked to a task in an enterprise project or creates a work item and sets the Submit to Project Server value to Yes. The synchronization engine queries the changes that are made for mapped team projects and sends requests to the approval queue or queues in Project Web Access or Project Web App (PWA).

Approval synchronization:

Step 6 Each project manager reviews their approval queue and either approves or rejects each status update request.

After updates are approved, the project manager must publish the project plan before the updates will appear in Project Server.

Important

When the synchronization engine submits multiple levels of work items to Project Server, the first level must be approved and published to Project Server before the next level can be submitted. For example, you can submit a batch of new work items that includes three levels of child items. In that case, the project manager must publish the project plan four times for all work items to be synchronized with Project Server.

Step 7 The event handler for approvals in Project Server transmits the approval decisions to the synchronization engine, which then updates the work items in Team Foundation Server based on the approval status.

For more information, see Understanding How Updates to Specific Fields Are Managed.

Managing Approvals and Rejections

All changes to work items that are linked to Project Server must be submitted for approval to the project manager of the enterprise project plan that is mapped to the team project. You can set up automatic approval so that all updates from Team Foundation are automatically approved. For more information, see Approve or reject task updates.

Approved work items typically get rolled back into the enterprise project plan. Rejected work items require resolution and resubmission.

For rejected updates, a message appears in the History field for the work item. The message indicates the value that was rejected and who rejected it. For team projects that map to project plans that are hosted on Project Server 2010, the message also contains any comments that the project manager provided about why the item was rejected. Team members must either reconcile the work item and resubmit it or remove it from being submitted to the enterprise project. Also, team members can create a work item query that finds all rejected items based on the Project Server Last Submit Status. For more information, see Monitoring Work Item Submissions and Resolving Rejections.

For information about auto-approval and auto-publish, see Operational Differences Between Project Server 2007 and Project Server 2010.

Synchronization and Retry Intervals

Data synchronization occurs on a schedule and not when each work item is updated. The synchronization job service runs every 30 seconds. During that time, it queries for the relevant work items and fields that have been modified in Project Server or Team Foundation Server or that the project manager has approved.

Every hour, the synchronization engine resubmits work items that failed to update previously. For more information, see Changing the Synchronization Retry or Resubmit Interval.

Data That Is Subject to Synchronization

Two levels of configuration determine which objects can participate in synchronization and what data becomes synchronized. Administrators for Team Foundation perform several levels of mapping to configure the objects that can participate in synchronization. At the second level, project managers and users of Team Foundation control which specific tasks and work items are synchronized.

Objects That Are Configured to Participate in Synchronization

The following configurations determine which objects participate in the synchronization process. Administrators for Team Foundation generally perform these configurations. However, project managers may also map their enterprise project plans to team projects.

PWA Instance That Is Mapped to a Team Project Collection: This mapping configures the team project collection to support synchronization and determines which instances of PWA can synchronize with a collection.
Enterprise Project Plan That Is Mapped to a Team Project: This mapping configures both the enterprise project plan and the team project to participate in synchronization. This mapping also determines which enterprise projects can synchronize with a team project.
Work Item Types That Are Mapped for Synchronization: When you map an enterprise project plan to a team project, you specify the types of work items that can be synchronized. This mapping adds the Project Server tab to the work item form and adds validation rules for each work item type to the enterprise project plan.
Work Item Fields That Are Mapped to Project Server Fields: By default, the synchronization engine synchronizes the following fields in Team Foundation: Title, Assigned To, Completed Work, Remaining Work, Original Estimate, Start Date, and End Date. You can add fields and set parameters that determine how fields synchronize. For example, you can determine which fields appear on the work item form and whether to allow separate values for a specific field.

For more information, see Mapping Project Server Components to Team Foundation Components and Specifying the Work Item Types That Can Be Synchronized.

Individual Task and Work Items That Are Configured for Synchronization

Project managers determine the tasks in an enterprise project plan that they want to publish to Team Foundation Server. Team members determine the work items in a team project that they want to submit to Project Server. Project managers can publish detailed breakdowns of deliverables and tasks to Team Foundation Server or publish and manage only summary task elements. Some restrictions apply to the publishing of subordinate tasks or parent-child work items, as Data Validation Performed During Updates and Upon Submission describes later in this topic.

For more information, see Managing Project Details in an Enterprise Project Plan Mapped to a Team Project and Top-Down Planning of Business Requirements within an Enterprise Project Plan Mapped to a Team Project.

Note

You can map multiple enterprise project plans to one team project, but you can map or link only one task in a project plan to a work item in Team Foundation. Each task in an enterprise project plan is distinct in Project Server. Tasks that are submitted to Project Server update only one work item in Team Foundation. Also, work items that are created in Team Foundation and submitted to Project Server update only one enterprise project plan.

Data Validation That Is Performed During Updates and Upon Submission

The synchronization process validates tasks and work items that have been tagged for synchronization before they are published to Project Server. Data validation is enforced in both the enterprise project plan and the team project.

When Project Managers Publish an Enterprise Project Plan

When a project manager who is working in Project Professional publishes an enterprise project plan that is mapped to a team project, specific validation checks are performed. The Team Foundation add-in performs the following validation checks on those tasks that are set to publish to Team Foundation (that is, Publish to Team Project=Yes):

The value that is set for the Work Item Type field must match a type of work item that has been configured to participate in synchronization for the target team project.

Important

Text30 is the default Project field that is associated with the Work Item Type column that is used in synchronizing tasks with work items. If you ever connect the project plan to Team Foundation Server by using the Choose Team Project option on the Team ribbon menu, an additional Project field, which is also labeled Work Item Type, becomes available. This field, with a default Project field of Text24, supports mapping of project plans that are bound to Team Foundation but does not support synchronizing plans. The Text24-based field contains the full list of work item types for the team project. You can verify whether you have the correct field by pointing to it and verifying that Text30 appears.
All values for mapped Project fields must pass specific checks to make sure that their values do not violate a rule that was set for the target work item type. These rules are added to the enterprise project plan when it is mapped to a team project.
After a task is published, the values that are set for Publish to Team Project and Work Item Type cannot change. If you do not want to continue to synchronize a task, you must delete it.
If a task and one of its subordinate tasks are both marked for synchronization, all tasks between them must also be marked for synchronization.
The value of the Resource Name field for a task must match the name of a valid contributor for the target team project.
If multiple resources are assigned to the same task, only one resource assignment must be selected as active. For more information, see Making Agile Team Progress Visible to the Program Management Office.
All values must conform to the rules that Project Server applies to the specific field definition. For example, an error can occur if you assign a value to a mapped field that is associated with a look-up table but that is not in the look-up table.

The Validation Resolution dialog box appears whenever one or more rules are violated. Project managers must resolve each error before publishing the changes.

When Developers Submit New or Updated Work Items from Team Foundation

When a developer who is working in Team Foundation creates or updates a work item and saves the changes, the following validation checks are performed on those work items that are set to publish to Project Server (that is, Submit to Project Server=Yes):

The value of the Assigned To field must correspond to a team member who also has been added to the enterprise resource pool and the project resources in the project plan. For more information, see Assigning Permissions to Support Integration of Project Server and Team Foundation Server.
If only one enterprise project plan is mapped to a team project, its name automatically appears for the Enterprise Project field on the Project Server tab for newly created work items.
If more than one enterprise project is mapped to the team project, you must specify a value for the Enterprise Project field for new work items that are created and whose Submit to Project Server value is set to Yes.
You cannot change the hierarchical structure of work items after they have been linked to Project tasks. For more information, see Summary Tasks, Task Hierarchy, and Submissions of Work Items that Are Nested at Multiple Levels.
Rules that have been added to a mapped work item type can result in validation errors when you publish the project plan. For example, a conditional rule can restrict what values users can assign to a field. For more information, see Working with Field Rules.
Basic rules, such as lookup tables, that correspond to definitions of fields in Project Server can cause errors during status synchronization. For example, an error will result if you use a lookup table to define valid values for a field in Project, map that field to a field in Team Foundation, and then set the field in Team Foundation to a value that is not in the lookup table.

After a work item is published to Project Server, the item is bound to a task in the target enterprise project plan. This binding is also referred to as a link. The links are locked during synchronization. To remove the link, you must delete the corresponding task in Project, or you must use the /force option when you remove the mapping of the project plan or work item type. For more information, see Removing a Component from Participating in Data Synchronization.

Mirror Fields and “Two Sets of Books”

Because the synchronization engine performs three types of synchronization and communicates with two databases in a scheduled negotiation, no data merging occurs. Instead, data synchronization occurs in a two-step sequence, and the engine allows for divergence between the two products. For each synchronized field in Team Foundation, you define a mirror field that stores the value in Project Server for the corresponding mapped field. During regular synchronization operations, the values for the two fields will differ from the time when a value is updated in Team Foundation Server until the project manager approves the update and publishes the project plan.

For each field that you map, you specify one of the following choices for how you want the synchronization engine to update the reference field in Team Foundation:

Always update the reference field in Team Foundation Server with the value from Project Server (PSWins).
Allow the value for the reference field in Team Foundation Server to differ from the value assigned in Project Server. This strategy is referred to as “two sets of books.”

When you maintain two sets of books, you can create a query to find those work items where the two values differ. For more information, see Understanding How Updates to Specific Fields Are Managed and Find Work Items Where the Work in Team Foundation Differs from that in Project Server.

For more information, see Field Mapping XML Element Reference for Integration of Team Foundation Server and Project Server.

Permissions That Are Required to Support Synchronization

For data to be synchronized between Team Foundation Server and Project Server, the following permissions must be granted:

For Project Server 2007, you must grant the service account under which the TfsJobAgent runs access to Shared Services Provider. For more information, see Grant Service Account to Shared Services Provider for Project Server 2007.

For Project Server 2010, you must grant Full Control permissions to the service account under which the TfsJobAgent runs so that the Project Server Service Application can be accessed. For more information, see Add a Service Account to the Project Server Service Application for Project Server 2010.
You must grant the service account under which the TfsJobAgent runs the permissions that are required to access each mapped instance of PWA.
Users who are assigned to tasks in Project Professional or work items in Team Foundation must be recognized as Contributors in the team project. Those users must also be recognized as resources of the enterprise project plan and granted permission to log on to the instances of PWA that participate in the synchronization process.

For more information, see Assigning Permissions to Support Integration of Project Server and Team Foundation Server.

Error Notification, Event Logging, and Traceability

The synchronization engine processes project updates that are published to Project Server, then status updates, and then approval updates. When you publish, you update Project Server, adding tasks and task details to the enterprise project plan. Publishing synchronization pulls the data from Project Server into Team Foundation Server. Status synchronization pulls data from Team Foundation to update the project manager’s approval queue, and approval synchronization publishes updates on fields such as remaining work and completed work to Project Server, which initiates a new cycle of synchronization.

Each type of synchronization enables the display of relevant status and error messages to the project manager in either Project Professional or the instance of PWA. Also, status and error messages that are associated with the synchronization engine and its configuration can also be written to the appropriate administration interfaces for Team Foundation Server and Project Server.

Project managers, team members, and administrators can all view and diagnose synchronization-related messages as they occur. Messages are written to the following locations:

In Project Professional, the status bar in the enterprise project plan shows publishing progress.
In the instance of PWA, the Approval Center shows the queue of updated tasks.
In the work item form for Team Foundation, the Project Server tab indicates the status and time when the work item was synchronized most recently.
In the work item form for Team Foundation, the History field records synchronization status and error messages after each update of the work item. When you integrate with Project Server 2010, comments that project managers write when they approve or reject a status update are also recorded in the History field.
The event log for the application-tier server that participates in the data synchronization maintains a record of all synchronization events and errors.

Administrators can retrieve the most recent event messages by using the TfsAdmin ProjectServer /GetSyncMessages command. For more information, see Viewing Synchronization Engine Error Messages. To gather even more detailed information, you can enable detailed tracing for the Team Foundation Background Job Agent that runs the services. For more information, see Team Foundation Background Job Agent.

Change History

Date	History	Reason
September 2011	Added links to topics that describe how the synchronization engine updates specific fields, and which versions of Project Server support auto-approval and auto-publish.	Information enhancement.
June 2011	Added information about the validation checks made when members of the development team submit or update work items.	Information enhancement.
April 2011	Clarified and renamed the section that describes mirror fields and two sets of books. Corrected the introductory paragraph of the section on error notification, event logging, and traceability.	Content bug fix.

September 2011

Added links to topics that describe how the synchronization engine updates specific fields, and which versions of Project Server support auto-approval and auto-publish.

Information enhancement.

June 2011

Added information about the validation checks made when members of the development team submit or update work items.

Information enhancement.

April 2011

Clarified and renamed the section that describes mirror fields and two sets of books. Corrected the introductory paragraph of the section on error notification, event logging, and traceability.

Content bug fix.

Dela via