views:

119

answers:

2

I just finished my first web Part for Sharepoint WSS 3.0 and I'm very excited.
What it does is that just makes a connection to the TFS (team foundation) to get the OPEN and FIXED bugs by Sprint (We actually use SCRUM agile Process). Then takes both values (open & fixed) and puts them in a sharepoint list. A chart is fed with that list (using codeplex's web parts).

In the other side the web part retrieves information about the current team names from the Project Server, it follows the same procedure but it just feeds a Sharepoint list.

Any recommendations on performance or anything else would be much appreciated.

PD. i will set this as a community wiki 'cause there is no correct or wrong answer, just waiting for your feedback =D.

+5  A: 

I'm a bit confused... Your webpart populates the list with values from TFS?

If you use a webpart, the list is populated only when someone visits the page and EVERYTIME someone visits the page.

Wouldn't you want to populate your SharePoint list using a console application or a SharePoint timer job that runs every so often?

Kit Menke
+1 for the timerjob. I am with you on that one. A console app is easier, but a timerjob keeps in the "SharePoint realm", which allows for simultanious deployment of the list that's filled with the queried data. and the TimerJob.
Colin
+1A sharepoint webpart should not be used to fill any lists. You need a reliable way of doing it ONCE every day. If noone is using sharepoint, then noone will fill the list for you. So a timerjob is the way to go (Which SharePoint also offers)Also make sure you start using spdisposechecker right away ;)
Heiko Hatzfeld
Sounds pretty good, thank you very much! one last question what if I want to filter information by User on that information retrieved from TFS and Project Server?
YeomansLeo
If you have a People field called User in your sharepoint list, you can create views based on this User field. You can set filters where "User is equal to [Me]" to have personalized views.
Kit Menke
A: 

To go a step further. Use federated search. In SharePoint (MOSS) you can specify locations (content sources) for the search service to index. This data will then be queryable in your sites. Using either custom scopes / customized search queries you can retieve data and then filter / display it on your sites.

Colin