Free Books

Another large collection of Free Microsoft eBooks and Resource Kits for you, including: SharePoint 2013, Office 2013, Office 365, Duet 2.0, Azure, Cloud, Windows Phone, Lync, Dynamics CRM, and more….

 Freebies:

 

http://blogs.msdn.com/b/mssmallbiz/archive/2012/07/30/another-large-collection-of-free-microsoft-ebooks-and-resource-kits-for-you-including-sharepoint-2013-office-2013-office-365-duet-2-0-azure-cloud-windows-phone-lync-dynamics-crm-and-more.aspx

The Trouble with Saving a Site as a Template, Office 365 Tricks

Oh how temperamental SharePoint can beat times. Here’s a quick tip.

Lets say you have a neat little Office 365 site collection you have customised, without activating publishing features, you have added some free third party apps from the SharePoint store, say the twitter app or something similar. Then you want to save this as a template, and you go to the usual site settings location and the beast isn’t there, and it was there the other day.

To troubleshoot, you will probably first remove as many customisations as you can, I’d recommend starting with the twitter app. Some third party apps cannot be saved in template, and good ol’ SharePoint doesn’t exactly tell us why we can’t do certain things. So you’ve removed the twitter app, but still the link is not available. Don’t go and reset everything without checking the site options parameter in SharePoint Designer.

The site has a parameter SaveSiteAsATemplateEnabled that is set to true until you do something (adding the twitter app) to make it switch to false. When you remove the twitter app, you would expect the paramater to change back to true. Wrong! It doesn’t automatically do this.

Open the site in SharePoint Designer, in the home page, Click on “Site Options”, you will get prompt, In the “Parameters”  Tab, you can find “SaveSiteAsTempalteEnabled”, set it to true.

 

Apply your change and refresh the site. You will be able to see the link to save the site as a template. If you still cannot save it as a template, the error message might be a little more informative as to why. Just remove the other offending items and check the parameter, and go for it again.

This is your captain speaking…Over and out

Using A SharePoint Designer 2010 Workflow to export an excel sheet into a sharePoint List

In SP 2010 there is an option to create a list from importing an excel sheet. I have a requirement to automate this process but I was not sure how to start or even if my proposed solution is the correct fit.

I have a sql database which dumps 2 excel sheets into a file location every night, with graded sales stock data and quantities. The data in the excel sheets changes every night as new stock is made ready for purchase. This excel sheet is manually copied and edited into an html editor and copied into an html page with the data for display on a website. This data allows users to see what graded stock is available for purchase. The main requirement is to automate this process with minimal human effort and store the table of information in a list in a SharePoint 2010 Intranet site.The fields of the excel sheet are item number, description, quantity and price.

My initial thoughts are to have the 2 files dumped into 2 seperate document libraries and then have workflows initiate to ‘export’ the contents into 2 seperate lists (One for each file) which will be written over everytime a new file is added to the libraries. there are no workflow actions out of the box to export an excel sheet to a sharepoint list. The reason I would like to use a list to display the data is so that I can create an order form in InfoPath to allow users to order items from the list of stock, which would involve the quantities being reduced everytime and order is submitted.

Perhaps there is a way to directly dump the excel file into a SharePoint list and negate the need for a document library inbetween?

I am using SharePoint Designer for my workflows due to time constraints and My Intranet is SharePoint 2010, I posted this to a Microsoft forum and this was my reply:

SharePoint Designer workflow can’t work here, because SharePoint workflow can start manually or a change occurs in SharePoint list/library automatically, but Excel data changes can’t start the workflow. So instead, we can create a custom timer job and set it start daily to import data from the excel file.

Here is a blog about creating custom timer job.
http://dotnetfinder.wordpress.com/2010/07/24/creatingcustomsharepointtimerjob2010/

Then we need to read data from excel file and import them to SharePoint list in the custom timer job. We can use the code from codeplex.
http://spreadsheet2splist.codeplex.com/
http://spreadsheet2splist.codeplex.com/SourceControl/changeset/view/25678#418495

I will be blogging about my experience with working with custom timer jobs to fulfil this request!

Catch 22 with SPD workflow and checking in documents

I recently had to build a workflow in SharePoint Designer to model a fairly lengthy approval process for policy documents involving multiple stages of review, each of which has to be passed before the draft document moves to the next review stage. The workflow itself was quite long but essentially boiled down to a series of repeated steps. Each step involved assigning a task to a reviewer (or reviewers) and then updating the status of the document to show what stage it was at. The Policies document library has enforced check in/out, version control, and content approval all turned on. I also needed a field called Review Stage to show what stage the document was at – that was a simple choice field with 7 different stages.

Version History

The obvious thing was to add the Review Stage field to the document library.  After some playing around with the workflow, however, I decided to do things a more complex way.  I created a new list called Document Review Stages with two fields, one was the choice field Review Stage and the other was a number field called DocumentID.  For each policy document in the document library, there is a corresponding entry in the Policy Review Stages list.  The DocumentID holds the ID (the built-in column that SharePoint populates automatically) of the policy document.  In other words, I effectively created a one-to-one relationship between the Policies document library and the Policy Review Stages list.  Of course, this being SharePoint and not a full-blown database, this isn’t a proper relationship – there’s no enforced referential integrity, no cascading updates, etc.  But the basic principle is the same.

So why did I do it in this convoluted way?  Well because the Policies document library has enforced check-in/out and major/minor version control.  So suppose I had the Review Stage column on the Policies document library itself.  That would mean any change to the document, even just changing its metadata, would create a new version.   And that means that the workflow, if it wants to progress the document to the next review stage, would have to first check out the document, then set the Review Stage field, then check the document back in again.  And you’d then have 2 versions of that document, both exactly the same in content, but with different Review Stage metadata values.  This would result in a confusing version history for each document, with some genuinely different versions of the document (edited by different reviewers) but also many identical copies of each document created automatically by the workflow as it moves the document through the review stages.  By moving the  Review Stage column to a different list, the workflow can update the Review Stage field without creating a fresh copy of the document in the version history. That makes the version history much cleaner and more readable.

Approval Catch-22

This being a SharePoint Designer workflow, not a Visual Studio one, I had to attach it to the Policies document library.  I got the workflow to find the Policy Review Stages list item related to its corresponding policy document, and update the Review Stage column on the list.  So far so good, but then right at the end of the workflow, the last step was to make the document go live by setting its approval status to be “Approved”.  There’s a special workflow action to do just that, so it seems easy enough.  But there’s a catch.  If you want to make the document Approved status, you have to change it, and the workflow complains if you try to change it without first checking it out.  OK, so you change your workflow to check the document out first, and then approve it.  But now the workflow complains because you can’t approve a document that is checked out.  Catch-22!

So how do you get round this?  Well you can use the Start Another Workflow action to start the normal Approval workflow on the document.  The built-in Approval workflow can work with a document that’s not checked out.  So you end your workflow early, before the final approval task is allocated, and hand off control to a standard Approval workflow to manage the final approval step.