It is hard not to be aware of the existence of Apps. Made hugely popular by the smart phone and iPad markets, these little programs can be downloaded from different types of App stores against a fee, or sometimes completely free of charge. After that, those Apps run on some type of client device, fulfilling the personal needs of the owner of that client device. SharePoint 2013 innovates that game by introducing Apps targeted towards the enterprise instead of the consumer.
Note App stores are becoming increasingly important in the Microsoft world. You will not only find an App store for SharePoint, App stores are also integrated within Windows 8 and Office 2013.
The introduction of Apps to the SharePoint platform is likely the one new feature that is the biggest eye catcher of all. Or, as Brian Jones (Group Program Manager on the Office Solutions Framework team) stated it with some sense of drama: “It’s the most significant thing we’ve done with the (Office) platform in 15 years since the introduction of Visual Basic for Applications (VBA)”.
At first, Apps may sound like nothing more than a change in brand name. In SharePoint 2013, lists are Apps, document libraries are Apps, site pages are Apps, event handlers are Apps, and so on. “Everything is now considered an app”, is a quote from Richard Riley, Director of Product Management for SharePoint. You will likely hear this quote, or something similar, a lot when talking about SharePoint 2013. You may also think about Apps as a logical evolution in the way SharePoint solutions are built and made available to the platform, and you wouldn’t be wrong. But you will see that Apps are more. Firstly, this blog post will teach you that Apps are in fact a paradigm shift in the way the SharePoint platform can be customized by 3rd parties. Secondly, you will learn how to deal with this new paradigm.
Apps, the SharePoint Store, and the Corporate Marketplace
With SharePoint 2013, the platform has in-built support for Apps, which provide functionality that allows you to customize SharePoint. Or, to put it in other words, Apps are ready-to-use solutions. The term App doesn’t just apply to third-party efforts, basically everything that is there in SharePoint out of the box is now also designated as an App. For example, now lists, libraries, tasks, and calendars all are Apps.
Note Apps are reusable pieces of functionality. Sounds familiar? This does sound a lot like the definition of a web part. The big difference being that web parts are hosted and executed on the SharePoint servers themselves. As you will see later on, SharePoint Apps don’t have to be.
The main reason for introducing Apps to the enterprise market is to make it real easy, but also safe, to extend your existing SharePoint platform with third-party Apps. To facilitate this and make life easier for Microsoft Independent Software Vendors (ISV) partners, Microsoft has introduced an online App store called the SharePoint Store, which is itself hosted in the cloud. SharePoint Store is directly integrated with SharePoint 2013 (in the on-premises variant as well as the Office 365 cloud variant) so that it’s real easy to acquire, buy and manage these Apps. The SharePoint Store shares the same back-end as the Office Store and is hosted on Office.com. Alternatively, you can get Apps from on-premises Corporate Catalogs. It is to be expected that Apps will provide various services, like:
· Site templates, Apps can provide ready-to-use site templates targeted towards specific branches.
· Site add-ons, Apps can enhance existing functionality by, for instance, adding new ribbon buttons that provide some type of new feature.
· Web parts, Apps can provide pieces of reusable functionality in the form of web parts that make sense in the enterprise sphere.
· Branding, Apps can provide custom branding themes by providing CSS files and JavaScript.
· Application Integration, Apps can integrate with external services, such as the ones offered in the Azure Marketplace (https://datamarket.azure.com/ ).
· Independent Line of Business (LOB) applications that integrate with SharePoint, Apps can provide an immersive full page solution that is still tied in to SharePoint.
The SharePoint Store has its own integrated payment system and it’s possible to allow end users to install Apps without requiring server administrators to be involved with the deployment and activation of Apps. Apps, after undergoing a rigorous validation process conducted by Microsoft, can be admitted to the SharePoint Store.
At the time of writing, the SharePoint Store is still in preview and the offering is still limited. The possibilities are endless though. To mention a few, there are Apps that offer Facebook integration, offer Digital Asset Management capabilities for working with paper documents, extend the SharePoint ribbon with the possibility to create compound documents, and offer an HTML 5 workflow creation tool. As may be clear, the range of possibilities is endless end the surface has barely been scratched.
Understanding the SharePoint App Model
If you take a look at the history of the SharePoint platform, you can tell there has been an evolution in the way the platform could be customized by 3rd parties. Always, there was a need for balance between the security/stability of the platform versus the power required by 3rd party customizations to offer useful solutions.
In the 2001 version, you could run web part code directly within page execution, in the same process, in the same thread, using either the JavaScript Eval or VBScript Execute functions. The power was limited to running either VBScript or JavaScript, and the potential disruptive force in the area of stability of the custom scripts during the normal page execution life cycle was huge.
The 2003 version was the first step towards maturity. Customizations were deployed to the server and ran under a strict set of privileges defined by various Code Access Security (CAS) policies, or full trust. This allowed IT Pros, if they chose to do so, to limit the potentially dangerous actions that could be executed by custom assemblies. At the same time, SharePoint web applications could be separated between multiple IIS Application Pools running in separate processes, thereby limiting the impact a single SharePoint web app could have on another. But still, custom code was executed on one or more servers of the SharePoint farm and could definitely have their impact on the performance and stability of such servers.
The development model didn’t really change in the 2007 version, although one major issue was addressed: a fool-proof way was added that allowed solutions to impersonate user accounts and run code in an elevated context. Other than that, as far as the available development models went, not much changed.
The development model did change in version 2010. Sandboxed solutions were introduced. They could be uploaded by site collection users and ran in a special and safe sandbox (in its separate process); under the control of a very strict Code Access Security policy to ensure sandboxed solutions couldn’t do any real harm. For instance, sandboxed solutions were allowed to execute a subset of the SharePoint server-side object model, but didn’t have read/write access to the file system, registry, or database. Another new feature was that sandboxed solutions could not only be run in on premises SharePoint farms, but also in SharePoint Online. To top it all, there was a sandbox resource limitation mechanism that allowed IT Pros to specify resource throttling settings to prevent sandbox solutions from over expanding server resources.
SharePoint Server 2013 brings a new addition to the available development models: the App model. To put it in black-and-white, the App model allows you to customize your SharePoint farm by running code outside your farm. For the first time, it is possible to develop custom solutions that are unable to affect your SharePoint farm in a direct way, since they are no longer a part of that farm. In the next sections, you will see how Apps are able to do that.
SharePoint App Architecture
As established earlier, SharePoint Apps provide custom pieces of functionality and have the capability to run isolated from your SharePoint farm. What an App can do exactly is determined by three factors (and you will learn about each of these factors later on in this section):
· App scope
· App permissions
· App authorization policy
In order for these factors to have an effect on Apps, every App needs to have its own App identity that can be used to recognize the App and associate the App to a security principal, which is also known as the App principal. The App principal needs to contain 5 pieces of information:
· App ID (also known as the client ID), a GUID that uniquely identifies the App.
· App Secret, a signing key that consists of a Base64 encoded string that is used by various parties to encrypt and decrypt messages and send it across the network.
· App Title, the friendly SharePoint App name.
· App URI, typically the base DNS name required to get to the App, such as https://myappserver.mydomain.com.
· Redirect URL (optional), in some cases the SharePoint App wants to increase the permissions it has been given programmatically. In such cases, SharePoint will respond by calling the Redirect URL that has been specified as part of the App Principal and send its answers along with this response.
Important The App Identity is great for tracking App activities via the SharePoint Audit Trail mechanism.
App Principals can be retrieved via the following page (be warned: it’s not a very user friendly UI):
http://%5Bserver name] /_layouts/15/appprincipals.aspx
Apps have two different ways to retrieve their App identity:
· From Azure Access Control Service (ACS) over the OAuth protocol, see section “OAuth” for more information.
· From a High Trust Relationship (via S2S trust and certificates), see section “High-Trust Apps” for more information.
NOTE The notion of applications having their own identity recognized apart from user identities sets OAuth and S2S apart from other authorization protocols.
Every App is shipped with an App manifest file (an XML file called appmanifest.xml), which contains essential information about the App and its configuration. The following is considered to be the essential information about Apps:
· The App Client ID
· The App display name
· The App domain
· The App version number
Then, there is information in the App manifest pertaining to its configuration, such as:
· The URL of the App start page, the page that opens when the App is started. This can be any page located anywhere, the sole requirement is that the file type of the start page must be able to support HTTP POST requests (so, for example, images as start pages are out of the question, but ASP.NET or PHP pages are perfectly acceptable).
· A list of App prerequisites (for example, certain features or services that just have to be there in order for the App to be able to run correctly).
· App scope, authorization policies, and permission requests for that scope.
· Other properties such as supported locales (i.e., en-US, nl-NL).
The following fragment shows some example content of an App manifest file:
<?xml version=”1.0″ encoding=”utf-8″ ?>
<App xmlns=”http://schemas.microsoft.com/sharepoint/2012/app/manifest”
ProductID=”{ff01dda0-712e-62c4-c224-d4d522d2286d}”
Version=”1.0.0.0″
SharePointMinVersion=”15.0.0.0″
Name=”TheCustomApp”
>
<Properties>
<Title>The Custom App</Title>
<StartPage>~remoteAppUrl /default.aspx/?SPHostUrl={HostUrl}</StartPage>
<SupportedLocales>
<SupportedLocale CultureName=”en-US” />
<SupportedLocale CultureName=”nl-NL” />
</SupportedLocales>
</Properties>
<AppPermissionRequests AllowAppOnlyPolicy=”true”>
<AppPermissionRequest Scope=”http://sharepoint/content/sitecollection/web/list” Right=”Write”/>
</AppPermissionRequests>
<AppPrincipal>
<RemoteWebApplication ClientId=”2ab64d52-6b4d-688f-e44f-bb453baad652″ />
</AppPrincipal>
</App>
Note You may have noticed that there is some magic surrounding the URLs of the start page and permission request. The format of the start page looked like this: ~remoteAppUrl/default.aspx/?SPHostUrl={HostUrl}, and as you can see it contains some tokens that can be used within the URLs. ~remoteAppUrl stands for the URL of the remote web application in an App for SharePoint, {HostUrl} is replaced by the URL of the host web of an App for SharePoint. See http://msdn.microsoft.com/en-us/library/jj163816(v=office.15).aspx for an overview of the available tokens. The format of the URI of the permission request in the <AppPermissionRequest> element was in this form: http:// sharepoint/content/sitecollection/web/list. This is because permission requests are made without intimate knowledge of the topology of the SharePoint site collection where the App gets installed. So, instead of specifying a specific SharePoint URL, you need to specify a generic URI. To complete the discussion about tokens and URL formatting, see http://msdn.microsoft.com/en-us/library/ms431831(v=office.15).aspx for an overview of generic SharePoint URL tokens.
When an App is installed within a SharePoint environment, this environment is called the Host. Once an App gets installed in a SharePoint site, this site is called the Host Web. It’s possible that the App needs a place to store specific App resources or declarative items, such as lists, site pages, CSS files, and JavaScript files. These resources won’t be added to the Host Web, they’re added to a dedicated child site called the App Web. If an App doesn’t contain any resources, no App Web will be created.
The end user who is installing the App is shown which permissions the App wants, based on the permissions requested in the App manifest file, and then it’s up to the end user to decide if the App is granted those permissions. This is an all or nothing thing: Apps can choose from one of the predefined permission sets and can’t create custom ones, and end users either grant the App all of the permissions requested or none at all.
Note There are multiple events that lead to a change in permissions assigned to Apps: the App is installed by the site administrator, the App is explicitly granted permission by a tenant administrator or site administrator, the end user gives consent, or the App is removed.
After granting permissions to Apps, you can’t modify them, so that the App won’t be broken because of it. Of course, it is possible to revoke App permissions, see section “Uninstalling Apps” for more information. End users can only grant permissions they actually have, or the installation fails.
Important At this point, the App has made clear which permissions it needs, but also to which scope those permissions apply and which authorization policy will be used. Under water, it’s the App principal that gets associated to specific SharePoint permissions and rights.
The scopes to which App permissions can apply are these:
· SharePoint Site collection, permissions apply to the entire site collection (including all children, such as sites, lists, and list items) where the App is installed. In the App manifest file, this scope is represented using the following URI: http://sharepoint/content/sitecollection/.
· SharePoint site, permissions apply to the entire SharePoint site (including all children, such as lists, and list items) where the App is installed. In the App manifest file, this scope is represented using the following URI: http://sharepoint/content/sitecollection/web. If you want to use a site-scoped App, you need to install it for each and every SharePoint site where you want to use the App.
· SharePoint list, permissions apply to the entire list (including all children, such as list items) where the App is installed. In the App manifest file, this scope is represented using the following URI: http://sharepoint/content/sitecollection/web/list.
· Tenancy, permissions apply to the tenancy where the App is installed. In the App manifest file, this scope is represented using the following URI: http://sharepoint/content/tenant. Tenancy-scoped Apps are installed in a single App Catalog site and are available for use in multiple host webs (as opposed to site-scoped Apps). This means that every host web accesses one single App instance, which centralizes App management.
· Feature, scopes can apply to specific SharePoint features, such as Search, Business Connectivity Services (BCS), and Project Server 2013. All other URIs referred to content stored in the SharePoint content database only. The way feature URIs look depends upon the specific feature.
Important All App permissions that were mentioned apply to resources in the SharePoint host environment. By default, Apps get Full Control rights over their corresponding App web.
The site collection, site, list, and feature scopes are probably familiar to you. The Tenancy scope may require a little further explanation. A SharePoint 2013 tenancy is a set of site collections in either a SharePoint farm or SharePoint Online. Usually, a tenancy relates to a single customer in a SharePoint environment used by multiple customers. A tenancy can be an entire site collection, or a subset of them, and the format of a tenancy URL looks like this (the content part reflects the fact that you’re accessing content stored in the SharePoint content database): http://sharepoint/content/tenant.
More Info For more information about tenancies, please refer to http://msdn.microsoft.com/en-us/library/fp179896(v=office.15).aspx .
Next to App permissions and scope, App authorization policies are a key factor in determining what Apps can do. The following App authorization policies are available:
· User and App policy, both the App as well as the current SharePoint end user have to have sufficient permissions in SharePoint to execute an operation. This policy is mandatory for SharePoint Store Apps that call back to SharePoint resources.
· App Only, only the App needs to have sufficient permissions to execute an operation. This is a good policy when the App is not impersonating end user actions in any way. The end user installing the App must have site collection administrator rights in order to grant the App the use of this policy. All operations executed by Apps under this policy run under the special SHAREPOINT\APP account.
Note Apps that do not make OAuth authenticated calls can’t use this policy. In addition, some APIs, such as the Search API, require the presence of a user context and therefore won’t run under the App Only policy.
· User Only, the current SharePoint end user needs to have sufficient permissions in order for the App to complete an operation successfully. This is a good policy when end user resources are accessed.
Each App can choose between four different, predefined permission sets to access SharePoint content:
· Read-Only, these rights correspond to the end user Reader default permission level. This allows an App to view pages, list items, and download documents.
· Write, these rights correspond to the end user Contributor default permission level. This allows an App to view, add, update, and delete list and library items.
· Manage, these rights correspond to the end user Designer default permission level. This allows an App to view, add, update, delete, approve, and customize items or pages within a SharePoint site.
· FullControl, these rights correspond to the end user Full Control default permission level. This allows an App to have full control within the specified scope.
Important See http://technet.microsoft.com/en-us/library/jj219576(office.15).aspx[ for a detailed overview of the exact permissions that are included in each set. It’s important to note that separate SharePoint features can have separate scopes and available permission sets. For example, the scope for Business Connectivity Services (BCS) applies to BCS connections, and you can only assign Apps Read permissions. For Search, there’s a permission set that won’t be found in the standard collection of permission sets: the QueryAsUserIgnoreAppPrincipal permission set. See http://msdn.microsoft.com/en-us/library/fp142383(v=office.15).aspx for more details.
When Apps are stored in the cloud, their App Manifest data is stored in ACS. To make it possible to install such Apps, SharePoint 2013 introduces a new service application called the Apps Service Application. The main responsibility of the Apps Service Application is to store basic information about Apps, their related App licenses (when Apps are downloaded from the SharePoint Store) and related App permissions.
Note The place where this information is stored is also known as the Storefront. First of all, you can use the Storefront to view all Apps in the SharePoint Store (so that SharePoint users don’t have to go to Office.com themselves). All Apps that are downloaded from the SharePoint Store, or from other places that will be discussed shortly, are persisted in this Storefront. Access to the Storefront is not just restricted to site collection administrators; in principle every site user can be granted access to it.
The Apps Service Application is consulted each time an App is accessed to ensure that the end user has sufficient permissions to make such a request. At this point, you have already learned that you can get Apps from the SharePoint Store, but there are several other options as well. Here’s the overview of the available options when it comes to hosting (and/or retrieving) SharePoint Apps:
· Submit your App to the SharePoint Store, also located in the cloud.
· Place the App in an isolated SharePoint site, but within your SharePoint farm.
· Place the App outside your SharePoint farm, on a dedicated self-hosted application server.
· Place the App outside your SharePoint farm, in the cloud (Azure).
· No hosting, of traditional SharePoint artifacts
Another common way of dividing SharePoint Apps models is this:
· SharePoint hosted
· Cloud (or remote) hosted
You will also find the hosting models divided in a different way: no hosting, SharePoint hosted (where the Apps run inside SharePoint), and provider hosted (cloud or dedicated application server).
App – SharePoint Communication
Before we dive into the different hosting models, it’s interesting to take a look at how exactly Apps communicate with SharePoint, since Apps will typically run outside of the SharePoint environment that are using the Apps. First thing you need to know is that Apps won’t be able to use the SharePoint server object model at all – even when the App runs in its own isolated SharePoint site (and therefore, runs on a SharePoint server). This is a good thing where it concerns the stability of your SharePoint farm.
In 2013, the only means by which Apps can interact with SharePoint have to come from the several client APIs offered by SharePoint. Apps will be more reliant on client-side technology such as JavaScript, jQuery (a very popular JavaScript library), and Ajax techniques to communicate with SharePoint leveraging either SharePoint’s client-side object model (or CSOM, pronounced ceesom) or REST API (also known as OData). The SharePoint client object model comes in different flavors:
1. Managed client object model, which can leveraged by .NET applications (such as a console application or WPF client) or PowerShell script to communicate with SharePoint.
2. Mobile client object model, which can be leveraged by Windows Phone devices.
3. JavaScript client object model, which can be leveraged by JavaScript code to communicate with SharePoint.
4. Silverlight client object model, which can be leveraged by Silverlight applications to communicate with SharePoint.
Since Apps are so reliant on CSOM, the coverage of SharePoint functionality has been extended a great deal. Starting in SharePoint 2013, new APIs are also available within CSOM, such as User Profiles, Search, Taxonomy, Publishing, Workflow, Analytics, E-Discovery, IRM and BCS.
In all forms of the client object model, client-side calls will be made to the CSOM end point, a Windows Communication Foundation (WCF) service called client.svc. In SharePoint 2013, client.svc is extended with REST capabilities (implemented in accordance with the OData protocol) so that it, as opposed to SharePoint 2010, now not only supports the fixed amount of entry points reserved for the different kind of CSOM flavors, but also has direct support of REST clients. In addition, all the CSOM calls can also be made via REST. REST calls will be made via URLs of the following format: [sharepoint url]/_api. Under the cover, these requests will be redirected to client.svc.
Note The new CSOM capabilities overlap with the previous REST endpoint ListData.svc. While new applications should be created using the new CSOM/REST capabilities, old client applications leveraging ListData.svc will still work in SharePoint 2013. In 2013, the new REST API always uses _api in the URL that accesses a REST end point. The following is an example of the format of a REST API call that requests the title of a SharePoint root web: http://ASharePointSiteColl/_api/ASharePointSite/title.
All this results in a major shift for App developers. Where in the previous versions of SharePoint most code was written in C#, or at least server-side code, now App developers will have to shift and write a lot more of their business logic using JavaScript. Microsoft did take care to make these client-side APIs a lot more powerful than they were in the previous version.
As an alternative, applications hosted on a dedicated application server or in the cloud won’t be able to leverage the SharePoint server-side object model, but will be able to leverage the managed client object model to let the App server-side code communicate with SharePoint.
Best Practices It would be a fair assessment if one would state that the App model is best suited for solutions that are mainly oriented towards HTML and JavaScript. From the administrator’s perspective, you can’t overlook the fact that Apps will bring along a lot of additional web traffic, much of it consisting of large blocks of JSON and XML data.
As you have seen, there are a lot of different options when it comes to communicating with SharePoint. Let’s finish this section with some closing advice about when to which option, as this will help you validate design choices made by App developers:
· Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server separated by a firewall benefit most from using the JavaScript client object model.
· Server-side code in Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server but not separated by a firewall mainly benefit from using the managed client object model, but the Silverlight client object model, JavaScript client object model or REST are also options.
· Apps hosted on non-Microsoft technology (more on this later) will need to use REST.
· Windows phone Apps need to use the mobile client object model.
· If an App contains a Silverlight application, it should use the Silverlight client object model.
· Office Apps that also work with SharePoint need to use the JavaScript client object model.
Note Keep track of further insights into best practices concerning the question when it makes sense to use a client API, please visit the following TechNet Wiki page: http://social.technet.microsoft.com/wiki/contents/articles/13637.sharepoint-2013-best-practices-what-client-api-should-you-choose-when-building-apps.aspx.
More Info The following MSDN article contains more information about important aspects of the App for SharePoint architecture and development landscape: http://msdn.microsoft.com/en-us/library/fp179922(v=office.15).aspx.
App Hosting Options
In the next sections, you will learn about the various App Hosting options, such as Cloud hosted, Provider hosted, and SharePoint hosted. At this point, it’s important to understand that the various App Hosting options are not mutually exclusive: it’s perfectly possible that Apps include various components that are hosted differently. For example, think of an App that contains SharePoint hosted components as well as Cloud hosted components.
Apps in the SharePoint Store
Only ISVs will go through the trouble of going to the SharePoint Store submission process, which requires adding Apps to the Office AppHub and undergoing an approval process. Once Apps are approved, they can be found in the SharePoint Store via the SharePoint Storefront in your SharePoint farm and used. The life cycle of a SharePoint Store App looks like this:
1. The ISV or individual software developer creates an App.
2. The App is entered in the official submission process and sent to the Office AppHub.
3. Microsoft validates each and every Apps and checks for potential issues about security, performance, any threats the App might pose to the SharePoint farm, and such.
4. If Microsoft approves and certifies the App, it becomes available in the SharePoint Store (at Office.com).
5. Both your own on premises SharePoint farm and SharePoint Online (your farm in the cloud) have a Storefront. The Storefront is responsible for integrating the SharePoint Store with your own SharePoint environment in a way that is completely transparent for your end users. Storefront uses a set of web services to communicate with the SharePoint Store.
6. End users will leverage the SharePoint UI and use Storefront to retrieve information about Apps that are actually hosted in the SharePoint Store. Please note that both administrators and end users can be allowed to have access to Storefront.
7. At that point, end users can actually buy or get (if the App is free) the App of their choice. By doing this, the App becomes available within SharePoint by hosting it either in the cloud, on a dedicate application server, or as an AppWeb within the SharePoint farm. After that, the App can be executed.
8. Every time an App gets executed, the Apps Management Service will check that the end user has the sufficient amount of permissions to do so. The Apps Management Service will also check if license requirements for that particular App have been fulfilled.
9. If the App is shipped under a licensing model, the App will contact the SharePoint Store at Office.com to validate if the end user is allowed to use the App.
10. The App UI will be generated and rendered by the App host (cloud, application server, or AppWeb).
The life cycle for a custom App that isn’t submitted to the SharePoint Store (a situation you’ll typically find for in-house development scenarios) is a little bit different. Instead of submitting the App to the SharePoint Store, it will be packaged and the SharePoint administrator will manually add that package to a Corporate Catalog. After adding the App to the Corporate Catalog, it too will become available via Storefront, where it can be selected by the end user. Figure 1 clarifies the App lifecycle as discussed so far:
Figure 1 The SharePoint App lifecycle: from App submission to usage.
Now let’s look at more detail at the architecture of what happens once the App is installed and ready for use.
1. The end user wants to use a specific App.
2. This request is received by the Web Front-End (WFE).
3. The WFE, via its service application proxy, calls the Apps Management Service.
4. The Apps Management Service decides what information regarding permissions and licenses needs to be retrieved from the database, but doesn’t retrieve this information itself. Instead, it returns control to the WFE. For performance reasons, the WFE caches the location of the Apps Management database. Therefore, it is more efficient if the WFE, and not the Apps Management Service, retrieves the required information.
5. The WFE retrieves information surrounding App permissions and licensing from the Apps Management database.
This is the normal workflow of a normal App request, which is displayed in Figure 2. If you manage Apps (for example, by using the administration UI or PowerShell commands) things work a little differently. Such administrative requests are directed directly against the Apps Management Service, instead of to the WFE, as was the case during a normal App request. Again, to optimize performance, the Apps Management Service won’t interact with its service application database, but will leave that to the WFE.
Figure 2 A depiction of the general SharePoint App communication flow.
Apps in an isolated SharePoint site
In this hosting option, Apps are still hosted on-premises within SharePoint, although they run completely isolated. This type of App is generally called a SharePoint Hosted App and comes in two flavors:
· AppWebs
· App Parts
Let’s start with a discussion of AppWebs. During this hosting mode, whenever an App is installed, a new SharePoint site is created that will house the App. This SharePoint site is called the AppWeb. AppWebs can’t be modified using either SharePoint Designer or the browser UI, to make sure end users are unable to interfere with the correct running of the App.
AppWebs need to be created as sub sites of the SharePoint site collection, but AppWebs don’t have to be immediate children of the root site. AppWebs provide their own chrome and contextual elements, but the permissions are provided by the parent web and the parent context is also passed to the AppWeb so that the client object model (CSOM) can make calls to resources located in the parent site, thus making it easy for the App to interact with SharePoint. However, despite their ability to communicate with their parent web sites, AppWebs can’t communicate with other AppWebs. AppWebs are made visible in the UI via an IFrame in the parent site.
The other flavor of SharePoint-hosted apps is the App part, also known as a Client Web Part. The App part is nothing more than an IFrame which can be added to any page and provides access to some remote resource.
Apps on an Application Server
Microsoft Support has found that the most common reason for issues in farms is caused by custom code. The greatest thing about hosting Apps on dedicated application servers is that it’s guaranteed that your SharePoint farm won’t be harmed anymore by custom code, while still leaving you in full control of the environment. Such Apps are the first example of Provider-hosted Apps. The Apps are stand-alone applications that run completely outside of your SharePoint farm, and SharePoint is completely technology-agnostic as far as these Apps go. This means, Apps can be hosted on any technology, such as application servers running on components of the LAMP stack (Linux, Apache, MySQL, and PHP).
Best Practices This particular feature was hailed enthusiastically by developers. I don’t share the sentiment. Although in itself it’s great to have the flexibility to use any flavor of application server you like, in reality I’ve found that this type of platform independence is almost never an issue. If you’re an avid Java or PHP developer planning to build Apps, you’ll find that you still have to have intimate knowledge of SharePoint technology and development models, as well as access to SharePoint-friendly tools. I’m convinced that the share of skilled Java and SharePoint developers is pretty limited. In addition, some people have even predicted the end of the era of SharePoint developers, since now every ASP.NET developer will be able to create Apps as well. I think this is a wrong conclusion, for exactly the same reasons. If you want to develop SharePoint solutions, you need the knowledge about the platform. You simply can’t do that, while avoiding becoming a “SharePoint” developer.
Apps on a dedicated application server are the first example of provider-hosted Apps. The interesting thing about provider-hosted Apps is that as soon as end user clicks on the App icon in the UI, the end user gets redirected to a destination web site located on the application server. The App can then leverage a set of available JavaScript libraries that enable the retrieval and display of basic chrome elements from the referring SharePoint site (including the basic stylesheet of that referring site). Apps can interact with the referring SharePoint site and execute callbacks to the referring SharePoint site collection and web resources. Apps will rely heavily on JavaScript to execute asynchronous JavaScript client object model calls and/or REST calls that allow the App to communicate with the SharePoint referral context.
In addition to running Apps on a dedicated application server, on-premises, it’s also possible to host Apps on dedicated remote application servers, under the control of a 3rd party vendor. The biggest advantage of running Apps on dedicated application servers is twofold: not only is it guaranteed that executing custom Apps won’t affect your SharePoint farm directly, if custom Apps don’t perform well enough you don’t have to scale SharePoint anymore: it’s sufficient to just scale the App causing trouble. From a management perspective, this is truly a great thing.
Apps in the Cloud
In essence, this option is identical to hosting Apps on a dedicated application server, with the big difference that in this scenario Apps are hosted in the cloud (Azure), within the Azure Web role. Therefore, this type of Apps is called Azure Hosted Apps. Azure Hosted Apps won’t be hosted in a dedicated cloud space provided by the App developer and shared by all customers. During installation, every App is installed in the cloud space of the customer: it will create Web, worker, and database roles as required. The App developer/vendor can ensure that the infrastructure that is external to SharePoint but required for the App is created in Azure during the App deployment process, but the customer is responsible for paying the costs associated to such an infrastructure. Because of this, these types of Apps are also known as Azure auto-provisioned Apps.
No Hosting
It may come as a bit of a surprise, but SharePoint Apps also come in a flavor where they don’t have to be hosted at all. In this case, it concerns Apps that contain classic SharePoint artifacts, such as content types, fields based on existing field types (but not custom field types or CFTs) such as the Calculated and Computed field types, remote site pages that can also include built-in SharePoint web parts, remote event receivers, list templates, and web templates. Such Apps can be deployed directly into the target SharePoint site.
What Apps can’t do
SharePoint Apps are quite powerful, but you need to be aware that there are certain things you can’t do. This section provides an overview of App limitations.
Best Practices Now we have arrived at what I think are two of the biggest drawbacks of the current App model: although Apps can use a basic stylesheet of the referring site, so far it doesn’t look as though Apps provide a seamless UI experience, but customers will expect nothing less. A second thing is that Apps, as opposed to previous versions that were dominated by server-side, object-oriented code, will now for a large part be written in JavaScript. It’s easily possible that this will lead to spaghetti code. It remains to be seen how App developers will respond to these challenges.
Within Apps, you can’t:
· Create custom web parts, although Apps can provide similar functionality in the form of site pages containing SharePoint web parts or App parts that run on a SharePoint site page.
· Use SharePoint server-side object model event receivers. Instead, Apps can handle remote events and App events (see section “Handling events in Apps for SharePoint” for more information).
· Deploy Custom Field Types. However, it is possible to deploy new fields based on existing field types.
· Deploy application pages.
· Call the SharePoint server-side object model.
· Access SharePoint components located on another SharePoint site.
· Deploy master pages, custom site definitions and themes.
· Deploy custom action groups and custom action hiding.
· Deploy custom user controls (.ascx files).
· Deploy delegate controls.
· Communicate with other Apps (but can share access to a list located in a parent SharePoint site).
Best Practices I expect that the first question companies will ask themselves when deciding to build Apps (or not) is this: will we able to build this App using CSOM? If the answer is yes, building a feature as an App becomes a lot more attractive.
Handling events in Apps for SharePoint
Apps know how to communicate with the referring SharePoint site and site collection via the JavaScript client object model or the REST API, but you may be surprised to find out that Apps are also able to subscribe and respond to several SharePoint events. App developers can create remote events receivers and App event receivers (both via WCF) to handle events:
· Remote event receivers handle events that occur within the life cycle of a SharePoint artifact, such as a SharePoint list item, SharePoint list, or SharePoint site. They function in a way very similar to their SharePoint server object model event counter parts, except for the fact that they work remotely. Events that occur before the actual action occurs can even prevent certain events from happening, such as the deletion of important list items. One way events always happen after the action has occurred, and can only be used to observe what has happened to the SharePoint environment.
· App event receivers deal with events within the App life cycle itself, most notably App installing, upgrading and App uninstalling events. Such event receivers are very useful for cleaning up App changes that affect the SharePoint environment, sending notifications, and logging purposes.
As part of the deployment deliverables, you should demand that App developers provide sufficient error handling within App event receivers. Failing to do so may lead to Apps that can’t be installed, upgraded, or uninstalled due to unhandled exceptions within App event receivers. The next code fragment shows a part of an installation file of a SharePoint App that registers an event receiver that responds when new items are added to a SharePoint announcements list:
<?xml version=”1.0″ encoding=”utf-8″?>
<Elements xmlns=”http://schemas.microsoft.com/sharepoint/”>
<Receivers ListTemplateId=”104″>
<Receiver>
<Name>RemoteEventReceiver1ItemAdding</Name>
<Type>ItemAdding</Type>
<SequenceNumber>10000</SequenceNumber>
<Url>~remoteAppUrl/RemoteEventReceiver.svc</Url>
</Receiver>
</Receivers>
</Elements>
Understanding SharePoint Customization Models
Now that you have learned more about the Apps customization model that makes it possible that SharePoint is extended with customizations, it’s a good idea to contrast that model against the other available development models for customizing SharePoint. Let’s start out by recapping what models are there:
· Farm solutions
· Sandboxed solutions
· SharePoint Apps
Farm Solutions
Farm solutions (.wsp files, a specific flavor of .cab files) are deployed to the Global Assembly Cache or web application Bin folder of every SharePoint Web Front-End (WFE) in the farm. These solutions typically have a wide range of possibilities as far as executing server-side code goes, and can be very powerful. Because of that, they also have the potential to destabilize the SharePoint farm in a direct way.
Security Alert In a lot of the resources I’ve seen about SharePoint 2013 Apps, the terms Farm solution and Full Trust solution are used interchangeably (even in MSDN documentation), implying that the code in Farm Solutions always runs under full trust. Don’t make this mistake. The capabilities of farm solutions can be limited to a very fine-grained level, but do require IT Pros to have a working knowledge of Code Access Security (CAS). In real life, there are plenty of companies that have taken the shortcut by letting farm solutions run under full trust. This goes against best practices and is not a trait of farm solutions per se.
However, be aware of a breaking change in SharePoint 2013: the default CAS policy that is used in this version is Full Trust (instead of the safe wss_minimal policy that allowed solutions to perform a very limited set of operations, like it used to be). In the web.config file it’s defined like this:
<trust level=”Full” originUrl=”” legacyCasModel=”true” />
This means that by default, a SharePoint 2013 farm solution will run under full trust, and allows a solution to do pretty much everything it wants. In effect, by default this also makes every farm solution a full trust solution. At the time of writing, it wasn’t completely clear what the reasoning behind this break in security best practices is and if it’s possible to run SharePoint 2013 under a different trust model without breaking. One thing that is quite clear at this point is that lots of companies found it hard to deal with security policies and opted for the easy way out by running their SharePoint farms under Full Trust anyway.
Sandboxed Solutions
Sandboxed solutions (.wsp files, a specific flavor of .cab files) run in isolation in a separate process called the User Code Service, running under a very strict CAS policy that does allow you to make service calls via full trust proxy services, as well as client-side web service calls (such as WCF services). What’s more, Sandboxed solutions run under a resource throttling mechanism that allows IT Pros to assign points of server resources that a solution is allowed to spend. This system allows for the automatic shutdown of solutions that spend too many server resources. All in all, although Sandboxed solutions run within your SharePoint farm, they are designed for safety, are intentionally limited in their capabilities, and have a minimal impact on their environment. Because of that, in SharePoint 2010, it was a recommended best practice to build Sandboxed solutions whenever you could. However, in the real world, most people found Sandboxed solutions to limited to be very useful. Therefore, Sandboxed solutions haven’t become as popular as was anticipated.
Important Although Sandboxed solutions are still supported; they are deprecated in SharePoint 2013. This means this type of solution probably isn’t supported in SharePoint vNext anymore, and best practices dictate that it’s better to avoid building new sandboxed solutions in SharePoint 2013. The development community won’t mind this decision as much.
App Solutions
We have talked about Apps, but let’s recap for a moment. Apps can run outside of your SharePoint farm, outside of any SharePoint technology, even outside of Microsoft technology, and if you want, in the cloud (Azure). Apps can do this in a safe way by leveraging the OAuth and S2S security protocols and still provide the functionality by leveraging the extended and improved client object model and/or REST (OData) API.
Note App solutions are deployed in the form of .spapp files. Each App package file itself contains a .wsp file (a cab file of the SharePoint brand) full of App resources.
What Apps typically can’t do is execute server-side code. The Apps model is by far the model that has the littlest impact on your SharePoint farm as it can’t affect it directly. However, as of yet, it is more difficult to integrate it with your SharePoint farm and also requires an understanding of the architectural ramifications of the App model.
Best Practices It’s an interesting question what to do when you’re still doing SharePoint 2010 development, and expect that one day in the undefined future you’ll be migrating to SharePoint 2013. Since SharePoint 2010 Best Practices dictate to buld Sandboxed solutions whenever you can, there’s a clear conflict because SharePoint 2013 Best Practices advise to build Apps wherever possible. What’s more, SharePoint 2013 deprecates Sandboxed solutions. One way to approach this problem is to go ahead and build Sandboxed solutions in a way that makes them easy to port to the App model. This would mean that they should be designed in such a way, that they leverage either the client object model or SharePoint REST interface a lot, and refrain from using the server-side object model. I would advise differently. You have to realize that both the client object model and the SharePoint REST interface have become a lot more powerful in SharePoint 2013. Therefore, you can create lots of headaches by trying to create the same solutions for SharePoint 2010 and will most likely end up with higher initial development costs. Instead, build Sandboxed solutions like you’re used to do and remember that they will continue to run effortlessly in SharePoint 2013 environments. If your solution survives until SharePoint vNext, invest in an upgrade at that point in time.
Comparing SharePoint Customization Models
You have learned about the various models available for customizing SharePoint, but now the question remains: when should you prefer which model? Let’s start with this: in SharePoint 2013 it’s a best practice to create SharePoint Apps whenever possible, in lieu of the other development models: Farm solutions and Sandbox solutions, since Apps can’t hurt your SharePoint farm directly. The things you could do with Sandboxed solutions can also be achieved via Apps, in a better way, so it should always be avoidable to build Sandbox solutions. The use of Farm solutions however, can’t be avoided completely. The following table provides detailed guidance on how to make the decision of which model to choose.
table 1 Comparison of SharePoint Customization Models
When to use/Customization model
Sandboxed solutions
SharePoint Apps
Farm solutions
Is it a best practice?
Sandboxed solutions are still supported but deprecated. Therefore, it’s unadvisable to build new sandboxed solutions.
For SharePoint 2013, creating SharePoint Apps is the best practice. You should choose Apps as a way of customizing your SharePoint environment if at all possible.
Create farm solutions when you need to do something that can’t be done using SharePoint Apps. See section “What Apps can’t do” for more information.
Does it have the ability to run server-side code?
Runs under a strict CAS policy and is limited in what it can do.
When Apps are hosted in an isolated SharePoint site, no server-side code whatsoever is allowed. The use of the SharePoint server-side object model code is never allowed within Apps.
Can run full trust code or under a fine grained custom CAS policy. Provides all the flexibility and power you could wish for.
How much impact does it have on server resources?
Run under an advanced resource management system that allows resource point allocation and automatic shutdown for troublesome solutions. In this regard, sandboxed solutions provide the most advanced capabilities, although they still run inside your SharePoint farm.
Apps run isolated from a SharePoint farm, but can have an indirect impact by leveraging the client object model.
Can impact SharePoint server-farm stability directly.
Is it able to runs cross-domain?
No, and there’s no need to since code runs within the SharePoint farm.
Yes, this provides a very interesting way to distribute server loads.
No, and there’s no need to since code runs within the SharePoint farm.
How about the efficiency and performance of the solution?
Runs on the server farm, but in a dedicated isolated process. The sandbox architecture provides overhead.
Apps hosted on separate app servers (even cross-domain) or in the cloud may cause considerable communication overhead. Apps can leverage the CSOM which has built-in task batching capabilities, which relieves this problem to a certain degree.
Very efficient.
How safe is it?
Very safe.
Apps rely on OAuth 2.0. OAuth is a protocol designed for safety, but App architecture offers a bigger attack surface compared to the other models. The Apps Updating mechanism has received criticism, since full control Apps that get updated are not subject to an extensive approval process (as long as the App manifest doesn’t change). In theory, this allows Full Control Apps to start misbehaving after receiving an update. In reality, App vendors can be traced easily via the SharePoint Store, which makes them easily reachable in case of losses caused by malicious Apps.
Can be very safe, but this requires administrators to put thought and effort in the CAS policies they allow to run.
Manageability
Easy to manage within the SharePoint farm. The technical infrastructure of sandboxed solutions is more complicated compared to farm solutions.
Can even be managed on a dedicated environment without SharePoint. Dedicated app admins can take care of this. The technical infrastructure of SharePoint Apps is without a doubt the most difficult to understand of all three customization models.
Easy to manage within the SharePoint farm. The technical infrastructure of farm solutions is the easiest to understand.
Cloud Support
Yes, sandboxed solutions are supported in Office 365.
Yes, Apps are supported in Office 365. What’s more, they have inherent support for the cloud (Azure).
No, on-premises only.
Maturity
There has been only one version of sandboxed solutions. After that, this technology has been deprecated. Therefore, the maturity and success of this technology is very limited.
The Apps model is completely new and therefore needs to mature.
Farm solutions have been around for a long and provide the most mature of all customization models. However, farm solutions have been known, because of their power and the fact that they run inside your SharePoint farm, to destabilize SharePoint farm deployments.
Audience
Available within Office 365 and on-premises SharePoint farm.
An immense audience can be reached easily by adding Apps to the SharePoint Store. Apps can be used in Office 365 as well as on-premises SharePoint farms.
Only available within your on-premises SharePoint farm.
Best Practices As a general rule of thumb, solutions targeted towards administrators don’t lend themselves well to be implemented as Apps. It seems fair to state that Apps are end-user focused almost exclusively.
The overview provided by this table is subject to change, since further insights can impact the comparison. Track the following TechNet Wiki page for a recent comparison of SharePoint customization models: http://social.technet.microsoft.com/wiki/contents/articles/13373.sharepoint-2013-what-to-do-farm-solution-vs-sandbox-vs-app.aspx. The following MSDN article compares Apps with SharePoint solutions: http://msdn.microsoft.com/en-us/library/office/apps/jj163114(v=office.15).
Understanding Security Protocols: OAuth and S2S
As a way of obtaining an App identity that can be used for authentication and authorization purposes, SharePoint Apps are able to leverage two different security protocols: OAuth and S2S. OAuth is the only security protocol supported in Office 365, which means that SharePoint Online will only be able to use Apps leveraging OAuth. By default, on-premises installations don’t contain an OAuth provider which makes S2S the de facto standard for on-premises App deployments.
High-Trust Apps
High-Trust Apps are hosted on on-premises Application servers, as opposed to the Office 365 model where Apps use the ACS to be able to support OAuth and obtain their App identities that way. ACS acts as an authorization service that needs to be trusted by both content server (SharePoint) and client application (SharePoint App). High-Trust Apps are a good solution for on-premises scenarios, because they make the use of ACS obsolete. Instead, High-Trust Apps leverage the S2S protocol to obtain App identities. High-Trust Apps are called this way because they are trusted to assert any user identity that they want by creating the user part of the access token. The term High-Trust App doesn’t mean that such Apps have Full Trust. App permissions have to be requested and granted separately, like Apps leveraging OAuth. In fact, S2S is also called application to application OAuth, but is not an official part of the OAuth specification, as you will learn later.
Best Practices Theoretically, it is possible for on-premise environments to use ACS. In order to do so, you will have to configure this explicitly, although you have to realize you won’t be able to use ACS directly. Instead, you need to acquire an Office 365 tenancy to manage security principal accounts, set up a trust from the on-premises SharePoint farm to the Office 365 tenancy, and go thro