Microsoft designed the SharePoint app model to work in the Office 365 environment as well as within on-premises farms. However, developing for Office
365 introduces a few important new concepts that will be unfamiliar to
many experienced SharePoint developers. One of the new concepts that is
essential to the development of SharePoint apps is a SharePoint tenancy.
A SharePoint tenancy is a set of site collections that are
configured and administrated as a unit. When a new customer establishes
an Office 365 account to host its SharePoint sites, the Office 365
environment creates a new tenancy. The customer’s business users that
access the tenancy are known (not surprisingly) as tenants.
When the Office 365 environment creates a new tenancy for a
customer, it creates an administrative site collection which is
accessible to users who have been configured to play the role of a tenant administrator.
A tenant administrator can create additional site collections and
configure the set of services that are available to all the sites
running within the tenancy.
The concept of tenancies was first introduced in
SharePoint 2010 to support hosting environments such as Office 365.
Although the creation and use of tenancies is essential to the Office
365 environment, their use has not been widely adopted in
on-premises farms. This is primarily due to the fact that SharePoint
farm administrators can create site collections and configure the
services available to users within the scope of a web application.
The architecture of the SharePoint app model requires that apps are
always installed and run within the context of a specific tenancy. This
can be a bit confusing for scenarios in which you want to install
SharePoint apps in an on-premises farm that doesn’t involve the
explicit creation of tenancies. However, SharePoint 2013 is able to
support installing and running SharePoint apps in on-premises farms by
transparently creating a farm-wide tenancy behind the scenes that is
known as the default tenancy.
1. Working with app service applications
SharePoint 2013 relies on two service applications to manage the
environment that supports SharePoint apps. The first service
application is the App Management Service, which is new to SharePoint
2013. The second service application is the Site Subscriptions Settings
Service, which was introduced in SharePoint 2010. A high-level view of
a SharePoint 2013 farm running these two service applications is shown
in Figure 1.
The App
Management Service has its own database that is used to store the
configuration details for apps as they are installed and configured.
The App Management Service is also responsible for tracking other types
of app-specific configuration data that deals with app security
principals, app permissions, and app licensing.
The Site Subscription Settings Service takes on the responsibility of managing
tenancies. Each time a new tenancy is created, this service adds
configuration data for it in its own database. The Site Subscription
Settings Service is particularly important to the SharePoint app model
due to the requirement that SharePoint apps must always be installed
and run within the context of a specific tenancy.
When you are working within the Office 365 environment, you never have to worry about creating
or configuring these two service applications, because they are
entirely managed behind the scenes. However, things are different when
you want to configure support for SharePoint apps in an on-premises
farm. In particular, you must explicitly create an instance of both the
App Management Service and the Site Subscription Settings Service.
Creating an
instance of App Management Service is easier because it can be done by
hand via the Central Administration or by using the Farm Creation Wizard. Creating an instance
of Site Subscription Settings Service is a bit trickier because it must
be done by using Windows PowerShell. However, when you create an
instance of the Site Subscription Settings Service by using Windows
PowerShell, it automatically creates the default tenancy which then
makes it possible to install SharePoint apps in sites throughout the
farm.
2. Understanding app installation scopes
A SharePoint app
must be installed before it can be made available to users. When you
install a SharePoint app, you must install it within the context of a
target web. Once the app has been installed, users can then launch the
app and begin to use it. The site from which an app has been launched
is known as the host web.
There are two different scopes in which you can install and
configure a SharePoint app. The scenario that is easier to understand
is when an app is installed at site scope.
In this scenario, the app is installed and launched within the scope of
the same SharePoint site. In this scenario, the host web will always be
the same site where the app has been installed.
SharePoint apps can also be installed and configured at tenancy scope. In this scenario, an app is installed in a special type of SharePoint site known as an app catalog site.
Once the app has been installed in an app catalog site, the app can
then be configured so that users can launch it from other sites. In
this scenario, the host web will not be the same site where the app has
been installed.
The ability to install and configure apps at tenancy scope is
especially valuable for scenarios in which a single app is going to be
used by many different users across multiple sites within an Office 365
tenancy or an on-premises farm. A single administrative user can
configure app permissions and manage licensing in one place, which
prevents the need to install and configure the app on a site-by-site
basis. The topic of installing apps will be revisited in greater detail at the end of this chapter.
