Developing for Office 365's SharePoint Online is similar yet different to on-premises SharePoint
One of the key questions people have about Office 365 is “What about the development story?” And more specific to the audience of this magazine, “What about the development story for SharePoint Online?”
Over the next few months, you’re going to hear more about, the evolved Business Productivity Online Suite (BPOS) that provides you with a cloud-hosted and bundled option of Microsoft’s productivity platform. Included with Office 365 are the latest versions of
• Office Professional Plus
• Lync Online
• Exchange Online
The price-points vary. Office 365 for Small Business runs at about $6.00 per person per month up to twenty-five people. You receive regular updates via an Online Services Connector and don’t have to worry about having to maintain the software.
What About SharePoint Online Development?
First, the look and feel of SharePoint Online is as you know it already. The out-of-the-box look and feel is the same as what you have come to know and expect, as Figure 1 shows.
The development story, similar to your on-premises instance of SharePoint, cuts across three major divisions:
- leveraging the OOTB functionality to customize your site
- using SharePoint Designer 2010 to develop no-code solutions for your site
- building managed code (or script-based) solutions using Visual Studio 2010
If you work in one of the primary audiences for Office 365, the small to mid-sized business (SMB), you’ll likely gravitate towards the OOTB and SharePoint Designer methods of developing for SharePoint Online. And you’ll find that you can do quite a bit with just these two methods.
For example, let’s take using SharePoint Designer. You can create custom business process workflow to manage, say, approval or review processes around list items or documents. With Visio 2010’s new SharePoint Workflow template, you can start in Visio—taking advantage of the ease of use in Visio—and export the workflow to SharePoint Designer, where you can further customize the process of specific actions and rules (e.g. send an email to email alias for document review).
You can also create custom actions in SharePoint Designer, change the default master page, customize site pages, create content types, and so on. For the newbie to SharePoint, and the company that has no IT department to support writing code, there is plenty here to get you to a comfortable and interesting place for SharePoint development.
For example, to update a site’s master page, you can create and add a master page to the SharePoint Online master page gallery, open SharePoint Designer, and right-click that master page to set your custom master page as the default master page—as shown in Figure 2.
The result of this resetting of the master page would depend on what you’ve got in the new master page, but you can see that the result can be quite transformative, as Figure 3 shows. This is the earlier site (that was built with the OOTB Team site template) with a newly-applied master page that updates the look and feel of the site.
SharePoint Designer is good, but if you’re after a more custom code option you can absolutely use Visual Studio 2010 as the place for your development. However, the question you’re likely asking yourself is what’s the difference between developing for SharePoint Server (on-premises) and SharePoint Online (specifically, the multi-tenant SharePoint Online Standard)?
Table 1 provides a glimpse into the major differences across these two versions. You can see that there are quite a few direct translations of capability; though, there are some areas you need to be aware of. For example, no code can be deployed at the farm-level in SharePoint Online; you don’t have access to the global assembly cache (GAC).
You also cannot make external Web service calls to the web, and Business Connectivity Services (BCS) is not available at GA—although there are plans for it to be available in a service update post-GA.
Still, you’ll find that there is quite a bit that you can do. For example, let’s say you want to create an application in SharePoint that enables you to use a web part to add information to a list and then render that data in, for instance, a Bing Maps control.
To do this, you’d need a programmatic way to interact with a SharePoint list and a way to read the data from that list to display in a Bing map. In Figure 4, you can see that this is what’s happening: A Web Part lets user enter information which can be added to a list, and the Silverlight Bing maps control scans the same list to populate and display records (in this case stores).
The Web Part was created using a sandboxed solution, which is a partial-trust code solution that runs in the context of a site collection. (To learn more about sandboxed solutions, see the MSDN website.)
The sandboxed solution uses the SharePoint server object model to insert list items. For example, the following code snippet illustrates the event that is called when you click the Add New link-button.
void lnkbtnSubmit_Click(object sender, EventArgs e)
SPSite siteCollection = SPContext.Current.Site;
SPWeb mySite = SPContext.Current.Web;
SPListItemCollection listItems = mySite.Lists\\["Store Locations"\\].Items;
SPListItem item = listItems.Add();
item\\["Title"\\] = "23";
item\\["StoreName"\\] = "Contoso Tacoma Dome";
item\\["StoreAddress"\\] = "Tacoma Dome Annex Shopping Mall, Tacoma, Washington, United States";
item\\["StorePhone"\\] = "253-442-1029";
item\\["Latitude"\\] = "47.2530556";
item\\["Longitude"\\] = "-122.4430556";
item\\["Hours"\\] = "12";
The Silverlight Bing Maps control uses a new API, the SharePoint Client Object Model, to interact with the list data. You can see from the following code creates a generic query to retrieve data from the SharePoint list using this new API.
private void GetListData(string listTitle)
clientContext = ClientContext.Current;
web = clientContext.Web;
List list = web.Lists.GetByTitle(listTitle);
CamlQuery query = new CamlQuery();
query.ViewXml = "<View></View>";
storeslistItems = list.GetItems(query);
While the sandbox may restrict you from achieving certain goals programmatically, it’s important to remember that you can still do quite a few interesting things with the sandbox. For those concerned with portability, one practice would be to use sandboxed solutions on-premises to ensure a seamless migration of code.
What about the Rest of Office 365?
Beyond the core capabilities of SharePoint Online development, you’ll also find a set of rich development opportunities outside of SharePoint in Office 365. For example, While Office 365 is a subscription-based service, you actually get the client install of Office.
For those of you that are familiar with Office development (often referred to as VSTO functionality), you can deploy managed-code add-ins to augment the functionality of your Office documents. This often translates into custom task panes that integrate data from line-of-business systems or custom ribbon elements that extend the functionality of the document.
You’ll note that you also have the ability to customize the Office Backstage. (If you’re unfamiliar with the Backstage, open a Word 2010 document and click the File tab—this is the Backstage.) Unpaid subscription fees automatically restrict the use of Office, which would ultimately effect your add-in, but otherwise it’s business as usual with Office development in Office 365. For more information, you can visit the MSDN site.
Further, Exchange Web Services also offer unique opportunities to access items and the data store items on Exchange. The Web Services, which are SOAP-based services, provide you with a way to integrate with mailboxes in a way that is compatible with Office Outlook and Outlook Web Access (OWA)—the front end to Exchange Online.
Microsoft has a development guide that, while older, gives you some insight into what you can do with Exchange Web Services. You can also check out my blog for code samples and more information on cloud-based solution development.
Office 365 offers a world of opportunity—from SharePoint Online to Office client development to leveraging Exchange Web Services. To get started, visit the Office 365 information portal.