Today I am going to talk about application model in SharePoint 2013. There are tons of hundreds of articles, videos, blogs and msdn how-to videos available online and they are pretty good too. The reason for sharing my thoughts on the subject is to give you a concise, holistic view in couple of paragraphs that may help grasp the concept. You are still going to need to read about the architecture t in order to understand the internal mechanics of how this new framework works but here is a good starting point especially for the new adapters. So lets get going.
For those who are new to exploring and evaluating SharePoint 2013, application model or app model for short is a new concept in SharePoint which provides a framework to which we deploy our applications in SharePoint. The traditional way of deploying was to create all artifacts, declarative, managed server side/client side code, web services etc. and put them all together in one single WSP or spread across in multiple according to their function.
Application model or app life cycle gives a new perspective of looking at not only deploying your application components to the farm but target the specific audience with specific functionality that can work independently or may have dependencies on the global components (root web) and can interact with those objects outside its own scope. To really grasp this concept, we have to look into application scopes and what their boundaries are.
Applications for SharePoint 2013 or SharePoint 15 run in its own app domain just like any other .net web application.
There are 2 application scopes provided by SharePoint:
Host Web
The Host Web is the app domain or the address space for applications running at the site collection level so that they are shared across all sub level sites. The customizations that are allowed to run in Host Web are Custom actions and web part deployments called app parts. You can deploy Host Web features which sit outside the WSP package in the .app file. I am going to talk about this mystery .app file later in this post but if you want to learn now, feel free to scroll to the application packaging section to learn more about it.
App Web
The app web is an app domain in which application for SharePoint runs. Every app in SharePoint has its own app domain so that the cross site/domain connectivity and scripting is not available and allow for each application to run independently. All App web applications have web scoped features only. There are exceptions to this rule which is beyond the scope of this post but to give you an idea an application can invoke rest based remote web services by specifying RemoteEndpoint in app manifest and using javascript via SharePoint proxy (SP.WebProxy and SP.WebRequestInfo). This has been tested by a colleague of mine and it works. MSDN provides a basic example here http://msdn.microsoft.com/en-us/library/fp179895(v=office.15).aspx
One the other hand if you want to make cross-domain calls from remote server into SharePoint where your app is deployed, you could use a SP.RequestExecutor javascript object to make REST calls. An example to do so is available at http://msdn.microsoft.com/en-us/library/bc37ff5c-1285-40af-98ae-01286696242d.aspx. There are whole bunch of cross-domain scenarios available at http://msdn.microsoft.com/en-us/library/bc37ff5c-1285-40af-98ae-01286696242d.aspx
What happens when you deploy an app for SharePoint?
When you deploy an app on the site, not only a new web is created under the root web with the title of the app and pages deployed under the pages library of the web, a GUID like app ID is appended to the domain to form the URL to access the app.
MSDN provides a pretty good example on this:
For example, suppose that an app, with SharePoint components beyond just the UI elements that can be deployed to a host web, is installed on a host website at the following URL: https://www.contoso.com/sites/Marketing
The app for SharePoint will be deployed to a newly created website with a URL like the following:
http://app-bdf2016ea7dacb.contoso.com/sites/Marketing/Scheduler
Note that this URL has the following structure:
https://App_Prefix-App_ID.App_Base_Domain/Domain_Relative_URL_of_Host_Web/App_Name
The placeholders are defined as follows:
- App_Prefix is any string set by the farm administrator in Central Administration. The default is “default.” In this example the administrator has changed this to “app.”
- App_ID is a hexadecimal number generated internally when the app is installed.
- App_Base_Domain is any string set by the farm administrator in Central Administration. The default is the domain of the SharePoint web application. In this example, the administrator has removed the “www.” and set contoso.com as the app base domain.
- Domain_Relative_URL_of_Host_Web is the relative URL of the parent host web, in this case sites/Marketing.
- App_Name is the value of the Name attribute of the app element in the appmanifest.xml file.
There are two primary reasons for deploying apps to app webs, rather than the host web. Both are related to security.
There cannot be nested apps or webs within the site collection which means all app webs exist directly under the root web.
Application deployment model
There are two basic modes Microsoft provides for developing and deploying a SharePoint app depending upon the features you want your users to work with. These modes are not exclusive so if you want to deploy an application which is hosted on SharePoint as well as in the cloud, you can certainly do so. Let’s see in detail what each mode offers to the developers.
SharePoint-Hosted
All SharePoint specific objects which are the building blocks of the SharePoint application like lists, libraries, instances, templates, features, resources including images, style sheets, etc. In other words only the declarative code can be deployed on SharePoint-Hosted environment and no server-side code is allowed. However, you could use client object model using JavaScript class library (SP.js) to talk to SharePoint.
Cloud-Hosted
All server side (managed) code which you want to deploy for your application goes here. In other words, business logic, data massaging and manipulation happens here. Within cloud-hosted deployment you have the option to either host your app on Microsoft SP App Store called Autohosted or you can deploy it in third party cloud called Provider-hosted.
Provider-hosted apps can be developed in any language of your choice. Be it javascript, php, python, Ruby on Rails you pick as long as it has the ability to get, put, post to request the objects from SharePoint and able to read the response back. Microsoft provides the following support to interact with SharePoint.
i) CSOM or SharePoint Client Object Model
This is SharePoint client object model which is a managed SharePoint client APIs which you can use to connect and perform CRUD operations on remote SharePoint instance. These set of APIs are not new if you have worked with SharePoint 2010 client object model. You need to install the SharePoint Client runtime to work with CSOM.
ii) REST/ODATA
Now SharePoint 2013 sites are fully available to be remotely managed using the REST APIs. You can create webs, lists, perform CRUD as well you can perform search and you do not have to use Search.asmx for that. You can also work with user profiles. I had to write my own REST APIs to work with user profiles so I guess I don’t need that any more.
The API’s were introduced in SharePoint 2010 but what’s new is there is a massive extension of these APIs which now lets you not only use ListData.svc but you can interact with Search, User Profiles, Publishing framework, just to name a few. The whole list is available on MSDN. You can perform your CRUD operations using javascript. All you have to do is to send http requests and receive responses using JSON. And believe me its super simple.
Its your choice how you want to work with REST APIs depending upon complexity and resources. The following ways can be adopted to work with these APIs:
- .Net Server side code allows you to simply drop the service reference in your project which will create a proxy for you and you work with the strongly typed objects as well as get intellisense and compile time error checking.
- You can use Javascript to send http requests to SharePoint using REST based URL and receive the response in callback methods. Large implementations can be a bit messy with this however if speed and optimization is the requirement than its the best candidate.
App Security
Application security is another new concept that was introduced with apps for SharePoint. You can configure your application to request certain permissions from the user before it can be used. Its the same security as in Windows 8 or Android devices. This security model is built upon OAUTH. For example if you application require internet connectivity than it must be granted for the first time when it runs.
Application Packaging
A SharePoint app is simply a zipped .app file with following structure:
- AppManifest.xml
- WSP
- Host Web Features
When you are ready to deploy your app and if you are using Visual Studio, just build the project and publish. What publishing does is it compiles the WSP and bundles it up in an .app file with a manifest file or host web features.
The app manifest is where all the magic is happening. It has the title, name, start page and configuration of features to activate, etc. Also it has another major configuration and that is permissions. What permissions does this app require in order for users to be able to use it. So basically it is an added security on top of user security. You can learn all about app security including objects, privileges and permission levels on the links provided at the bottom.
Host Web features
The Host Web features are different than web features which are packaged inside the WSP as normal feature. The host web features allow deploying stuff on the site collection just like site scoped features but only limited to custom actions and app parts. The web host features are deployed by including in the app package a Feature that is not inside the package’s .wsp file and that deploys the components that will go to the host web. This “loose” Feature is called a host web Feature. App parts are deployed to the host web in the same way. The host web Feature consists of a standard SharePoint 2013 feature.xml file and one or more associated elements.xml files.
Wrap up
My 2 cents on the app framework is that Microsoft has kind of left the interpretation of application model to its users and developers. Some might take it and use it as another means of bundling and deploying specific features, some might look at it from security isolation point of view and some would take it as an independent application which bundles related features as well as provides an entry point for users to navigate and interact. The pages deployed by an app work exactly like application pages but reside in pages library and use a different master page for look and feel. One of the things that I most like is the ability for an app to run from SharePoint but have remote counter parts.
The easiest way to start developing your apps is to get yourself a developer site on Office 365 and to get you going with building your first app for SharePoint or understanding the application life cycle, I would encourage and point you to follow the MSDN articles below and watch the videos as those videos are very well presented and will clear your concepts on app development. There are also a few samples available on MSDN
- SharePoint Apps Overview – http://msdn.microsoft.com/en-us/library/office/apps/fp179930(v=office.15).aspx
- Basic SharePoint App – http://msdn.microsoft.com/en-us/library/office/apps/jj163980(v=office.15).aspx
- Client API examples – http://msdn.microsoft.com/en-US/library/fp179912(v=office.15).aspx.aspx
- Client API reference – http://msdn.microsoft.com/en-us/library/office/apps/jj193041(v=office.15).aspx
- Javascript – http://msdn.microsoft.com/en-us/library/office/apps/jj220041(v=office.15).aspx
- Licensing apps for SharePoint – http://msdn.microsoft.com/en-us/library/office/apps/jj163257(v=office.15).aspx
- Cross-domain access – http://msdn.microsoft.com/en-us/library/bc37ff5c-1285-40af-98ae-01286696242d.aspx
