Thursday, 26 June 2014

Step-by-step video: remote SharePoint code in Azure

As I noted in my last post Modern SharePoint Development – techniques for off-box code, there is something of a movement in the SharePoint development world to what is often termed “the Cloud Application Model”. In a nutshell, this is the approach that many development tasks *must* use for Office 365, and *can* use for on-premises SharePoint. Specifically, the Cloud Application Model is about having custom code run “off-box” to SharePoint using the remote APIs rather than than the server-side API – after all, in Office 365 it’s simply not possible to deploy custom SharePoint code to Microsoft’s servers (this is not permitted because some bad code could affect the service for many clients). But as I noted last time, there can be benefits to this approach even in on-premises projects - such as:

  • Greater isolation – an app running “off-box” cannot bring down SharePoint for the entire organization
  • Ease of upgrade – less customizations made in SharePoint, the easier upgrade (e.g. to SharePoint 2015) becomes
  • Possibility of transitioning to cloud – if the organization is even half-considering a move to Office 365 (e.g. in the next few years), building solutions the “cloud-friendly” way means no/minimal re-work is required to move. Certainly we have more than one client who has asked us to build this way – because they want to leave the door open for Office 365 (or hybrid) as they move forward

Some different flavors of off-box code include:

  • Client code running in the browser - use of the JavaScript Object Model (JSOM), or the REST API from JavaScript
  • Remote server-side code – use of the .NET Client Object Model (CSOM), or the REST API from the server

For the latter case, you need to identify a non-SharePoint server where the CSOM code can run. Common choices here include using Azure (or similar cloud service) or providing your own IIS servers – since an app is typically required for the “trust” of the remote code, this is the notion of “provider-hosted apps” which you have probably heard about. As I’ve often said, I really like the Azure option because so many infrastructure things are taken care of (SSL, High Availability, ability to scale up, backup/restore, published to the internet and so on).

As a reminder, Microsoft supply *lots* of useful remote code in their Office App Model Samples pack (known as the “AMS samples”) – this deals with many common scenarios you might encounter. But you still need to figure out where to run the code from, and go through the “remote code” configuration steps to enable this (or any remote server-side code) to run.

A guide – my subtitled video showing end-to-end config of remote code in Azure

There are various resources related to apps and remote code, but the steps are fiddly and sometimes it’s difficult to follow the entire process. So I decided to produce a video, with lots of captions explaining each step – the scenario I’m using is configuring a Remote Event Receiver (RER) in Azure. Note, however, that perhaps 90% of the steps apply to *any* remote server-side code scenario where the hosting location is Azure. So if you have any kind of provider-hosted app and want to run it from Azure, you’ll need the same set of steps (even though you’re not using RERs).

The image below might give you a sense of the video/captions:

COB RER video snapshot


If you have any feedback/questions, please publish them here and I’ll try to respond. Thanks!


Richard Walsh said...

Just so I'm getting this right conceptually (and correct me if I'm wrong), but isn't this process you describe (putting provider hosted apps into Azure), a replacement for auto-hosted apps in SharePoint?

CyberPine Educational Media said...

This is in line with my development strategy for our new SPO 2013 environment.

Ideally we are building more SOA in Azure - but IMO, we need better SPO client side form and reporting designer tools to help ease the pain.

I'm hoping FoSL is really flexible and powerful with WYSIWYG drag-n-drop, expressions and allowing more data connection, joining and filtering options. Think SPD DVWP 2010 meets SSRS meets Access 2013.