Thursday, August 03, 2006

Work Item Migration via the WIT Web Service (Part 3/3)

Uploading through the Web Service requires sending an xml package through the Client Service that contains all the work item information. The xml package mentioned last post in insertWorkItem has the following format:

<Package Product=http://your_server:8080/WorkItemTracking/v1.0/ClientService.asmx DisableNotifications=”True” xmlns=””>
  <InsertWorkItem ObjectType=”WorkItem” BypassRules=”True”>
      <ComputedColumn Column=”System.RevisedDate”>
      <Column Column=”System.WorkItemType”>
      <Column Column=”System.AreaId”>
      <Column Column=”System.CreatedBy” Type=”String"/>
    <InsertText FieldName=”Microsoft.VSTS.CMMI.Analysis” FieldDisplayName=”Analysis”>text goes here </InsertText>

Column values for System.WorkItemType and System.AreaId are absolutely required for web service update. These relate the work item to the database. Team Project is specified through the System.Area field, and not through the System.TeamProject field (not required). All other Column entries require a Type to accompany the field name.

Fields of type HTML or PlainText must be entered into parameters instead of through . Fields of type String have a character limit of 255.

The most valuable (from a migration-perspective) part of this xml package, and really the only reason to use the Web Service method instead of the OM to upload, is the BypassRules attribute. Setting this attribute value to True allows the State/Reason/Transition rules to be bypassed, as well as allowing values such as Created By/Date, Resolved By/Date, Closed By/Date to be programmatically set.

Note: Microsoft could release a new version of their WIT Web Service at any point in time and change the format of the Package document. This (and previous) posts are to provide an outline of the methodology for web service uploading of work items.