Quantcast
Channel: SharePoint Config
Viewing all articles
Browse latest Browse all 18

Developing for SharePoint Online

$
0
0

On Saturday the 12th of November I presented a session on “Developing for SharePoint Online” at the second SharePoint Saturday in the UK. The session was aimed at SharePoint developers who had no or little experience building solutions to run in SharePoint Online which is part of Office 365. I’ve included the slides at the end of this post but if you didn’t make it the key points are summarised below.

SharePoint Online Flavours

SharePoint Online is part of Office 365 which has two broad offerings; the Office 365 public cloud and Office 365 dedicated.

As the name suggests the public cloud is a shared environment so other people will be using the same servers to run their SharePoint sites. To ensure one customer doesn’t affect another customer on the same server Microsoft has had to impose many significant restrictions. For example you can’t deploy files to the file system as this could overwrite files from another customer. This was also a driving force behind sandboxed solutions – a restricted set of allowed customisations that Microsoft can guarantee won’t affect other customers in a shared environment.

There are several different licencing models for the Office 365 public cloud. The main offerings are:

  • Professionals and small businesses (P plans) – these are limited to 50 users and a single site collection. There are also less features available and there is no supported upgrade to the enterprise plans (E plans).
  • Medium businesses and enterprises (E plans) – these allow 300 (non-my site) site collections containing 100GB of content each. The enterprise plans also include my sites and cross-site collection search. For more details have a look at the Microsoft SharePoint Online for Enterprises Service Description.

Office 365 dedicated is aimed at 30,000+ seat deployments so unless you have a large user base this isn’t going to be an option as Microsoft will only start discussing this if you have a deployment of this size. As you are the only customer using the servers, however, you are able to deploy full trust solutions in SharePoint Online dedicated although these still need to go through Microsoft approval process before they can be deployed to the servers. The rest of this article will focus on the features and limitations of the public cloud.

Screen shots of the administration panel for the P and E plans are shown below. Note the complete lack of farm level configuration in the P plans:

P1 Administration screen (note the ‘Manage team sites’ simply takes you to the team site settings page).

p1-admin

E3 Administration screen (note the SharePoint Online | Manage link takes you to the following additional admin screen)

e3-admin

E3 SharePoint Administration Screen

e3-sharepoint-admin

E3 SharePoint Site Collection Administration – note the resource and storage quotas. Sandbox solutions are limited to consuming the available resources in the quota – if these are used up all sandbox solutions stop running.

e3-sharepoint-site-collection-admin

What’s In

A broad summary of the features available in SharePoint Online is included below. More details can be found in the Microsoft SharePoint Online for Enterprises Service Description.

  • My Sites
  • Office Integration (2007/2010)
  • SharePoint Workspace 2010 for Offline Working
  • External Sharing
  • Simple Public-Facing Website
  • Document Libraries
  • Slide & Media Libraries
  • Business Taxonomies & Tagging
  • Document Sets & ID’s
  • Office Web Apps
  • Cross-site Collection Search
  • Search Refiners
  • Indexing Controls
  • People Search
  • Phonetic Search
  • Excel Services
  • Access Services
  • Visio Services
  • SharePoint Web Services
  • Forms Services
  • Custom Web Parts
  • Silverlight controls
  • Sandboxed Solutions
  • Blogs
  • Wikis
  • Business Connectivity Services

As you can see there are a large number of features, and Microsoft is continuing to add to this by adding features. For example support for Business Connectivity Services and the Secure Store Service was added during October and November this year. If you need to extend these capabilities then sandboxed solutions can be used.

What’s Out

At the time of writing the following features were unavailable.

  • Records Center
  • Information Rights Management (IRM)
  • SharePoint for Internet Sites and WCM workflow and approval
  • Site Variations
  • PerformancePoint Services
  • Power Pivot
  • Full-Trust Code Solutions
  • FAST Search

Development Options

There are several options for developing custom solutions for SharePoint Online. As with on-premise SharePoint deployments you can use the browser to create site columns, content types, lists, web pages and other artefacts. You can also use SharePoint designer and InfoPath to create custom workflows, enhance list forms and provide similar customisations as you can with an on-premise deployment.

If you need to write code to provide functionality such as an event receiver or a web part then you can use sandboxed solutions to create and deploy managed code assemblies. If you need to provide functionality that isn’t supported in the sandbox such as timer jobs or service applications then one option is to host this logic in an external environment such as Windows Azure and interact with SharePoint online via the client object model and/or the SharePoint web services.

Key sandbox limitations

The sandbox model has some major restrictions on what is allowed. Some of the key limitations are:

  • No access to the file system
  • Code restrictions:
    • GAC deployment prohibited
    • Restricted set of allowed assemblies
  • No server side external calls
  • No Web Application or Farm scoped functionality
  • No full-trust proxy allowed in SP-O standard
When you deploy sandbox solutions they must be uploaded and activated on individual site collections through the browser. At the moment there is no way to automatically propagate a solution to multiple site collections at once. Another thing to note is that sandbox solutions have a resource quota that is used up when processor cycles, database queries and other resources are used. Expensive operations like throwing unhandled exceptions and long-running processes use these resources up quickly and will eventually lead to a solution being blocked if all resources are consumed.

Limitation #1 – No access to the file system

Without the ability to deploy files or interact with files on the file system this prevents you from using the following in SharePoint Online:

  • Site definitions – These require onet.xml and webtemp.xml files deployed to the SharePoint root directory so are not available. To work around this limitation you can use the WebTemplate element that is new in SharePoint 2010 (and often overlooked). To find out more check out Vesa’s great post on SharePoint 2010 and web templates.
  • User controls – Again these need to be deployed to the ControlTemplates folder in the file system. To get around this limitation you can install the Visual Studio 2010 SharePoint Power Tools as these include a Sandboxed Visual Web Part template that can be used to write a control (.ascx) file that is then compiled and deployed in your assembly, circumventing this limitation.
  • Application pages – Typically used for settings or admin pages but you cannot deploy to the _layouts virtual directory as this maps to the SharePoint root LAYOUTS folder so these cannot be used. A workaround for these is to create a site page and embed a web part on this page so it appears like an application page. Wictor Wilén has a good article on this at Custom application pages in the SharePoint 2010 Sandbox. Note when embedding your web part you need to use the SPUserCodeWebPart class rather than adding your web part directly to the page.
  • Branding resources – Often resources such as images and JavaScript files are deployed to the SharePoint root so these need to be deployed to a library such as the Style Library instead. Another thing to note is that all file including masterpages and page layouts provisioned via a feature are checked out when using Sandboxed Solutions. Waldek’s article Automatically publishing files provisioned with Sandboxed Solutions provides a solution for this.
  • Web.config – Without the ability to change the web.config file you are prevented from many things such as creating HttpModules, adding custom authentication providers, and changing the appsettings entries. Many of these cannot be avoided but for application settings you can still use the SPWeb property bag or a SharePoint list.
  • ULS logs – As you cannot write to or view entries in the ULS logs or Windows Event Logs debugging errors becomes a lot more difficult. When a web part or event handler errors in SharePoint Online there is no stack trace available and no log to check for details of what caused the error. One solution is to log to a SharePoint list and this is something I demonstrated in the SharePoint Saturday session. You need to be mindful of resource usage so the ability to switch logging on and off in production is useful here. I’ll include more details and an example solution in a later post.

Limitation #2 – Accessing external data

Code running in SharePoint online is restricted to the scope of the current site collection. You cannot make web services calls or create new SPSite objects for other site collections. Some options for interacting with external data are:

  • Use client side code – This could be in the form of a Silverlight application using the Client Object Model, JavaScript running in a browser using the ECMAScript client model or using the Managed client OM such as in an Office Add-in. Wictor has a interesting article on one example of how to do this in his article SharePoint Online and External Data using JSONP.
  • Business connectivity services – The BCS feature allows you to create external lists that render data from an external system so you could create a WCF service that exposes data in an external system and display this as a SharePoint list.
  • Data view web part – Another simple way of getting data in is to use SharePoint designer and the data view web part. This can be used to display an RSS feed on a SharePoint page, for example. Note that you cannot use this server side so its use is fairly limited.

Limitation #3 – Code restrictions

Some important points here are that you cannot deploy solutions to the GAC so your solutions do not have full trust. This prevents components such as custom workflow solutions and timer jobs from running. You also have a very restricted set of allowed assemblies and methods within those assemblies that can be called. For example the SPSecurity namespace is not allowed so you cannot run code under the application pool account as SPSecurity.RunWithElevatedPriviledges is not allowed. The Visual Studio SharePoint Power Tools mentioned earlier help you with this limitation by compiling sandbox solutions against the allowed set of assemblies so you can identify the available methods via intellisense and at will see errors if you use these at compile time.

Another key thing to note is that you do not have full access to the Page and HttpRequest objects. When the sandboxed code runs it is executed under the SPUCWorkerProcess not the W3Wp.exe process. The SPUCWorkerProcess only contains a copy of the Page and SPWeb objects so methods that Microsoft have not implemented such as Page.ClientScript or Response.Redirect will not work.

Some good articles on this topic are (again) by Wictor and Waldek:

The Sandboxed Solutions article on MSDN also has more in-depth coverage of some of these issues.

To get around some of these limitations one approach is to move your more complex application logic into an external system such as Windows Azure. The external system can then perform the procedures it needs to in a a fully trusted and fully featured environment. You might also want to store some of your data in an external system for compliance or cost reasons. Steve Fox has more information on this in his article Leveraging Windows Azure WCF Services to Connect BCS with SharePoint Online.

Limitation #4 – Deployment scope

Sandboxed solutions can only contains site collection or site/web scoped features. Additionally you don’t have full access to farm features such as search so there are features such as managed search properties that are not available in SharePoint Online. Other things that are unavailable are authentication providers and custom service applications. Again, for situations where you need to extend your SharePoint Online environment beyond the scope of the site collection you may want to consider moving this application logic elsewhere and/or consider a hybrid approach where some SharePoint content is online and some is on premise.

Resources

To find out more or get up and running I recommend using the following resources:

I also found the following books useful resources for understanding more about SharePoint online development.

Deploying Cloud-Based Microsoft SharePoint 2010 Solutions – good overview of Office 365. Doesn’t go into a lot of depth in terms of development but has a great high-level overview of Office 365, SharePoint Online, and high-level options for SharePoint online customisation and development.
Developing Microsoft® SharePoint® Applications Using Windows Azure- useful hands on guide to developing applications using Windows Azure and integrating these with SharePoint.

Professional SharePoint 2010 Cloud Based Solutions- I’ve haven’t read this yet as it has just been released but it appears to have lots of hands on development examples of how to integrate SharePoint with a variety of cloud services.
Lastly the slides from my SharePoint Saturday talk are below:

Developing for SharePoint Online is a post from: SharePoint Config


Viewing all articles
Browse latest Browse all 18

Latest Images

Trending Articles



Latest Images