TFS Admin, Part III - POC Extending TFS Warehouse

If I had a dollar for every time I wished for the capability to configure and store metadata about team project in TFS, I could at least take a very long vacation. Using a custom list in SharePoint to keep track of team projects and their metadata is the best solution I've come up with so far, especially if you use it as a request queue. But it´s still a non integrated solution causing manually work if you want to do reporting or anything useful with it.

Extending TFS Warehouse with metadata
Having metadata in a SharePoint list, which I could write code against, and knowing that the TFS warehouse is extendable gave me the idea to feed the TFS warehouse with team project metadata. For this to work I need the team project names to be the same in both the SharePoint List and TFS. This should not be a big issue for anyone, especially if you use the SharePoint list as a request queue and automatically create team project as described in previous post.
My plan was to write a generic adapter for the TFS warehouse, extending the Team Project dimension in the warehouse with selected fields from the SharePoint list.

Writing a custom TFS Warehouse adapter
My plan was to write a generic adapter for the TFS warehouse, extending the Team Project dimension in the warehouse with selected fields from the SharePoint list.
After some research on MSDN I was ready to start. A custom adapter is simply a class implementing the 3 methods in IWareHouseAdapter, compiled into an assembly and deployed to a special folder. To implement the IWarehouseAdapter interface you have to write code to make
• Make Schema Changes to the TFS Warehouse and cube
• Make Data Changes, i.e. create rows in the database
• Handle Initializing, request to stop processing
The TFS API provides an object model for the warehouse, together with some good articles on msdn and Steve Wrights posts How I built a Team Foundation Server custom data warehouse adapter made it pretty easy writing the adapter and deploying it to the server.

Retrospective - the real challenges
In retrospective I can see that the biggest challenges had nothing to do with writing the adapter or handling a SharePoint custom list. Looking back I spent more time doing other stuff then writing the logic for the adapter. The other things taking most time from the real task were:

Testing and the test environment
Running the test environment (a virtual PC image of o complete TFS setup) locally on my old and slow laptop were not funny. In order to save time, I tried reinitializing the TFS warehouse between tests. But this took too long time, so I ended up with reverting the virtual my machine and setting up my environment for every test run. Maybe a better design/separation and mocking could have saved time in the end.

Trying to make the Warehouse over complex
My lack of real world experience from BI projects took me out on long journey trying to make a too complex warehouse in order to handle the metadata in a generic way. After many hours trying to implement the advanced model with the TFS API I consulted a colleague with real life experienced of BI project and went for a really simple design instead.

Handling configuration for the adapter dll
Needing to store some configuration and have it easily handled I thought that using a .config file for the dll would be the best fit. I simply added settings to the adapter project and used the Properties. Settings class. Things worked nice until I tried changing the value in the .dll.config file. As I was afraid of it didn’t work. After hours of fruitless search for a way to get the framework to actually read my config file, I gave up and derived a custom setting provider from LocalFileSettingsProvider, override the GetPropertyValue method reading the config file as an XML document. Once I decided to write my own settings provider was I was done in 15 minutes, but I wasted several hours looking for a better solution.

Reducing technical dept
As I needed to wrap a SharePoint list in this project to I started to break out the SharePointListWrapper into a utility project. One thing lead to another and in the end I ended up fixing some of the code for the Automated Order Process to.
Doing so I repackage the source for The Automated Order Process, although the code is in better shape, it is like the TeamProejctMetadataAdapter still a proof of concept.


http://cid-5d46cae8c0008cf0.skydrive.live.com/self.aspx/.Public/POC%20TeamProjectMetadataAdapter.zip