SharePoint Dragons

It’s a remarkable move that InfoPath forms are no longer used in workflows. InfoPath in combination with Forms Services is a great platform that makes it quite easy to create robust and nice looking web forms. We’ve found that one of the places where InfoPath really shines was within SharePoint workflows. InfoPath forms are rendered to HTML by Forms Services, running as a service within your SharePoint farm. To us, this is just another example of the clear trend where Microsoft tries to move custom code outside of your SharePoint environment.

Loops have been a much requested feature for SharePoint Designer that has been added in v2013. We have seen lots of developers and power users asking for it. In SharePoint 2010, workflow Loops where only available in Visual Studio 2010 as it was considered too dangerous to hand the power of Loops and its possible disastrous side-effects to power users. One misconstrued infinite loop in a custom workflow could have a definite impact on SharePoint farm performance. Now, since SharePoint 2013 workflows run outside the SharePoint farm (in Windows Azure Workflow, WAW), such risks are considered to be acceptable. As a side note and recurring trend: again the SharePoint 2013 platform does its best to take all code out of the farm.

As a successor of the popular SharePoint 2010 Best Practices TechNet Wiki page ( http://social.technet.microsoft.com/wiki/contents/articles/8666.sharepoint-2010-best-practices.aspx ), we’ve slowly started accumulating links for its successor, the SharePoint 20103 Best Practices TechNet Wiki Overview page. It can be found at http://social.technet.microsoft.com/wiki/contents/articles/12438.sharepoint-2013-best-practices.aspx#Development and can use some love!

There are a lot of different options when it comes to communicating with SharePoint. Here’s some advice when to use them when building Apps:

• Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server separated by a firewall benefit most from using the JavaScript client object model.
• Server-side code in Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server but not separated by a firewall mainly benefit from using the .managed client object model, but the Silverlight client object model, JavaScript client object model or REST are also options.
• Apps hosted on non-Microsoft technology (such as members of the LAMP stack) will need to use REST.
• Windows phone apps need to use the mobile client object model.
• If an App contains a Silverlight application, it should use the Silverlight client object model.
• Office Apps that also work with SharePoint need to use the JavaScript client object model.

See http://msdn.microsoft.com/en-us/library/jj164060(v=office.15).aspx for more general guidelines concerning client API choices and solution development.

Keep track of newer insights at TechNet Wiki page http://social.technet.microsoft.com/wiki/contents/articles/13637.sharepoint-2013-best-practices-what-client-api-should-you-choose-when-building-apps.aspx

The mantra of SharePoint 2013 seems to be: “Must get all the evil custom code out of SharePoint” (whether that will be workflows, InfoPath, or farm solutions). Is it just us or is the new best practice of creating Apps for SharePoint 2013 leading to a big mess of so-called “client-side pattern” cum “spaghetti” code? At this point, it feels as if MS is catapulting SharePoint devs back into a time where JavaScript was the main tool of the trade (or, as is suggested here, you should build business logic using client-side JavaScript: http://msdn.microsoft.com/en-us/library/office/apps/fp179889(v=office.15)). It seems that in one or two new versions of SharePoint from now we all will be saying: “of course this old development style lead to all kinds of problems and messy code, luckily now we have a development environment that fully supports OO client-side development”… Anyway, this Wiki page contains a link to some of the emerging design patterns for Apps for SharePoint 2013: http://social.technet.microsoft.com/wiki/contents/articles/12438.sharepoint-2013-best-practices.aspx