C H A P T E R  2

SharePoint Online Development Overview

There are many who mistakenly believe that Office 365 heralds the end of custom development because of its limitations. Nothing could be farther from the truth. In this chapter, we will take a look at how the rules of development have changed with the advent of Office 365. Although you will need to learn new ways to do things, customizing and extending SharePoint through development will still be an integral part of what companies want to do with SharePoint Online.

Okay, let’s get started. In this chapter we will cover the following topics:

• The different approaches and tools available
• Limitations that apply to development and customization
• Customizations available in the browser
• Using SharePoint Designer 2010 (SPD)
• Creating custom code with Visual Studio 2010

Three Customization Approaches

There are three basic toolsets available when customizing SharePoint Online. First, you can use the web browser to change configuration and customize elements in SharePoint. After you’ve reached the limit of what is available in the browser you can apply additional customizations to individual sites using SharePoint Designer 2010. If you want to make changes that affect the entire site collection, you will inevitably turn to writing custom code using Visual Studio 2010.

Customization Through the Browser

Customizing SharePoint Online using only the browser is the easiest and most convenient way to modify how SharePoint Online looks and operates. You can make significant changes in both the look and feel of a site and the functionality available using only a web browser. Possible customizations include, but are not limited to, the following:

• Changing the site title, description, or icon
• Modifying top-level or quick-launch navigation
• Applying themes to change the look and feel
• Creating site columns and content types for storing different kinds of content
• Adding functionality by activating existing site collection or site-level features
• Configuring shared services applications provided in SharePoint Online
• Adding a Content Editor Web Part to embed client-side code (JavaScript/jQuery) on a page

The focus for making most of these changes will be the links found on the Site Settings page shown in Figure 2-1. Site collection administrators and site owners can reach this screen through the Site Actions menu.

Figure 2-1 The Site Settings page in a SharePoint Online site

SharePoint Online also includes a subset of the shared service applications available in an on-premise installation. These services include the following:

• InfoPath forms service
• User profile service
• Managed metadata service

Global administrators can configure these services from links on the SharePoint Online administration center page, shown in Figure 2-2.

Figure 2-2 The SharePoint Online administration center page

Additional Public Web Site Customizations

In addition to the site settings and service application customizations that are available in all on-premise installations of SharePoint, Microsoft has added additional control over the look and feel of the public web site. When an administrator is logged in to the public web site, an additional ribbon is visible, as pictured in Figure 2-3. This ribbon provides control over many of the aspects of both the master page and regular pages in the site. There are even things such as applying a page background or setting a fixed width to the master page that can only be done with a custom-developed master page in on-premise environments. By using this ribbon, administrators can create a compelling Internet presence environment that is so different from a standard SharePoint look and feel that most users will never know it’s running on SharePoint.

Figure 2-3 Applying a page background to the public web site

This custom ribbon has the following four tabs:

• File: Controls saving and publishing the page.
• Home: Similar to the Format Text tab available when editing a WIKI page, you use it to create new pages and format text.
• Insert: Adds controls that you can use to add things as simple as an image or as complex as slideshows, embedded video, or maps to the page.
• Design: Customizes the color, style, layout, background, and navigation.

There are other ways to accomplish many of the customizations available in this ribbon. For example, you can apply an overall color change to a site by selecting or creating a theme in the Site Settings page. However, some of these enhancements can only be accomplished elsewhere in SharePoint Online using SharePoint Designer or custom-developed code.

When the Browser Is Not Enough

Although you can make a lot of changes using only the web browser user interface (UI), these changes are often insufficient. Many companies will need to move beyond the capabilities of the browser UI to reach the level of customization they want in SharePoint Online. When the customizations possible using the browser UI fall short of what you envision, the next step is to move to SharePoint Designer 2010.

Customization Through Declarative Solutions and Client-Side Coding with SharePoint Designer

Customizing a site with SharePoint Designer 2010 (SPD) provides an almost identical experience whether you are accessing an on-premise or SharePoint Online environment. The main difference between the two environments will be that you cannot use SPD to connect to external data when customizing a SharePoint Online environment. In spite of this difference, you will probably use SPD more frequently when customizing SharePoint Online than you have in on-premise installations because of the development limitations of SharePoint Online. For example, SPD is the only way to create a workflow for SharePoint Online. SPD provides extensive capabilities to change the look and feel, and extend the functionality of your SharePoint Online site. Using SPD, you’ll be able to customize SharePoint Online sites in the following ways:

• Create or apply a theme to change fonts and colors.
• Create and deploy custom master pages.
• Create or edit Cascading Style Sheets (CSS).
• Create or edit new pages or publishing page layouts.
• Build declarative workflows.
• Customize how users view and interact with content.
• Provide access to external data through Business Connectivity Services (BCS).
• Add client-side code to a page.

Changing the Look and Feel

SPD has always been one of the preferred tools for prototyping the branding of your SharePoint site, and that won’t change because you move to SharePoint Online. Figure 2-4 shows a typical master page being edited in SPD. In addition to its editing capabilities, SPD can do even more to change the look and feel of your site.

Figure 2-4 Editing a master page in SharePoint Designer 2010

Applying and Creating Themes

Many corporate intranets require only a minimum of branding. Using SPD, you have the same access to themes that you have when using the web browser UI. In fact, selecting the Change site theme link on the summary page for a SharePoint Online site will launch your browser and take you to the Site Theme page under Site Settings in your SharePoint Online site. From here you can select one of the built-in themes, create your own custom theme, and preview what your site will look like.

Customizing Master Pages

Using SPD, you can easily create or modify a master page. By implementing a custom master, you can insert your company logo, add a standardized footer, modify how navigation is displayed, and much more. The result will be a consistent look and feel for every page in your site. After your master page and CSS customizations are complete, you can apply them to all the pages in your site using buttons on the ribbon.

Creating Publishing Page Layouts and New Web Part Pages

If your site is using SharePoint’s publishing features, then SPD is also the easiest place to create new page layouts. After you’ve chosen a publishing content type to base your layout on, you can add field controls to the layout to display information on that page. Using publishing and page layouts, you can delegate the creation of content pages in your site to multiple people and still guarantee a consistent look and feel across all the pages.

You can also use SPD to make changes to existing pages in your site or create new nonpublishing pages. Master pages often supply default content to be displayed on the page, but through SPD you can override that default content and change the way a specific page displays. For example, you can easily remove the quick-launch navigation supplied by the master from the left side of the page. This kind of fine-tuned control often removes the need for multiple master pages. You can also easily add your own static content or Web Parts to the page.

Editing Cascading Style Sheets

SharePoint 2007 used mostly HyperText Markup Language (HTML) tables to control placement of elements on a rendered page. But SharePoint 2010 has concentrated on doing most of this placement through the use of CSS <div> and <span> tags. As a result, SharePoint has an extensive set of CSS files that contain the classes used to control how content is displayed and formatted on a page. SPD provides an easy way to override the built-in CSS files for your site. When you choose to edit a specific CSS class in SharePoint, SPD will automatically make a copy of the built-in CSS file and store it in the content database of your site. Using this copy, you can override the existing CSS classes or create your own custom classes to control how your site is displayed.

Creating Workflows

One of the most common focuses for wanting to do development in a SharePoint site is to change the way information is processed by your company. Creating controlled, repeatable business processes is the role of workflows in SharePoint. In an on-premise SharePoint installation, you can choose to build workflows in either SPD or Visual Studio. However, due to limitations on custom code in SharePoint Online, you can create workflows only in SPD.

Figure 2-5 shows the creation of a declarative workflow. SPD declarative workflows can even be created in a local on-premise development environment and then uploaded to SharePoint Online as a WSP sandbox solution. You can also extend the set of actions available in SPD by creating custom actions in Visual Studio 2010.

WHAT ARE SANDBOXED SOLUTIONS?

Figure 2-5 Editing a workflow in SharePoint Designer 2010

Building Dynamic User Interfaces

You can also control how users interact with content through Web Parts using SPD. By default, SharePoint 2010 uses an Extensible Stylesheet Language Transformation (XSLT)–based Web Part to display the contents of lists and libraries. In SPD, you can directly apply conditional formatting, sorting, filtering, and paging to the Web Part. Or you can modify the XSLT used to format the display of content in the Web Part. In addition to customizing the existing XSLT List View Web Part, you can also insert your own Data View or Data Form Web Parts on the page. Using these tools, you can create sophisticated dashboards that highlight critical content for your users.

You can also customize how individual content entries are added, edited, or displayed. Using InfoPath 2010 you can replace existing ASPX (Active Server Page Extended) pages used to create, display, or edit content entries with InfoPath forms.

Accessing External Data with Business Connectivity Services

Most organizations discover that it isn’t feasible to store all their information inside SharePoint. There are a variety of reasons for this. Typically, organizations may find that the following content would not be appropriate to store in SharePoint:

• Files, such as videos, that are too big to upload
• Information stored in third-party line of business applications
• Content that is best stored in a relational database

However, organizations still want to be able to browse or search for all their content, whether it’s in SharePoint or not. Using SPD, you can create external content types and external lists that surface data from external data sources. These external lists can even provide full create, read, update, and delete (CRUD) access to this external data. In an on-premise installation, this is often accomplished by surfacing content in external lists through Business Connectivity Services (BCS).

When Office 365 was originally released, BCS was not supported. Microsoft added support for BCS in late October 2011. Although this is a welcome addition, it should be noted that this is more limited than BCS in an on-premise SharePoint farm. On-premise BCS models can connect directly to SQL databases, via .NET class, or through WCF. In SharePoint Online, you can access external data only through WCF endpoints. Despite these limitations, the addition of BCS support opens new opportunities for managing all your information in a SharePoint Online environment.

Creating Pages with Client-Side Code

One of the frequently overlooked capabilities available in SPD is the insertion of client-side code into a page. SharePoint 2010 added a rich client object model implementation that allows the creation of client-side code using either .NET managed code, Silverlight, or JavaScript. Later in this chapter, we’ll discuss deploying client object model code from Visual Studio, but you can also embed this kind of code directly on a page using SPD. More traditional JavaScript or jQuery code can also be embedded on a page. This is often the easiest way to get small snippets of code deployed to specific pages in your environment.

Limitations Using SPD with SharePoint Online

Although SPD is a powerful tool, there are several limitations that you should be aware of when using SPD to customize SharePoint Online. One of the primary limitations is that SPD is scoped at the web site level. You can only open and edit individual sites in SPD. So when editing a site in SPD, you are unable to apply changes to an entire site collection. For example, if you create a custom master page, you can apply it only to the site you are currently editing. To apply the same master page to subsites using SPD, you would have to open each subsite and apply the master page. However, if the publishing features are enabled, you can apply a master page to an entire web site hierarchy using the user interface. This same limitation exists when working with on-premise sites in SPD.

Packaging Solutions for Deployment

When customizing sites using SPD, you will frequently work directly on the production site in Office 365. However, sometimes it’s better to test your customizations on a local on-premise development environment before you deploy them to Office 365. SPD includes the capability to package many of the customizations you develop as sandbox solutions that can then be deployed to the solution gallery of an Office 365 site collection. Workflows can be saved directly to a sandbox solution template, or you can customize a site and save the whole site as a template. When saving a whole site, you can determine what is saved in the .wsp file. It can contain the entire contents of your site, including views, forms, workflows, and Web Parts. You can also save individual components, such as a list, a view, or a workflow.

Customization Through Visual Studio 2010

SharePoint Online is based on a multitenant environment. As a result of this shared environment, support for custom code solutions is more limited than in an on-premise SharePoint installation. Using Visual Studio 2010, you can create projects that will be deployed only as sandbox solutions. Deploying custom code to the sandbox user code service restricts the operations that your code can perform and also includes a monitoring environment that keeps your code from adversely impacting other sites on the server. Farm solutions developed in Visual Studio 2010 cannot be deployed to SharePoint Online.

Using Sandboxed Solutions

Sandbox solutions normally involve custom code that is deployed and run at the site collection level in SharePoint. Where farm solutions in an on-premise environment must be deployed by a farm administrator, sandbox solutions can be uploaded and activated by any site collection administrator. Figure 2-6 shows a site collection administrator uploading and activating a sandbox solution. Sandbox solutions are uploaded to a solutions gallery in the top-level site of the site collection. When activated, they run in an environment that restricts their functionality. For example, sandbox solutions cannot run with elevated privileges or access external data. Monitoring is also conducted to ensure that a solution does not negatively impact the stability of the rest of the environment. Because of the shared environment that underlies SharePoint, online sandbox solutions are the only way to upload and run custom code.

Figure 2-6 Activating a sandbox solution

Client Object Model

SharePoint 2010 introduced a robust client object model that can be leveraged using .NET managed code, Silverlight, or ECMAScript (JavaScript/jQuery). SharePoint Online’s requirement that server-side code only be deployed using sandbox solutions, and the limitations imposed by that deployment, will lead to an increased reliance on client code. The client object model APIs provide a subset of the features available in the server object model, but are relatively full featured when manipulating objects at the site-collection level or below. Client-side code is also one of the primary workarounds for calling XML web services to interact with data that is stored in external systems.

Customization Limitations

As we have seen, SharePoint Online supports many of the same customization and development options that are available in a SharePoint 2010 on-premise deployment. However, there are some limitations that need to be considered when developing for SharePoint Online. There are a variety of reasons for these limitations, but many of them are imposed because SharePoint Online is based on the multitenant environment. This imposes several limitations, including the following:

• Can only access objects stored within the site collection
• Cannot modify files in the server file system
• No deployment of managed code assemblies to the Global Assembly Cache (GAC)
• Cannot deploy Farm-level solutions
• Cannot create SharePoint timer jobs
• Only a subset of shared service applications are provided

There are workarounds for several of these limitations that will be discussed in later chapters. These workarounds frequently use client-side code in place of a managed code assembly deployed on the server.

Sandboxed Solution Limitations

Not all of the SharePoint 2010 project templates available in Visual Studio 2010 can be deployed using sandbox solutions. Table 2-1 lists the project types that can be deployed to the sandbox and those that cannot.

Missing Shared Service Applications

Because of SharePoint Online’s multitenant environment, there are only a limited subset of the shared service applications that are available in an on-premise environment. Lack of support for several of these service applications imposes significant limitations on custom development in SharePoint Online. SharePoint Online currently does not include support for the following service applications:

• PerformancePoint Service Application
• Secure Store Service
• Web Analytics Service Application
• Word Automation Services

Summary

In this chapter, we provided an overview of the different approaches available for customizing and extending SharePoint Online in Office 365. In later chapters, we’ll examine each of these approaches in greater detail. Table 2-2 summarizes the points discussed. Now let’s turn our attention to building an environment that we can use to develop customizations for our Office 365 environments.