Introduction to Office 365 Add-ins

Foreword

The main intention of this article is to set the ground right by giving an introduction to basic concepts. In this article I will be focusing more on Provider Hosted Add-ins. This series is inspired by the works of Kirk Evans and Chris O’ Brien

A Bit of Background for Office 365 and SharePoint

Few years ago, one of my colleagues, to explain SharePoint for non-SharePoint Developers, he placed a dot on the white board, drew a circle around it and loudly said Sharing the Point is what SharePoint does. Well, that’s exactly right. It is a collaboration platform for organizations to perform better by sharing information. It is a combination of so many enterprise product suites like Content Management Systems, Document Management Systems, Business Intelligence, Social Computing and Enterprise Search.

During early 2000s when Portals were riding high, Microsoft launched SharePoint Portal Server 2001. This product has so many ancestors like Site Server, Tahoe, and Front Page, etc. Joining Dots has done extensive research on early history of SharePoint (a bit of old post).

As part of Office 365 suite, SharePoint Online is a subscription based Software as Service Product. Apart from SharePoint Online Office 365 has many other offerings like Office Online, Exchange Online, One Note One Drive and many more.

Best things about learning Office 365 Add-in Development

  1. You don’t need to be well versed with SharePoint although basic knowledge related to core components like Lists, Content Types etc. can help to speed things easier
  2. You can bring your existing web development skill set to the table
  3. Microsoft has done amazing job on documentation even though Office 365 space is constantly evolving they are trying to keep documentation up to date. Numerous resources are available for self-paced learning. Best I recommend is http://dev.office.com/training

What is New Office 365 Add in Model

Traditional Solutions

Traditional on premise SharePoint Solutions are Farm based solutions which means solutions get deployed on to SharePoint servers and use Server Side Object Model. These solutions can run in the scope of Site Collection or Web Application or an entire Farm. These solutions always run with full trust. From SharePoint 2010 onwards, Microsoft introduced a new paradigm called Sandbox solutions. These kind of solutions can run in Sandboxed environment with restricted access to resources. Sandbox solutions have limited access to Server Side Object Model and run with security restrictions in an isolated process, hence installing and uninstalling these solutions will not affect the farm.

Add-in Solutions

SharePoint 2013 introduced Add-in Model which is significantly different from the above described Farm and Sandbox solutions. On the high level, these are the main concepts of Office 365 Add-in Model.

  1. The applications logic is self-contained and they run independently not on SharePoint Farm.
  2. Business Logic of the Add-in can access data hosted in SharePoint via various Client APIs.
  3. When administrator on Site Collection Owner installs an add-in, the site where it is installed is calledHost Web and as part of installation, another site (with separate subdomain) called Add-in Web gets created which holds SharePoint components of Add-in.
  4. SharePoint Add-ins can be surfaced either by Immersive experience with look and feel of SharePoint Site or there is a special type of component called Add-in Part which are made of iframes. With Add-in part, Add-in can be surfaced inside a SharePoint Page to provide consistent user experience.

There are two approaches for developing Add-ins for Office 365.

  1. SharePoint hosted Add-in, here application is written in Client Side Web Technologies (HTML and JavaScript) and hosted on custom SharePoint Pages. Add-in can access SharePoint data via JavaScript Object Model. These types of Add-ins typically work well by leveraging SharePoint Core Components like Lists, Pages and Workflows.
  2. Provider hosted Add-in, here application logic can sit on third party servers independent of SharePoint Farm. Again, it can access SharePoint data via Client Side APIs. This kind of Add-in can open possibilities to use non Microsoft Stack for the Add-ins.

Decision of which model to use completely depends on the type of the Add-in functionality that we are targeting.

SharePoint Hosted approach is best suitable if add-in needs to use more out of the box SharePoint functionality like People Picker or out of the box modal windows and has little or no connectivity with external data resources. Examples could be Productivity apps like Task list which can be shared with team or Time Sheet app. Below diagram represents how SharePoint hosted Add-in co-exists inside SharePoint/Office 365 tenant

sphosted

Provider Hosted App is best for situations where there is lot of connectivity with external data sources. Building dashboards with data that is stored inside SharePoint List or projecting data on to the map based on latitude/longitude information stored in List.

providerhosted

Authentication and Authorization in Add-in

Office 365 uses OAuth 2.0 + Open ID Connect with Azure Active Directory for authentication and authorization. In SharePoint hosted apps, the application logic sits inside Custom Pages of SharePoint under Add-in Web. To access these pages, the user has to sign in with his Office 365 credentials. To access data hosted in SharePoint, Add-in needs to use Cross Domain library using Logged in users principle.

Since Provider Hosted Apps live on third party servers, it is the responsibility of the developer to secure them. Office 365 uses Azure Active Directory for Authentication. To provide Single Sign on experience for end user, we could secure the Prover Hosted Add-in with Azure Active Directory. When a user launches Add-in from Office 365, the user will be redirected to Provider Hosted App Page with two types of tokens in the query string of the URL. These tokens can be used to communicate with SharePoint under the context of App or under the context of the user.

This concludes basics concepts related to Office 365 Add-ins.

Next Steps

  1. Securing Provider Hosted Apps
  2. Impersonating Custom WebAPI and calling it from Provider Hosted App
  3. Integrating Outlook Addin with Office 365

To be Continued…

Leave a comment