We recently migrated from TFS 2010 to TFS 2015 and came across that some of the reporting services are not working anymore.
One of the view we created was pulling various information (WorkItem State, Title,Fld10118) from "WorkItemsLatest" table, however, checking the collection database of TFS 2015 indicates that there is no more "WorkItemsLatest" table in TFS 2015 collection database.
I would appreciate if you can advise how to get above mentioned fields in TFS 2015 collection database. I understand that the operational databases are not supported by Microsoft and encourages to retrieve data from Warehouse database, however, we would like to retrieve this data and will allocate some development time in the future to ensure that data is retrieved from the Warehouse database.
WARNING
Even though you've already mentioned this yourself, querying the database tables directly can lead to breaking functionality between updates. With the recent amount of churn in the work item space (new template customization features landing on VSTS and probably coming to TFS vNext and the new workitem form), expect these items to keep changing in the near future.
Ok, I get it
So, you're probably looking for the following two views:
[Tfs_DefaultCollection].[dbo].[vw_denorm_WorkItemCoreLatest]
[Tfs_DefaultCollection].[dbo].[vw_denorm_WorkItemCustomLatest]
And join them with tbl_Field to be able to identify which Custom Field ID matches which Field Name.
Related
We do a lot of TFS analysis and reporting in Excel, using PowerPivot to map to 'executive friendly' terms (like dates vs iterations) and they are quite please with all that. However, we also now have several TFS 'projects' (instances, versions, whathaveyou), and an Excel workbook cannot link to more than one project at a time. Also as the projects grow larger and larger, my machine struggles to process. I'd like to put the mapping tables AND the TFS data from several instances into an Access database.
Question 1
Is there any way to link Access to TFS? If not, I'm fine having TFS data in Excel and linking to Excel, but with the 'header' TFS insists on putting in your export, the linked table has issues (like not having headers in first row, and then always having two erroneous records upon every refresh).
Question 2
Any thoughts on how to get around the funky header?
There is no native way to link Ms Access to TFS or to easily get rid of the header row that's added in Excel when linking a table. I'm afraid that the direction you're seeking will not help you in the end. It will only put all the computational pressure on Access instead of Excel.
The way to go here would be to setup the TFS reporting features, which offloads a lot of the processing to SQL Server Analysis Services (which can be used as a source for Excel) and reporting is provided by SQL Server Report Server in that case.
Unfortunately, the Reporting part of TFS hasn't had a decent update since 2010 and can be a bit archaic to use. For VSTS (the cloud-based version of TFS) it's now possible to link the account to PowerBI, which does everything you're after. This feature is not available on-premise though, it may be a great reason to move to the cloud. PowerBI can handle large amounts of data, can be connected to one or more VSTS accounts and can slice and dice data from multiple accounts and projects with ease.
I am working with TFS 2013 and generating reports with SSRS however I have benn tasked with creating a detailed report showing all steps and acceptance criteria for each test case and list the available parameters. I have searched and searched the web and have not found any examples that show the test steps.
Thank you in advance.
In most instances the Test Steps fields are not set to reportable by default so they are not populated in normal reporting databases. You'll need to set them to reportable or create a new data source targeting your TFS transaction databases instead of the Warehouse/Cube databases.
It is not recommended you target transaction databases with reports since this can affect performance of TFS when reports are run. Especially a field like Test Steps since it might need to pull a lot of data at once.
Use the witadmin command to change the reportability of the Test Steps field. Using detail will only put the information in your Warehouse while the detail option will put it into the Warehouse and the Cube. Where you want it depends on how you write your reports. Once set the reportability type can only be changed in limited ways, so please keep this in mind when deciding how you want it set.
witadmin changefield n:<nameOfFieldToChange> /collection:http://yourcollectionURL:8080/tfs/YourCollectionName /reportingtype:<dimension,detail>
See the reportable attributes section for details.
Long version, what I've read and tried so far:
I'm trying to optimize a weekly task for some of our users. We have a CMS build using Angular that uses MySQL to store entries that are now reviewed within the CMS after which they write an evaluation in SharePoint 2013 (on prem SQL Server 2012 on one machine, SharePoint 2013 on another server all in the same domain).
The goal is to have the MySQL entries show up in a SharePoint list as soon as they are created. I'd be highly preferred if the arrival of a new MySQL entry could spark a 2013 WorkFlow (send email, update webparts, log changes to task-lists etc).
The CMS currently does have NuSoap installed to feed a mobile application, but SharePoint Designer has some issue with reading all the fields from the WSDL and I read that this is one of the preferred methods to obtain pushed data into workflows, but I could not get SharePoint to usa the call http web service with success. Adding the WSDL as data source did only include the index and did not display anything in a webpart.
An alternative option was using ODBC on the SQL Server to grab the data in a SQL view from the Linked Server and copy the new entries over when they arrive. I have managed to make a view that can be used as External Content Type in SharePoint Designer 2013 and than can successfully be displayed in SharePoint as an External List.
Given the nature of the submissions, the content cannot be altered in the MySQL database. But I do want users to be able to add notes and other fields in SharePoint.
I found in two (older) Sources (the one on Stack Overflow) that it is not possible to fire a WorkFlow when using External Content Types, since "SharePoint does not own the data", but SQL Server does, so you cannot attach a workflow or have a workflow be notified when an entry is added.
==
TL;DR version
How do you make a "copy" of MySQL data from a read only source into a SharePoint 2013 List?
Neither the business data connection tools (web services as data source) nor the External Content Type solutions seem to result into a solution with default SharePoint List with attached Workflows.
For this specific solution push or frequent updates are required.
I have sucessfully set up the reporting capability for my TFS 2012. Now I'd like to report effort per work item (like User Story). I'm using the Agile process template, so the tasks and user stories have a field for typing in effort. However, during report creation I can't idendify the table and colum where the effort resides. Can anyone give a hint?
Found it. It's in the table FactCurrentWorkItem, field Microsoft_VSTS_Scheduling_CompletedWork.
HI!
Does anyone have any idea how to synchronize MS Access data to SharePoint portal. I would like to link both of this together and trigger a workflow upon receiving a new data entry.
Hope you could advice on it.
Thanks!
In Access you can have so called "linked tables". You can have access linked tables with a Sharepoint installation. In Sharepoint this linked table manifests itself as a regular list, so you can have a workflow trigger on each new item created.
There is a nice tutorial here: How to Link SharePoint Server 2007 Lists with Microsoft Access 2007 and for Sharepoint 2010 and Acccess 2010 Microsoft hast written something nice: Synchronize a SharePoint 2010 list with Access 2010.
Additionally let me show you some Screenshots from Access. When you go to External Data > Export > Sharepoint List (see next screen)
When you click on that button you get the following dialog where you can select where to export your table to:
The same dialog you get when you Right click on a table, go to Export > Sharepoint List.
Now if you want to synchronize your data, you need to link that created Sharepoint list to your Access DB. So you click on External Data > Import > From Sharepoint List and you get the following dialog:
When you have a linked table it is synchronized with Sharepoint.
I think you are looking for this article.
http://office.microsoft.com/en-us/sharepoint-designer-help/add-a-database-as-a-data-source-HA010100908.aspx
Basically, you need to create a new Data Connection Library (pick from the Library list in the "Create" page). And then follow the steps depending on the connection method (i.e. Single Sign-On, custom connection string, or user id/password).
The process involves migrating your access tables to SharePoint. So if you moved or migrate a table in Access to SharePoint AND THEN choose to link the table, then it is a live connection to SharePoint. This is a bi-direction synnc of that table. So any change in Access (any update to that linked table) will see changes sent to the same table (list) in SharePoint. This is a VERY different process then trying to sync a whole file. So power-point files, or even a Access file does not work well at the FILE level, and you don't get any kind of multi-user setup.
However, if you migrate the tables to SharePoint lists, then any sql query you build in Access against that linked table will work just fine. And that includes append query, update query, or just a select for data.
And you can even work against these linked tables in off-line mode. This means that you can continue to update the tables even without network connection. When you do finally get wi-fi or some internet connection, then the data will auto-sync (both ways) and tables will update missing or changed data.
Note that you can even migrate and maintain related data, and SharePoint now supports relations and maintains those relations for you (referential integrity between tables is supported when using Access 2010 (or later) and SharePoint 2010 (or later).
VERY careful steps are required to migrate related tables. Access will migrate and send related tables of data to SharePoint (and maintain the relations for you). You simple have to ensure that your relations are of a type that SharePoint supports.
This means your PK has to be a autonumber ID type, and the foreign key has to be standard long data type. Since this setup is the vast majority of Access relationships, then these types of related tables move rather well to SharePoint. However, if you PK/FK setup is say a string, then such relationships don't work in SharePoint.
The other issue is to keep in mind that performance issues can arise when the row count exceeds 5000 rows when using Office 365 or hosted SharePoint. If your SharePoint system in on-premises then you can turn off some of these limits.
Migration of related data tables is easy, but you need to ensure you setup the relationships using the table lookup wizard in most cases. Sometimes you can use the relationship window, but in most cases, you need to re-build the relationship in a correct way BEFORE you migrate the tables to SharePoint. If your don't have related data, and just a few tables, then you don't really have to do much of anything in Access before you migrate such tables.
As noted, once migrated to SharePoint, then any sql query you execute against such linked tables will work fine. So no need to update the table local, or on SharePoint - the whole process is fully automatic and synced for you.
This video shows how to migrate related data tables to SharePoint if that is your requirement:
https://www.youtube.com/watch?v=3wdjYIby_b0&t=0s&list=PL27E956A1537FE1C5&index=3
Edit
Given that the tags are for SharePoint 2007, then you will find that access 2010 (or later) and SharePoint 2010 (or later) is required for referential integrity to work. And pre Access 2010, you find performance of linked lists to be rather slow, and table row counts needs to be keep small. (under 10,000 rows).