SharePoint Portal Integration

Description:

The client's project managers and executives were using a SharePoint Portal Server as the front end to their corporate management and reporting system. They wanted these SharePoint users to be able to view Team Foundation Server queries and reports using the same SharePoint interface that they were already used to.

Before migrating to TFS, the client was using a third-party defect tracking system to track their customer's "Work Orders". Secondarily, they also used SharePoint lists to track work orders, so that managers could view work order status from within SharePoint. In effect, they were double-submitting their work orders, once into the defect tracking system and once into SharePoint. The obvious synchronizations problem ensued from this mode of operation.

We proposed a solution whereby work order information could be pulled directly out of TFS and displayed within SharePoint, dispensing with the double-submittal process.

Background:

As we've worked on this project and other projects, we've experienced a common theme: using alternative interfaces, expecially web interfaces, to access, view, and update TFS items, queries, and reports.

The primary interface into Team Foundation Server is the Team Explorer desktop client. Team Explorer installs itself as and add-in to Visual Studio. Thus, Visual Studio is required to use Team Explorer. This creates a problem for non-technical managers and other extended team members who typically do not have Visual Studio installed on their desktops.

Microsoft recognizes this problem and has provided a separate component, Team System Web Access (TSWA) as a web-based alternative to using Team Explorer. To allow limited access for non-licensed users, Microsoft also provides the Work Item Web Access (WIWA) component, which is also web-based.

In addition to TSWA and WIWA, TFS automatically creates and maintains a portal for each project you create in TFS. This portal is created using Windows SharePoint Services (WSS) which is a technology included with Microsoft Windows Server. To confuse matters, Microsoft also has their Microsoft Office SharePoint Server 2007 (MOSS 2007) product, which is not free. MOSS 2007 is based on the underlying WSS technology, but provides various enterprise-level functionality not found in WSS. In other words, one type of "SharePoint" is free, and one costs money.

All of this begs the obvious question of what happens when the client is using both TFS and MOSS? Unfortunately TFS and MOSS are not as well integrated as one would hope, a point which has been commented about by various bloggers on the Internet. Microsoft's Brian Harry has also written about this, and is a area which Microsoft has promised to address in the upcoming Visual Studio 2010.

Solution:

By combining the SharePoint and TFS API's, we wrote a series of SharePoint Web Parts that gave the client the information they were looking for, and at the same time simplified their work order management process.