The other day I decided to start a power user best practice series. I started with site columns and now the next logical step is content types. I have found that many times experienced users don’t realise the importance of a properly setup content type. Because of this, they often are recreating the same data, having to redo the content types and in some cases blow them away and start over (both of which are a real pain if the CT is already being used). The intent of this post is to cover the best ways to create your content types.
So today I am starting a new series on SharePoint Best Practices. This may seem like a fairly simple topic but, I have come to learn that it is an important one. I am not talking about best practices in setting up and configuring SharePoint or how to best develop a solution in SharePoint. I am instead wanting to discuss best practices in your day to day usage of SharePoint. Too many times I have worked with experienced clients that have a decent knowledge of how to do things in SharePoint, but don’t think of the little things that make these best practices. This is where this series is coming from. Today I am going to cover site columns.
Years ago when Microsoft released it’s latest version of SharePoint Designer, it came with a few enhancements that really made building workflows with Designer more robust and efficient. One efficiency enhancement was the ability to copy actions, steps and even entire stages within the same workflow or even between workflows. Microsoft also allowed for the ability to move back and forth between stages instead of continuing down a parallel path (called a state machine workflow). While the addition of state machine workflows to Designer (previously only available in Visual Studio workflows) is great; in my opinion the best (by a very small margin) addition to Designer is the ability to call web services. As your queries get more and more complex however, knowing what is coming back into the workflow can be filled with frustration as you try to determine how to get the data from the response content. While I it isn’t a new concept, I wanted to discuss handling REST responses in SharePoint Designer workflows. Or at least how I do it. The method I use is pretty straight forward and very easy to implement.
The other day I was taking a look at Vlad Catrinescu’s blog on quickly creating a SharePoint 2013 dev farm. It’s a great blog and provides some good information on creating a dev environment much faster than you could ever do it manually. I like to develop in an environment as similar to the production environment as possible and I also have the hardware to do it. With this in mind I wanted to come up with a way to quickly build a multi-server SharePoint 2013 developer environment. The problem is that for a single server install you could be looking at hours to install and configure, a multi-server environment could take even longer. I set out to build scripts that would not only deploy the SharePoint environments but would also create the VMs, deploy Active Directory and SQL Server, and configure the network. In addition, I wanted to be able to do this more than once (as different environments are sometimes needed at different times).
So recently at my client site we had a report that was running incredibly long. This was a while ago, so unfortunately I can’t remember the run time, but I believe it was greater than 12 hours. The report was pretty basic, just a determination of which documents were created within the month and an output that displayed things like location, file name, created date and creator.
When reviewing the code I noticed the original solution had been coded to loop through each site in the web and then grab all the documents within a particular date range. The line in particular that scanned the documents was as follows:
var listAddedItems = listItems.Where(x => ((DateTime)x["Created"] >= reportManager.ReportStartDate && (DateTime)x["Created"] <= reportManager.ReportEndDate) || ((DateTime)x["Modified"] >= reportManager.ReportStartDate && (DateTime)x["Modified"] <= reportManager.ReportEndDate));
Pretty straight forward, but what it’s actually doing is going through and gathering all the data and throwing out what you don’t need. Not a big deal unless you are working with a lot of data. Right now we are sitting at around 1 million items in our SP farm. I think I found the culprit.