Chapter 4

Introducing SharePoint Online

What’s in This Chapter:

• What is SharePoint Online?
• A brief technical overview of SharePoint Online
• Comparing SharePoint Online and SharePoint On-premises
• Developing for SharePoint Online

A discussion of a locally installable product such as SharePoint may seem out of place in a book on programming for the cloud. SharePoint has, after all, historically been an application that a company installed in its datacenter and managed itself. True, there have been various incarnations of hosted SharePoint, ranging from Microsoft’s massive Business Productivity Online Services (BPOS) instance to many smaller hosting or service companies providing instances of shared SharePoint. However, prior to the 2010 release, these shared instances have been largely static out-of-the-box installations with little support for custom development.

With the 2010 release of SharePoint, Microsoft changed this game entirely. One of the primary drivers for the changes introduced with SharePoint 2010 was a need for large scale multitenancy, that is, multiple companies coexisting within a single SharePoint farm. Another driver was support for enhanced options for customization via server-side code without breaking security or impacting performance across tenants.

This chapter provides an overview of SharePoint Online, mostly from a developer’s perspective, contrasting it with SharePoint on-premises. The goal is to help you to understand what is and is not possible in SharePoint Online.

SharePoint Online 101

SharePoint Online (SPO) is the evolution of the portal and collaboration aspects of Microsoft’s Business Productivity Online Services, bringing the hosted SharePoint portions of that offering into the 2010 product release, including most of the rich capabilities offered by the latest release of SharePoint. Much of SPO should be immediately familiar to anyone with some experience with SharePoint 2010. There are, however, some important items of which you must be aware.

The first point may be obvious but it bears mentioning—SPO is SharePoint. Many, if not most, end users would never know that they are interacting with a hosted service if they weren’t told. All the distinctions discussed in this chapter are technical details of interest only to those who peel back the covers and take a peek at what occurs underneath. End users could, and likely should, live their lives blissfully unaware of the messy technical details of multitenancy, Sandboxes, globally distributed datacenters, and so on. End users have a job to do that touch only upon the technical details of SPO tangentially. They need to create and collaborate on content, search for existing content, share content, and so on. They don’t care how those services are provided. They care only that they are provided.

SPO is an instance of SharePoint 2010 hosted in the cloud by Microsoft. Other hosting providers offer their own version of hosted SharePoint, and each differs depending on what features and functionality are made available and how the hosting company configures the environment. This book is concerned only with SPO. Although other hosting providers’ offerings are almost certainly similar—they are all SharePoint-based—there are important differences with which you must familiarize yourself if you want to operate effectively in other hosted SharePoint environments.

Any discussion of SPO must begin with a cursory review of the larger differences between it and its on-premises sibling that frames the rest of the conversation. You must understand the changes to the game board if you have any hope of following along. At a high level, SPO is SharePoint, except for the following:

• All server-side code runs in the Sandbox (see the next section “SharePoint Online—A Brief Technical Overview,” which discusses the Sandbox).
• Not all features of SharePoint are available (see the section “Licensing”).
• Central Administration is not available. Rather, in this multitenant version, you have access to “Tenant Administration.” a slimmed down, focused counterpart to Central Administration.
• Multiple companies (tenants) coexist on the same SharePoint farm.
• Each tenant is allocated one or more site collections, depending upon the plan purchased.
• The tenant has NO access to the underlying hardware or servers via any type of remote desktop or similar capability. In other words, all administrative or customization interaction with SPO happens via the browser or tools such as SharePoint Designer.

Other than those six things, SPO is effectively identical to an on-premises installation.

SharePoint Online—A Brief Technical Overview

Development in SPO is all about the Sandbox. This is the single most important aspect of SPO for developers to understand. The Sandbox has been mentioned a couple of times so far, so now let’s take a moment to ensure you understand it. In SharePoint 2010, the Sandbox is a controlled, monitored execution environment operating inside the SharePoint application. It is responsible for ensuring the security of content, as well as the stability and performance of the SharePoint farm. To say that code is “running in the Sandbox” means that this special execution environment manages the code’s execution to ensure that it does not perform actions that have been blocked, and that it doesn’t use too many server resources, such as processor time or memory, with the ultimate goal of ensuring that no single tenant can destabilize any other.

As part of this controlled execution model, SPO has a few important aspects:

• Deployment options: SPO supports only the Sandbox deployment model for custom solutions. You cannot deploy Farm solutions to SPO.
• Resource Monitoring: SPO tracks the work done by custom code and shuts it down if too much strain is placed on the server environment.
• Code Restrictions: SPO allows only programmatic access to those elements accessible from the Sandbox or via the client object model. For the most part, this means access to the site collection level and below. Web Application and Farm elements are not available in SPO via custom code, server-side or client-side. This also means there is no access to external components, such as remote WCF services, e-mail services, or similar external systems.
• Solution Validation: SPO layers additional validation requirements upon those enforced by the Sandbox.

Deployment Options

In SPO, unlike SharePoint on-premises, the only deployment option is the Sandbox. Farm solutions cannot be installed in SPO.

Resource Monitoring

The Sandbox environment tracks the number of cumulative total server resources used and can temporarily shut down to prevent poorly written or malicious code from consuming so many resources that they impact other tenants or the server. Table 4-1 shows the various resources that the Sandbox tracks as well as details on what each means and the cost of usage.

Table 4-1: Resources That the Sandbox Tracks

The easiest way to understand this table is with an example. If you have a web part on a page that requires 20 calls into the SharePoint database to deliver its content, this costs one “point” every time that page loads. If you have 50 people in your company and each person views that page twice per day, that page costs 100 points (1 point per page load × 50 people × 2 page loads per person).

By default, each Sandbox (that is, each site collection) has 300 “points” available before it shuts down and stops processing additional requests for Sandboxed solution items. This 300-point quota is configurable on a site collection-by-site collection basis through the SPO administration pages. When the Sandbox for a given site collection shuts down, users see the message shown in Figure 4-1 until either the next day (usage is reset at midnight, datacenter time, or an administrator increases the quota allocation for that site collection.

Code Restrictions

In addition to resource monitoring, the Sandbox also restricts access to elements in the SharePoint object model. Sandboxed Solutions are not allowed to access every object in the SharePoint server-side object model. Instead, they have access to the subset object model. The subset object model is just what the name implies—limited portions of the full server-side object model. While not an exhaustive list, some important items not in the subset object model include:

• The SPSite constructor
• SPSecurity
• SPWebApplication
• SPFarm

Solution Validation

In addition to the code restrictions previously covered, SPO implements validation logic when custom Sandboxed Solutions are activated. This logic prevents custom code deployed to SPO from accessing other resources that could present security or performance problems. For details on how to work within the scope of this additional validation logic, see the information on the FxCopRules project in the “Tooling” section later in this chapter.

Programmable Scope

As might be expected in a multitenant environment in which each tenant must be totally isolated from each other tenant, all custom code in SPO is restricted to accessing the current site collection. You cannot reach across site collection boundaries to access content, users, configuration details, and so on from another site collection. Furthermore, you cannot reach outside SPO, except through Business Connectivity Services. This restriction is enforced regardless of where the code executes—managed code in a Sandboxed Solution running on the server, JavaScript running in a client browser, managed code running in a Silverlight application on the client, managed code running in a .NET application on a client, or any code running anywhere using the REST APIs. While it’s true that some access mechanisms (notably the managed code client object model and the REST APIs) can access multiple site collections, they must authenticate with valid credentials to each site collection they connect to. They cannot hop from one site collection to another without authenticating. Because these approaches do not operate within the context of a site collection, they are not violating the site collection boundaries. For JavaScript code and Sandboxed Solutions, the site collection boundary is still paramount.

The end result of all these elements is allowing tenants to add server-side code to their custom solutions with no fear that it can impact or interact with the resources or content of another tenant in any way.

SharePoint Online Versus SharePoint On-premises

Looking at SPO more closely, the biggest benefit may not be immediately obvious. Quite simply, this is the effort required to set up servers, install the application, patch the application, create the farm, and all the other myriad of details required to build a SharePoint environment from scratch. When you use SPO, the time from when you decide to use the tool to the time users browse your SharePoint environment can be measured in hours or days, not weeks or months. Naturally, this is not always the case, and large-scale adoptions of SPO can involve a significant effort, especially if migration of existing content is involved. However, at a bare minimum, that effort does not need to include the establishment of a datacenter and the building out of a server infrastructure, which can often run into months of effort.

The rest of this section delves more deeply into some key differences between SPO and SharePoint on-premises.

Licensing

When installed in your (self-hosted or rented) datacenter, the functionality of SharePoint is governed by its license selection. The license choices:

• Foundation: The free core product. Provides basic SharePoint functionality for content creation, sharing, collaboration, and social interaction.
• Standard: Built on top of Foundation, it introduces additional functionality, such as enhanced Search and Social capabilities, content rating and tagging, managed metadata, and web analytics.
• Enterprise: The whole enchilada—all SharePoint functionality.

For a detailed breakdown of features and functionality by on-premises SKU, see the chart published at: http://sharepoint.microsoft.com/en-us/buy/Pages/Editions-Comparison.aspx.

Features and Functionality

The feature set of SPO is most closely analogous to the feature set of SharePoint Server Enterprise, with a few notable exceptions:

• Claims-based security: Available in all SKUs of SharePoint on-premises but not available in SPO
• Custom Timer jobs: Available in all SKUs of SharePoint on-premises but not available in SPO
• FAST Search: Available in SharePoint Server Enterprise but not available in SPO
• Secure Store Service: Available in SharePoint Server on-premises but not available in SPO
• Web Analytics: Available in SharePoint Server on-premises but not available in SPO
• PowerPivot for SharePoint: Available in SharePoint Server Enterprise on-premises but not available in SPO
• PerformancePoint Services: Available in SharePoint Server Enterprise on-premises but not available in SPO
• Specific enhancements to search, social, business intelligence, security, and so on: Available in SharePoint Server Enterprise on premises but not in SPO.

Cost

The cost for SPO is an obvious benefit for the bean-counters in the room. If you can fit your requirements into the capabilities of SPO, you can gain significant cost-savings.

SPO is a hosted service for which you pay a monthly fee per user. SharePoint on-premises is a per-server and per-user license-based model. The difference can be considerable. At the time of this writing, the per-user fee for SPO as part of the full Office 365 Suite can cost as little as $72 per user per year for typical small business functionality—e-mail, content sharing and collaboration, social networking, instant messaging, online meetings, and web-based versions of the Office client applications. For larger enterprises that need licenses for the desktop Office applications, enhanced capabilities for content sharing, collaboration, and so on as well as full phone system integration, the cost can go up as high as $264 per user per year—depending on which options you choose.

Contrast this with a typical on-premises installation that could cost tens of thousands of dollars in licensing and services to hundreds of thousands of dollars; the cost benefit of SPO is immediately apparent.

Availability

Related to cost is the question of availability. Highly available environments simply cost more to set up and maintain. Without insulting the IT Pros who maintain an on-premises environment, keeping an environment always-on is a difficult prospect, and most SharePoint environments do not come close to the availability of SPO. Microsoft guarantees 99.9 percent uptime for Office 365 with financially backed service agreements. This means that if it does not meet that agreement, you get a credit against future billing; 99.9 percent availability translates to just under 9 hours per year (or 1 minute, 26 seconds per day) of down time. Although initially that may seem like a lot, realize that this includes scheduled downtime for patches and updates, which are typically scheduled for off-hours to minimize the impact on users.

IT Professional Requirements

Maintaining a SharePoint environment on-premises is not a feat to be undertaken lightly. There are a LOT of moving parts—Windows Server, SQL, IIS, Active Directory, antivirus software, firewalls, monitoring, SharePoint, and so on. To maintain the environment, all the components that make up a SharePoint environment require resources from a variety of disciplines to work in concert.

Maintaining an SPO environment is almost a nonevent. For smaller businesses there are no requirements for these types of resources—it is all handled by Microsoft. For larger enterprises the need might be there, but it is greatly reduced to just maintaining connectivity and interactions between on-premises services and SPO as required by your particular usage scenario.

Administrative Requirements

The day-to day administrative tasks to manage users, security, lists/libraries, and so on are not significantly different between SPO and SharePoint on-premises. In either environment, site collection administrators use the same (or similar) web pages to perform their tasks. These can range from adding users to security groups to controlling resource access to creating and managing lists and libraries. There are some minor differences in screens and steps between the two environments but nothing significant.

Developer Requirements

Although identifying the exact skills necessary to be an effective SharePoint developer is a highly subjective exercise, any list would likely include the following:

• Managed code—either C# or VB.NET
• ASP.NET
• JavaScript
• The SharePoint server-side object model
• CAML
• SharePoint administration (yes, even for a developer)
• Web services
• The SharePoint client-side object model (managed code, Silverlight, and JavaScript)
• REST

Depending on your environment and the task at hand, you’ll use some of those more than others.

When you move into SPO development, however, your skill level in most of those areas needs to improve. For example, it is far more likely that you need to use JavaScript in SPO development than in SharePoint on-premises development because resource restrictions are in place as part of the Sandbox. JavaScript does not count against your resource quotas. Therefore, you’ll to need to upgrade basic JavaScript skills to more advanced skills.

Similarly, you must write efficient, managed code in an SPO environment because every line of custom server-side code that executes counts against your resource quota. A deeper understanding of how your custom managed code operates and how to make it as efficient as possible is likely the most important aspect in becoming an effective SPO developer. Tweaking your CAML query to be as efficient as possible, returning only the necessary rows and columns and nothing else is more important than ever before. Understanding the importance of efficient looping, proper disposal of objects, minimizing processing time and bandwidth all come to the forefront of what it means to be an SPO developer. Although not technically correct, it was often possible to get away with somewhat sloppy code and processing when your code had the full horsepower of the servers available to it and direct access for an administrator to clean up any fallout. As covered in the previous section, this is no longer true, and every processor cycle you waste or every byte of additional RAM you consume is counted against you—use too much and you run into trouble.

Finally, you must be far more familiar with the features and functionality of native SharePoint to know the most efficient way to meet a business requirement. Sometimes fulfilling a requirement means a unique combination of out-of-the-box capabilities augmented with a smattering of custom server- or client-side code. SharePoint, even SPO, gives you an amazing toolkit with which to build your application, and knowing everything in that toolkit is more important than ever when you operate in a resource-controlled environment such as SPO.

In addition to enhancing your overall developer skills, a few new skills are necessary to be an effective SPO developer:

• Load/performance testing and tuning: The aforementioned resource restrictions of the Sandbox make it far more important that your code is as optimized as possible to avoid potential problems. The only way to validate this is to test for it.
• JavaScript: This was mentioned previously but bears repeating. By its nature, SPO lends toward more client-side development. In practice, this is doubly true. You’re almost certainly going to do more JavaScript coding in SPO than in SharePoint on-premises. Period. Just accept it. This likely means that you must be comfortable with native JavaScript as well as one of several popular extension libraries—JQuery, MooTools, Dojo, and so on. JQuery is currently the market leader de jour, but is by no means the only option.
• SharePoint Designer: Often seen as the bane of a SharePoint developer’s existence, SPD is no longer a tool that can safely be ignored, relegated to an “end user tool.” For a variety of reasons, SPD is more often going to be the right answer to get SharePoint to do what you need in SPO. Whether this is workflows, DataView web parts, or another SPD capability, it plays a role in your solution. The trick is maintaining good application development discipline while still taking advantage of what SPD has to offer, but that’s a discussion for another time.

Developing for SharePoint Online

Other than the things mentioned previously, writing code for SPO is identical to writing code for any other SharePoint 2010 installation. Solutions still consist of Features; Features are deployed in WSPs, and Features consist of declarative and programmatic elements to define Lists, web parts, workflows, and branding.

Capabilities

This is not to say that everything that can be built in SharePoint can be built for SPO. There are still some restrictions around the actual artifacts available for SPO. For SPO deployment, the Solutions are limited to the following:

• List Definitions and Instances
• WebTemplate Feature elements
• Site Columns and Content Types
• Modules
• Feature Receivers
• Web Parts
• Event Receivers (item, list, and Web receivers)
• Custom Actions
• Declarative workflows

Each of these elements can be deployed to a specific site collection and will execute within the confines of that boundary.

Tooling

As might be expected, the primary tool for SPO development is the same as the primary tool for SharePoint on-premises development: Visual Studio. In addition, SharePoint Designer plays a larger role in SPO development than it typically does in SharePoint on-premises development. Finally, there are several additional tools, some of which are also useful for SharePoint on-premises, which are particularly useful for SPO development. The following sections discuss these tools.

Fiddler

Fiddler (or a similar HTTP inspector) enables you to inspect browser requests sent to SPO (or any website, it is not SPO-specific) at a low level to get a better understanding of what is happening in your application. Fiddler is freeware. Detailed help on using Fiddler is available on its website (www.fiddler2.com).

FXCop Rules for Office 365

You can find this at www.fxcoprules.codeplex.com. This tool is a code analysis plug-in for Visual Studio that can help you use only those aspects of the SharePoint object model enabled in SPO. As of October 2011, the following items are checked by this tool.:

Assembly References

Referencing the following assemblies is not allowed:

• Microsoft.AnalysisServices
• Microsoft.BusinessData
• Microsoft.Office.Excel.Server.Udf
• Microsoft.Office.SecureStoreService
• Microsoft.Office.SecureStoreService.Server.Security
• Microsoft.Office.Server
• Microsoft.Office.Server.Diagnostics
• Microsoft.Office.Server.Search
• Microsoft.Office.Server.UserProfiles
• Microsoft.SharePoint.Portal
• Microsoft.SharePoint.Publishing
• Microsoft.SharePoint.Search
• Microsoft.SharePoint.Search.Extended.Administration.Common
• Microsoft.SharePoint.Search.Extended.Administration.dll
• Microsoft.SharePoint.Search.Extended.Administration.ResourceStorage.dll
• Microsoft.SharePoint.SubsetProxy.dll
• Microsoft.SqlServer
• Microsoft.Win32
• System.Data.Sql
• System.Data.SqlClient
• System.Data.SqlTypes
• System.IO.Pipes
• System.IO.Ports
• System.Runtime.Remoting

Method Calls

Calling any of the following is not allowed:

• System.Array.CreateInstance (System.Type, System.Int32)
• System.Type.GetType
• System.Type.InvokeMember
• System.Threading.Monitor.Enter
• System.Threading.Monitor.Exit
• System.Threading.Interlocked.CompareExchange
• System.Threading.Thread.get_CurrentThread
• System.Threading.Thread.get_ManagedThreadId
• System.Reflection.FieldInfo.GetFieldFromHandle
• System.Reflection.MethodBase.GetMethodFromHandle
• System.Reflection.FieldInfo.GetValue
• System.Reflection.ConstructorInfo
• System.Reflection.MemberInfo.get_Name
• System.Reflection.MemberInfo.GetCustomAttributes
• System.Reflection.PropertyInfo.get_PropertyType
• System.Reflection.PropertyInfo.GetValue
• System.Reflection.PropertyInfo.SetValue
• System.Reflection.MethodInfo

Object Creation

Creating any objects whose full class name begins with the following is not allowed:

• Microsoft.SqlServer
• Microsoft.Win32
• System.Data.Sql
• System.Data.SqlClient
• System.Data.SqlTypes
• System.IO.Pipes
• System.IO.Ports
• System.Runtime.Remoting
• System.Threading
• System.Reflection

Miscellaneous

The following other rules are enforced as well:

• Including a finalizer is not allowed.

JavaScript Debugger

The IE Developer Tools (included with Internet Explorer), Firebug (www.getfirebug.com), or a similar JavaScript debugger tool enables you to work much more closely with your JavaScript code. With the enhanced focus on JavaScript development, these tools enable you to debug, test, and work more closely with your JavaScript code in the client browser.

Summary

SPO is an exciting new opportunity for SharePoint developers to flex their development muscles and offer new solutions to business problems. This chapter provided an overview of SPO ranging from available features and functionality to an introduction to the controlled and monitored execution model of SPO development. If you want to dive further into SPO, read on. Chapter 5 gives you more detail.