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:
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.
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:
Note that this URL has the following structure:
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.
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.
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.
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.
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.
The IT Leader's Guide to Multicloud Readiness
This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.
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.
A SharePoint app is simply a zipped .app file with following structure:
- 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.
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
- 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