Building Traditional SharePoint Collaboration Solutions with the App Model

The SharePoint store on the Office 365 preview is slowly filling with apps. To date the one thing all of the apps have in common is that none of them resemble the sort of traditional SharePoint collaboration solutions that I believe constitute a large majority of the solutions people build in-house. By ‘resemble’ I do not mean look and feel but rather functionality.

Traditional collaboration solutions

SharePoint has a huge number of features and people use it for all sorts of things, but the sweet spot has long been solutions that take the basic components of a Team site and apply them to solving specific business scenarios. Such solutions are made up of business specific content types, lists, libraries, and event handlers or workflow. They often involve branding and custom UI components, but the bulk of the functionality usually comes from SharePoint and much of the code (both declarative and procedural) in a given solution is devoted to configuring the site as opposed to creating truly custom components.

SharePoint is an attractive platform for a wide range of applications because it contains so much configurable functionality right out of the box. Skilled implementers can do some amazing things in a very short amount of time compared to traditional start-from-scratch development. The deep integration with Microsoft Office, especially with Outlook, makes it possible to easily integrate shared functionality delivered via the web with the desktop productivity applications business people use all day, every day.

None of the current marketplace apps make extensive use of these building blocks. Instead most of them add complimentary functionality, as is the case with the Nintex Workflow app, or integrate with some external service like HP ePrint.

App Web Confusion

When SharePoint 2010 was in beta I built a non-trivial sandbox solution to find out how well the sandbox model works. I am now in the process of doing the same thing with the new app model. I had a very hard time at the beginning because I was focused on the App Web as the location of my functionality. An App Web is a special web intended to host all or part of an app. However, an App Web is very special and it lacks most of the building blocks needed for a traditional solution including:

  • Navigation
  • User and group management
  • Rich client support
  • Site settings

It seems that an App Web is a good option for completely custom solutions like Nintex Workflow, to host App Parts like the Bamboo World Clock and Weather part, or as a landing page with instructions or configuration tools, but for a traditional solution it is completely inadequate. After flailing about for a significant amount of time I came to understand that a traditional solution requires the use of the host web, not the App Web.

Using the Host Web

A host web is a regular SharePoint site where the application is installed. Any regular SharePoint site can be a host web. An App can specify that it needs significant permissions to the user’s host web up to full control.

But there is a problem.

Although an App can contain features in a wsp (web solution package) file, the solution package and features are applied not to the host web, but to the App web. The only declarative features you can apply to the host web via an App are CustomAction and ClientWebPart. These allow you to add functionality to a site’s menus and to add App Parts, respectively. The implication of this is that to use the host web effectively you can’t use features but must use one of the client side API’s to do provisioning, CSOM, JSOM, or REST.

Living without Features

For my App I decided to use C# and CSOM for the provisioning code, but I was very skeptical that the client side object model contained enough functionality to do the job. I was pleasantly surprised to discover that it was. I am able to provision and configure fields, content types, lists, and pages with Web Parts. The only real issue I had was that you can’t specify a content type ID when you create a new content type.

I am even more surprised to tell you that I prefer this approach over CAML and that I find it to be more flexible. I built a generalized framework to provision these elements which will be the subject of further posts, and I greatly appreciated being able to add tracing and logging to the process. It made debugging much easier. I believe that I wound up with more code than I would have using XML, but not much more. I also appreciate the fact that should the App Web become an option, I will be able to simply change the target web and my code will still work.

On the other hand, I did have to a lot of work to move from features to code. Fortunately I can reuse the code so future projects will be fairly painless.

About the only thing my App lacks is workflow, but the Nintex Workflow App clearly demonstrates that the API’s are there.

Remote Event Receivers don’t Work in the Preview

…at least if they do I haven’t ever seen it. In the meantime I just have a "Provision" button on a page in a provider hosted site configured for high-trust. In my App the list forms are custom and so I have been able to live without event receivers – I can do the work on submission of the forms. However, for many potential applications this will be a major issue. If it is I suggest you simply wait until the next code drop before you try to implement anything where you simply must have event handlers.

Is it better than Sandbox?

Based on my experience thus far it’s no contest. The App model is far more flexible. The client API’s are larger and more complete than the sandbox object model and the ability to do work at a higher level of permissions than those possessed by the current user enables many more scenarios.

Is it better than Farm?

I don’t know yet, but if you are currently restricted to a sandbox model or do extensive sandbox development you might want to change simply to minimize the number of skills you have to maintain across your team. The downside is that the architecture is more complicated and has more moving parts.

Is this Approach Valid for the Office 365 Marketplace?

At the moment there is nothing explicit in the guidelines that prohibits this approach. At the same time, I doubt they want users to party on the host web and I doubt Microsoft will approve an App that does this. However, both Office 365 and on-premises installations support side-installs to support just this sort of scenario by requiring an administrator to enable the App. Regardless, most Apps of this nature won’t be built for public sale anyway.


Author: Doug Ware