Get Started Building SharePoint Online Solutions

For almost a year, I’ve been working with SharePoint Online (SPO) and cloud integration. I’ve found that the latest version of SPO provides many new capabilities and more flexibility for developers who want to create business solutions that run on SharePoint sites in the cloud. After I give a quick overview of what you can do with SPO, I’ll discuss how to do it. As you’ll soon find out, there are many different design patterns that you can use to integrate SPO solutions with cloud components.

What You Can Do

SPO is essentially SharePoint 2010 running in the Microsoft cloud. It lets you create sites for sharing documents and information with colleagues and customers. The latest version of SPO falls under the Office 365 umbrella of Microsoft Online Services, which includes Exchange Online, Lync Online, and integration with the Office Web Apps. You can sign up for the beta version of Office 365 and learn more about the new SPO version.

In past SPO versions, the main development tools have been the web browser and SharePoint Designer. In the latest version of SPO, you can do much more than configure solutions with a web browser and enhance them with SharePoint Designer. Now, you can deploy custom code to SPO in the form of sandboxed solutions.

Sandboxed solutions can deploy coded components, declarative components, Silverlight applications, and more. For a complete list of the components you can use in SPO, check out the Microsoft article “SharePoint Online: An Overview for Developers”. You might be surprised when you see how many different components you can deploy to SPO. Table 1 lists some of those components and gives examples of how you might use them to create SPO solutions and, in several cases, interact with cloud components. Although this list isn’t exhaustive, it provides a good starting point that can get you thinking about how to create SPO solutions that include sandbox-compatible components that integrate with cloud components.

Table 1: Components Available in Sandboxed Solutions for SPO

How You Can Do It

Now that you’ve seen many different ways to extend and enhance SPO sites, you’re probably wondering how to go about developing SPO solutions. To get started, you’ll need a standard SharePoint 2010 development environment. If you haven’t built one yourself, you can download the 2010 Information Worker Demonstration and Evaluation Virtual Machine. This virtual machine (VM) set includes everything you need to develop SharePoint 2010 solutions. Also, make sure you check out the SharePoint Online Developer Resource Center and the SharePoint Developer Center for training kits, SDKs, and sample code.

Next, if you’re creating Silverlight applications for use in your SPO sites, download and install the Microsoft Silverlight 4 Tools for Visual Studio 2010. You’ll also need the Silverlight 4 Developer Runtime.

Finally, download and install the following:

The Windows Azure Developer Center contains training kits and videos to help you get up to speed on this platform. After your development environment is set up, sign up for a Windows Azure account.

SPO Design Patterns

As Table 1 shows, there are many ways to integrate SPO sandbox-compatible components with cloud components. How you choose to go about integrating the two will depend on your environment and requirements. There are several options available. To begin, let’s discuss the client portion of the implementation.

By design, sandboxed components (which run in the context of the User Code Service) don’t have permission to make calls to external services. This behavior is identical to that in the on-premises version of SharePoint 2010. To learn more about the User Code Service and the sandbox execution model, check out the Sandboxed Solutions web page in the SharePoint 2010 Patterns & Practices documentation.

To make calls to external resources, such as cloud resources, you need to use code that runs on client machines in a web browser session. Both jQuery-based and Silverlight client solutions can be deployed as SPO sandboxed-solution components that interact with external services, such as cloud resources. This makes jQuery-based and Silverlight applications the perfect choice for clients that interact with cloud components.

After you decide which technology you want to use to implement your SPO solution, you need to figure out how to access the services that support your solution. Perhaps the most common design pattern you’ll see at first is calling external web and Windows Communication Foundation (WCF) services from a client browser session. The reason this pattern will be so common is that there are already many services on the Internet that line of business (LOB) applications rely on, such as weather data, traffic data, and customer relationship management (CRM) services (e.g., Salesforce.com). In this pattern, users access a jQuery-based or Silverlight application deployed to an SPO site. The jQuery-based or Silverlight application calls out to services available on the Internet. Figure 1 illustrates this pattern.

As cloud development evolves and more organizations choose to deploy services to the cloud, it will become more commonplace to call WCF services hosted in Windows Azure. In this pattern, users access a jQuery-based or Silverlight application deployed to a SPO site. The jQuery-based or Silverlight application calls out to WCF services running in Windows Azure. Figure 2 illustrates this pattern.

Sometimes LOB applications must access on-premises services. In such a scenario, you can use the Windows Azure AppFabric Service Bus to call on-premises services. Using the AppFabric Service Bus to forward requests to on-premises services has several benefits, including:

In this pattern, users access a jQuery-based or Silverlight application deployed to a SPO site. The jQuery-based or Silverlight application calls out to the AppFabric Service Bus running in Windows Azure. The AppFabric Service Bus relays the call to the on-premises service. Figure 3 illustrates this pattern.

In addition to accessing services from SPO sites, you’ll probably need to access cloud-based data sources to support your SPO solutions. Many cloud-based data sources already exist, including SQL Azure and the Windows Azure Marketplace DataMarket (formerly code-named Dallas).

In the pattern to access cloud-based data sources, users access a jQuery-based or Silverlight application deployed to a SPO site. The jQuery-based or Silverlight application calls out to SQL Azure, Windows Azure Marketplace DataMarket, or another cloud-based data source. Figure 4 illustrates this pattern.

Perhaps the most interesting pattern of all is replicating SharePoint’s timer job functionality using nothing but cloud-based components. In this pattern, Windows Azure worker roles monitor data stored in cloud-based data sources. The worker roles then react accordingly and create, update, and delete data stored in cloud-based data sources. Users access jQuery-based or Silverlight applications deployed to a SPO site that interacts with the data the worker roles manipulate. Figure 5 illustrates this pattern.

Deployment

Developing cloud-based components is most easily done in a local development environment, as previously mentioned. Windows Azure WCF Services, Windows Azure worker roles, and SQL Azure can all be run locally on a development machine. Running the cloud-based components locally lets you easily debug and fine-tune them. When you’re ready to deploy the cloud-based components, simply publish the Windows Azure components to the cloud.

Just like a traditional on-premises scenario, you should create a development/test site collection to validate that your code works. To test your SPO components, first set up a development/test site collection within a SPO customer tenancy. SPO sites are hosted in a multi-tenancy environment. A customer tenancy is a given customer’s site collections within the multi-tenant hosted environment.) After the development/test site collection is set up, deploy your SPO components. This will allow you to iron out any kinks related to authentication, authorization, and interacting with Windows Azure or other cloud-based services and components. After the testing phase is complete, simply create the production site collection within the SPO customer tenancy and deploy your SPO components.

To the Cloud!

As you can see, SPO provides a wide variety of components and integration points with cloud resources that make it possible to create robust LOB applications in the cloud. Cloud-based solutions are gaining momentum every day, as more businesses move their LOB applications to hosted environments. Don’t be left behind. Sign up for an Azure developer account and start building SPO solutions. The sky’s the limit!