Where can I find online reference for diagrams or text/XML dump of Microsoft CRM (2013 or 2015) table/fields, entity/attributes . I don't have access to an instance of the software, but need a heads up on structure and naming conventions.
Bunch of diagrams for 2013 can be found here
Related
My work group recently upgraded from TFS 2013 to TFS 2015; and migrated the database to the new environment. We use the TFS kanban for tracking our work, and for allowing customers to see all the possible items in the input queue to vote on which item is worked on next. We had built a custom SSRS report to get this data out of the TFS database for review from our customers... But now that we've upgraded TFS, a table that was integral to this report is now missing? The table which is now missing is dbo.WorkItemsAre.
Is anyone familiar with where/how the TFS kanban items will be tracked after migrating to 2015? It seems like the documentation on the TFS database has always been lacking when I try finding anything on MSDN or a microsoft site.
Thank you!!
For customized reports you should use the warehouse database (Tfs_Warehouse). You can find the documentation about work item tables here.
Or you can use the cube. The documentation about the work item perspective is here.
For data not available in either the warehouse or the cube you can use the RestAPI or the Client API.
The operational databases are not supported by Microsoft. You may also be asked to remove anything you have built against the operational store for any support to be given.
I wanted to use some queries using the TFS SDK in .net,
It would make things easier if I had access to the database schema.
I found this which says there is no such documentation but it is from 2007. Is there any sort of documentation for TFS 2013 now or is there still none?
TFS database schema is not documented for the reason that you are not supposed to use it directly. The reason being that database schema changes between versions of TFS and whatsoever you would have created might/would stop working after an upgrade or update. Please use TFS API instead.
Having said that, there are some blogs and guides that use database directly. Have a look at Grant Holiday's blog who has posted about using some queries to get some statistics e.g.
http://blogs.msdn.com/b/granth/archive/2009/10/23/tfs2010-sql-queries-for-tfs-statistics.aspx
Also, ALM Rangers reporting guide contains an appendix about Work Item Store Database schema
https://vsarreportguide.codeplex.com/downloads/get/764892
DISCLAIMER: As I said, the data model can and will change over time so be mindful of that.
Please check Work item field and database schema reference. It includes two important components
Relational warehouse database
Analysis Services cube
To understand warehouse schema, you'd better have a basic understanding of star schema, fact and dimensions. There are also several view to help you not touch table directly. TFS data warehouse is very powerful, from which you can generate all kinds of report including project progress, bug trend, test report, etc.
We're doing an application which takes feeds and items in that feed to entities on our own site. This is supposed to be an open site which anybody can sign up to. All of this is done with MVC + knockoutjs. We are thinking about managing the entities from that site using Sharepoint 2013, essentially replacing our SQL tables of those entities, and putting them into lists on in our Sharepoint instance. We're also thinking of doing the same thing for users and passwords and such. Then we might have a setup for a single sign on for any other sites my company makes. Currently we're using NHibernate and SQL server.
Are we are naive to think that Sharepoint could handle the amount of traffic, with outside users using our site, along with customers. I've heard that it's doable, I'm just wondering if it's a smart thing to do, and if there are hickups, limitations that any of you have run into trying to do this.
We went pretty far down the Sharepoint-as-a-development-platform path and ultimately ended up scrapping what we had done and rewriting it in other technologies. That doesn't necessarily mean it is not the right choice for your situation, but there a few things to consider:
"Why do it this way?". What are the benefits to adding the Sharepoint layer to your technology stack? If not Sharepoint, what do the alternatives look like?
Do you already have a solid Sharepoint admin team in place? Sharepoint definately requires a dedicated admin or team of admins that really understand the product to keep it performant and to help you troubleshoot when things are not working correctly.
Do you have Sharepoint development talent already in house? Good Sharepoint developers are harder to find and are typically more expensive than your regular .NET developer. Also, some existing .NET developers may not be interested in learning Sharepoint.
What is your expected traffic, and can Sharepoint handle it out of the box? At least in previous versions of Sharepoint there were internal limits on the amounts of data that could be stored in each list. On top of that, there were practical limits before the performance of the app becomes totally unacceptable. Understanding what those limits are should be a part of your initial due diligence so you can plan for those eventualities.
Will you be extracting operational data for external reporting or warehousing purposes? Is your data team already familiar with getting data out of Sharepoint?
Ultimately, the reason we failed was we ran down the path after the promise of "easy" development without really committing to the product. When we started running into problems, we struggled with basics like troubleshooting because we had lost a couple key people and our regular devs and admins struggled to figure out what was going on. If we had had the right people in place, our experience might have been different. We didn't, however, and we eventually chose to move away from Sharepoint and rebuild on our standard MVC/SQL platform.
SharePoint has come a long way in a short time to allow external applications to interact with it in the way you describe. I wouldn't try it with anything but SharePoint 2013 mostly because the licensing allows for this without additional cost per user and partly because what I mention next isn't available in 2010 or earlier.
You can use a MVC/knockout frontend but, the MVC app for SharePoint template isn't exactly what you want unless you will provision every user as a SharePoint user account. That template is still an SP app which means it's run by an SP user. I would look at SharePoint as just an OData service that your app writes back to. You can either use the client object model (SCOM) and write back directly (each user exists as a SharePoint user), or you can proxy the data access from your MVC controller and use a 'service' SP user to connect to SharePoint using SCOM. SCOM is just REST and OData so you can use any web-capable language you choose. I know there are examples for C# and JavaScript (node.js). There may be others.
If you are expecting a lot of volume, I would suggest you host this application on SharePoint Online (Office 365), if possible, and configure it to federate with the rest of your environment. That way you only need to add more space as your data grows (rather than more and more servers as load grows).
Here's a nice overview of the APIs available to you:
http://msdn.microsoft.com/en-us/library/office/jj164060.aspx
SharePoint 2013 Developer Center:
http://msdn.microsoft.com/en-us/library/office/jj162979.aspx
5 minute video on SharePoint 2013 SCOM:
http://www.microsoft.com/office/preview?videoid=1e859ac8-58ca-46d0-a8e0-00f4189761a8&from=sharepermalink-link
Timely blog on anonymous access to SCOM:
http://blogs.msdn.com/b/kaevans/archive/2013/10/24/what-every-developer-needs-to-know-about-sharepoint-apps-csom-and-anonymous-publishing-sites.aspx
There is no point to redesign you application only for replacing your database tables with sharepoint lists. Performance is one issue. Sharepoint list limitation is another issue, you will lose flexibility from relational database design and give your life to a black box design called sharepoint list.
I'm a newbie to ASP.NET MVC. I've been learning MVC 3 for the past couple months and at my job I have to design a CRM system using MVC 3.
In all MVC 3 tutorials, they use MS SQL Compact Edition.
In the CRM project, I have to import Products table from the QB Database and populate that into the CRM.
Keeping in mind, the CRM has to use the QB database and import the products table and
Should I save the CRM data in SQL CE or should I use SQL Server to save all the CRM data as well as the QB data?
MVC 3 is entirely decoupled from the data layer.. The reason you'll have seen most tutorials coupling it with SQL Compact is because most web application tend to need a database of some sorts to be functional and SQL Compact is one of the simplest options when focus should really be on MVC itself.
As far as MVC, you need some way of making data available to the controller and ultimately the view.. you don't even have to use the entity framework (which I guess most examples use for simplicity), however, if you do want to use the entity framework, it looks like you can query quickbooks directly by using this
As I understand, you should implement next logic:
Retrieve needed data from QuickBooks. Here you can use any kind of paid tools like RssBus QuickBooks Data Provider mentioned above, but you are still free to do it using QuickBooks SDK directly (QBXML or QBFC), it is not so hard.
Convert received data to format applicable to your Products table structure.
Perform data export using LINQ to SQL or whatever you want. It is completely up to you which edition of MS SQL Server to use and depends only on complexity of functionality that you need from it.
We would like to give our customers access to report bugs and to look at existing bugs and work items, through Team Foundation Server.
For that, we will need a web frontend, which is customer-friendly. It should be easy to use and with a nice UI. I am aware of Web Access, but think it is too developer-oriented for our customers to use.
Is there any good open source or commercial products out there for doing this? It is important that we will be able to customize the products for our needs.
There is WIWA, but it's quite similar to the regular web access tool. It exists more as a licensing aid (helping TFS admins ensure they don't overstep the CAL requirements) than as a fresh new UI aimed at non-developers.
Note: get it from the latest download package for TSWA SP1, not the CTP linked in the blog post
I don't know of any other solutions that are as customizable as you're hoping. I've seen (and contributed to) one-off solutions that were tailored for a specific work item type. At the broadest level, you could say that the bug pages # connect.microsoft.com and # Codeplex fall into that category as well. But none of them is publicly available, nor would they be helpful even if published.
You'll probably need to do a one-off of your own using the Work Item Tracking API. Luckily, this is far easier than writing a generalized workflow engine / forms designer that knows how to parse WIT XML.
A bit of a shameless plug as I'm the project owner: Spruce is an ASP.NET MVC2/jQuery driven front end for TFS 2010 aimed at replicating the user-friendly approach you find in products such as Fogbugz, Unfuddle and online sites such as Github, Bitbucket.
A few screenshots:
I'll be adding the list of features found on the blog at the start of the year.