.svg)
Provider Hosted Application is very useful to re-use the existing, Net application with very minor changes and their hosting environment. The topology of the Provider Hosted Application is as follow.
An example of flow interaction:
“SharePoint Provider Hosted App” is now officially called as ‘SharePoint Provider Hosted Add-in’ by Microsoft. In rest of the article “App” will be denoted as “Add-in”.
SharePoint Provider Hosted Add-ins contains components that are deployed and hosted outside SharePoint farm. Their installation occurs in host web; however, their remote components are hosted in an isolated server/domain.
SharePoint Hosted Add-ins have a fixed hosting pattern, as they are hosted in Add-in-web. “Provider Hosted Add-in” provides better flexibility for hosting various components of your “Add-in”. If you want to create an application, you need to match your goals and requirements with the appropriate hosting pattern.
One of the most important question you need to ask Provider Hosted Add-ins provide you two options through which you can interact with SharePoint:
JavaScript cross-domain library
Library
JavaScript cross-domain library allows you to interact with more than one domain from remote components of your add-in through proxy. Cross-domain library is a good option under following two conditions:
If client-side code and the permissions assigned to user in SharePoint are sufficient (Read permissions to library).
Whenever you are making remote calls through a firewall.
OAuth
OAuth is an open protocol that enables secure authorization from client applications (desktop, web, and mobile applications) in a manageable way. OAuth is required whenever you are calling into SharePoint from a web application that is remotely hosted and can’t use client-side code (HTML + JavaScript) exclusively.
While using Provider Hosted Add-in with Azure (Cloud) web deployment and Office 365, you need ‘Microsoft Azure Access Control Service (ACS)’ as the trust broker between Azure (Cloud) Web and Office 365 SharePoint site. But while deploying add-in in ‘On-premises SharePoint 2013’ site, it needs Server certificates along with ACS to enable High-Trust between add-in and SharePoint. These certificates should be installed on SharePoint on-premises server to enable trust between add-in and SharePoint.
Below table lists out all possible patterns for hosting both SharePoint components and remote components of your add-in, along with trust brokers which are available to you in case you are using OAuth.
Provider-Hosted Add-In
“Bring your own server hosting infrastructure” Developers will need to isolate tenants
SharePoint-Hosted Add-In
Provision an isolated sub web on a parent web
- Reuse web elements
(lists, files, out-of-box web parts) - No server code allowed; use client JavaScript for logic, HTML/CSS for UX.
Useful language for development:
- The ClientObject type is the base abstract class defined in the .NET Client Object Model to describe any object retrieved on a remote client.
- You can reference a ClientObject-inherited object in another method call or query definition, even if you did not already retrieve it from the server, because it will be correctly resolved by the CSOM
Api Architecture
- REST based endpoint
- Supports XML/ATOM or JSON
- Wraps CSOM
- Not well documented
- But CSOM is documented
- And you have .NET Reflector, as well
Blog Scenario
In the scenario of realizing a blog Sharepoint, the actors involved in planning the architecture are as follows, a SharePoint site is created a dedicated database and finally a custom html page uses javascript technologies to call rest services so that they can interact with the web installed on the azure machines.
Do you want more infromation about this? Contact us!