SharePoint Dragons

It certainly seems to be true that the tone of voice in SharePoint 2013 is pretty upbeat, not only when compared with previous versions, but in general. Already, the “working on it” feedback you get when SharePoint is busy has become something of a catch phrase amongst SharePoint devs and admins. It’s a great thing, whenever someone comes up to you and asks you’ve finished something, you can just look up and reply: working on it!

We’ve witnessed another nice example of this upbeat tone when we finished completing toe configuration of the App environment which allows end users to install SharePoint Store Apps, see http://technet.microsoft.com/en-us/library/fp161236(v=office.15) if you want to know how to do that.

Of course, after configuring the App environment, we immediately tried to install one of the SharePoint Store Apps and this is what we got: “Everything is fine, but we had a small problem getting your license. Please go back to the SharePoint Store to get this app again and you won’t be charged for it.”

We appreciate the positivity of the message, but in fact things are not fine and this problem doesn’t get away over time. The message probably means you’re trying to add Apps using the SharePoint System Account, which we found out is not allowed by design as importing App licenses under this account could lead to performance problems (we’re wondering why?) as stated at http://technet.microsoft.com/en-us/library/fp161231(v=office.15).aspx .

So instead, you need to use a regular user account to install Apps. It’s not as easy to sign in as a different user account as it used to be. In SharePoint 2013, the quick shortcut Sign in as Different User is missing, so one thing you can do is go to Start > click Shift + Internet Explorer and choose Run as Different User to run the browser in a different user context. We found that that’s not even enough, because now the SharePoint Store has trouble detecting language settings, so you need to actually log in as a different user. After that, adding Apps from the SharePoint Store should work fine.

Interesting App gotcha: when Apps run under the App Only App Authorization Policy they run under the special SHAREPOINT\APP account. This only works for OAuth authenticated calls, and doesn’t work for some APIs that require the presence of a user context, such as the Search API.

We feel that most people would agree that the introduction of the SharePoint 2013 App model is the biggest architectural change in SharePoint 2013. We feel it’s a logical step and we have faith that eventually the App model will turn out fine, but we have our doubts how the APP model will work out initially. For now, these seem to be the biggest drawbacks of the App model:

• Apps can leverage a basic stylesheet of the referring SharePoint site, but for sure until so far the UI integration between Apps and SharePoint doesn’t look seamless at all. The Apps that are available right now from the SharePoint App Store seem to be struggling with this a lot. This is going to be a huge pain point, customers will expect integration to look naturally and for now it’s a big question mark if the tools provided to App developers allow them to deliver.
• Apps will need to rely heavily on JavaScript and asynchronous REST API calls/client OM calls to interact with the associated SharePoint context. Apps mostly built using JavaScript: we fear the code will become a huge spaghetti mess.
• Sahil Malik brings up an interesting point in http://www.dotnetrocks.com/default.aspx?showNum=794 , although App/SharePoint communication leverages OAuth, will it be safe? Sahil raises some serious doubts concerning the current implementation, and expects the burden of providing a secure solution will be placed on the shoulders of every App developer.
• After a SharePoint App has successfully obtained Full permissions, in principle there is nothing from stopping a vendor from modifying that web application to do something different (and evil?).
• The new App model brings a lot more cross-server communication with it. Will this impact the performance noticeably, will Apps be perceived as sluggish?

Andrew Connell has written this great blog post about doing advanced workflow debugging in SharePoint 2013 by leveraging the free HTTP traffic monitoring tool Fiddler. Using an HTTP monitoring tool for workflow debugging purposes makes a lot of sense for two reasons:

• SharePoint 2013 leverages Windows Azure Workflow (WAW) to provide SharePoint 2013 workflows. Both components communicate via HTTPS/SSL.
• SharePoint 2013 workflows are declarative and don’t allow developers to add custom code. Instead, developers have to either create custom actions or use the new HTTP workflow activities to call custom WCF services.

Because of these two reasons, the amount of HTTP traffic that happens under water when executing workflows increases dramatically. Hence, Fiddler becomes a useful workflow debugging tool. Check out the good stuff at: http://www.andrewconnell.com/blog/archive/2012/07/18/sharepoint-2013-workflow-advanced-workflow-debugging-with-fiddler.aspx.

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

Without getting into much detail,  there are several host models for Apps in SharePoint 2013, namely:

• No-hosted
• SharePoint-hosted
• Provider-hosted

Again, without getting into details, provider-hosted Apps can be hosted on dedicated application servers or in the cloud (Azure). We want to take a moment to reflect on the provider-hosted Apps on dedicated application servers… Those Apps are stand-alone applications that run completely outside of your SharePoint farm, and SharePoint is completely technology-agnostic as far as these Apps go. This means, Apps can be hosted on application servers running, for instance, using any technology on the LAMP stack (Linux, Apache, MySQL, and PHP).

This particular feature was hailed enthusiastically by lots of SharePoint bloggers. We don’t share the sentiment. Although in itself it’s great to have the flexibility to use any flavor of application server you like, in reality we’ve found that this type of platform independence is almost never an issue (Roger Sessions once did some, unscientific, research about it, wrote about it, and found that this is a factor in less than 1% of the IT projects). If you’re an avid Java or PHP developer planning to build Apps, you’ll find that you still have to have intimate knowledge of SharePoint technology and development models. What’s more, developing these types of solutions will be a lot easier using the Microsoft dev tools. We’re convinced that the share of skilled Java and SharePoint developers is pretty limited and we’re betting it’ll stay that way for times to come. In addition, some SharePoint bloggers have even predicted the end of the era of SharePoint developers, since now every ASP.NET developer will be able to create Apps as well. We think this is nothing more than a wrong conclusion, for exactly the same reasons. If you want to develop SharePoint solutions in the form of Apps, you need the knowledge about the platform. You simply can’t do that while you’re avoiding becoming a “SharePoint” developer.

Your thoughts?