Freigeben über

Understanding SharePoint Apps as an IT Pro

  • Artikel

Summary:   Sam Hassani, Microsoft Certified Master (SharePoint 2010) and Microsoft Premier Field Engineer based in the UK provides us with an introduction of SharePoint 2013 Apps, explains why there is a need for Apps in SharePoint, and then demonstrates the architecture of Apps in SharePoint from an IT Pro's perspective. A “must read” for any IT Pro looking at SharePoint 2013 Apps (and who isn’t?). Enjoy!

SharePoint 2013

At the SharePoint Conference in November 2012, Chris Whitehead and I presented on "Understanding and Maintaining SharePoint Apps for IT Pros".   Much of the session focused on some of the key configuration steps to be carried out to successfully set up your on-premises farm to have SharePoint Apps deployed and installed to it.  The purpose of this article is to firstly recap what Apps are and why there is a need for Apps in SharePoint, and then move on to demonstrate the architecture of Apps in SharePoint from an ITPro's perspective.

Why Apps?

For far too long both IT Pros and Developers have relied solely on full trust solutions, whether speaking about SharePoint or another platform.  Having full trust to the box at all times just isn’t the way we want to do things nowadays!  As we all know, the flexibility of full trust solutions makes for unpredictability of a platform.  That model can make IT Pros feel like their fate is in the hands of the developers and often require them to clean up the mess come upgrade time or after an outage.  I’ve lost count of the number of times I’ve been onsite for critical situations (a.k.a. critsits) involving custom code and memory leaks.  Of course we shouldn’t tarnish all developers with that brush.  Furthermore, full trust solutions are unfeasible on a hosted platform such as Office 365.

SharePoint 2010 took a step in the right direction with sandboxed solutions.  Sandboxed solutions provided a way to isolate code execution in both on-premise and SharePoint online deployments, albeit with a subset of the object model.  For IT Pros sandboxed solutions introduced additional complexity when administering their farms, and for the end user it didn’t really provide an enhanced experience.

In SharePoint 2013 we have Apps.  Sandboxed solutions are still here but are deprecated in favour of the App model.  Apps are all about taking classic software and making it simple to the end user.  An App serves a specific purpose and does what it should do very well, often by connecting to remote web services but remaining as a standalone entity.  Apps protect the end user and the IT Pro that is looking after the system. Neither want to install solutions that they cannot trust to be safe and “just work” out of the box.  For developers, the Apps paradigm goes one step further than simple sandboxing because it allows them to benefit from an eco-system with built in lifecycle management, whether it’s the install/uninstall process, updating of apps, or licensing.  If required, the App can also perform off box code execution whilst it appears to be executing on the local platform.

Apps Architecture

Apps for SharePoint come in a variety of different flavours and can be divided into a few categories depending on how they are hosted.  You have cloud-hosted which further gives the option between provider-hosted and auto-hosted, and you also have SharePoint hosted Apps.

Different flavours of SharePoint Apps

Starting with SharePoint-hosted – these are Apps that include only SharePoint components and logic that runs on the client. There are no external components and all components of the app such as lists, content types and workflows are contained within a special kind of App Web.  The app is installed on an existing site, but it actually runs from and stores all its data within this App web, which is a sub site of the site where the App is installed – we'll come back to this shortly. It's worth calling out that no server side code is allowed for SharePoint-hosted apps, only JavaScript calls between the client machine and farm.

A good example of a SharePoint-hosted app is that of a Poll or Survey.  Users of a site can install the App which has a specific piece of functionality, in this case allowing users to create surveys for different purposes.  The App would allow users to create surveys with a specific set of questions and optional answers, and also track responses.  We'll refer back to this example later in this post.

Cloud hosted apps include at least once component that is hosted outside of the SharePoint farm, but they may also include SharePoint-hosted components. We break this down into the following two categories:

Provider-hosted (or sometimes called developer hosted) apps are hosted by the provider or developer, or even on your own separate hardware (this could be in the cloud).  Their data storage and business logic is down to the provider or developer, this also includes enforcing isolation between the accounts of the various customers who purchase an App if the developer is providing the App for multiple customers. Of course as mentioned these apps can have SharePoint components too, stored in an optional app web hosted in the SharePoint farm.  Provider-hosted apps provide lots of flexibility, for example being able to use any platform and programming language for your application – even non-Microsoft.

Autohosted apps include a Windows Azure Web site, and possibly a SQL Azure DB that are automatically provisioned invisibly to the end user when an app is installed. The Windows Azure Web Sites infrastructure manages isolation of tenancies.

As with provider-hosted apps, autohosted apps can have SharePoint components stored in the optional app web too. For example, in the case of the Poll or Survey App, the questions and results could be stored in the App web, but the processing may be done using server-side code off box.

Let's speak a little bit more about host webs and App webs that I mentioned earlier.

The site to which an app is installed is called the host web.  However, the components implementing the logic of the app for SharePoint, whether they are SharePoint components or external components, are not deployed to the host web.  Similarly external components are deployed to external servers, or to a Windows Azure Web Site.

SharePoint components are deployed to a special sub Web of the host web called the App Web.  It uses a new site definition in SharePoint 2013 and is configured in such a way that end users cannot manipulate app webs using a browser or SharePoint Designer, to avoid breaking of the Apps.  Pretty much everything is deployed to the app web.

The only components that are deployed to the host web are a limited set of UI components that give users access to the app's other components, we'll come back to this point shortly.

Every time a particular SharePoint hosted App is installed in different sites, it will have its own App web deployed, there's effectively a 1:1 mapping.  Of course, although it's not shown on the diagram below, Autohosted or Provider-hosted apps can also have their own App webs as we mentioned previously.

Host Webs and App Webs

So to clarify, if we have another site collection and we deploy another app there, we get an App web deployed beneath that site collection.

App web deployed beneath a site collection.

But why is this?   Well it all comes down to architectural design decisions to support Apps in SharePoint.  At the start of this post I mentioned that some of the design goals for Apps were to make them self-contained with a lifecycle story.  One of the issues with the solutions model is that it led to spattering of new functionality at various different scopes.  The apps model contains everything to either a remote site, or to a single SharePoint app web.

There are plenty of examples as to why this is a good thing, amongst other examples, when we remove the App, or upgrade it, we know we are not going to break functionality elsewhere because a developer forgot to write deactivating or uninstalling code.

It's worth calling out here that an app also has its own identity and it has permissions that are not necessarily the same as the permissions of the user who is executing the app.  We’ll speak about this more later, but you can see that its reasons like this which make using a separate app web, rather than deploying to the host web the logical design decision.

App UI Components

I mentioned earlier how SharePoint components are deployed to the App Web and that a limited set of UI components that give users access to the app's other components.  As well as the user starting an app from Site Contents and the App running in full screen mode, we can add custom actions and "App Parts" to interact with the App.

App parts are a type of webpart that are really just wrapper iframes that contain content from an App, and have properties that can be set to choose exactly what and how data may be rendered.  If you think back to the Survey App example mentioned earlier, an App part could be used to interact with one of many surveys hosted within the App.  More specifically the App web could be used to view and create all surveys, and the App part could be used to complete and view results from one survey, as per the images below.

App Webs and App Parts

App Webs and App Parts

In addition to App parts we can add custom actions to Ribbon and Edit Control block menus, allowing the app to be available in the context of the content.  In the screenshot below we have extended the SharePoint ribbon with an icon labeled "Convert to Grayscale."  When in the context of an image, this functionality actually connects to a Cloud-hosted app (Autohosted in this case) to take the image and run some server side code to convert the image to grayscale, and render the image to the end-user in the browser.  This conversion process and rendering of the new image all happens outside of the SharePoint environment.

Extending the SharePoint ribbon with an icon labeled "Convert to Grayscale."

It is important to note that the User Interface components are deployed as a Feature in the Host web that is part of the App package

The Isolated Domain

One thing we haven’t spoken about yet is the URL of each app.  Clearly for autohosted or provider-hosted apps, we are making calls to different URLs in different domains.  However, this is also true for each app web for SharePoint hosted apps or the optional app webs for autohosted or provider-hosted apps.  We mentioned earlier that when we install a SharePoint-hosted App in a site, we get an App web deployed beneath that site.  You would think that the URL or the App web would just be created as if it was a sub-web in the site.  For example if the App "Poll" was installed at https://intranet.contoso.com/sites/SiteCollectionA, you may expect the App web URL to be https://intranet.contoso.com/sites/SiteCollectionA/Poll. This is not the case!

The URL for the App web would actually look something like this: https://app-bdf2016ea7adcb.contosoapps.com/sites/SiteCollectionA/Poll.

Each App web is created with a unique URL. The difference in URL between each provides a layer of isolation. This is because browsers enforce something called the same origin policy with regards to JavaScript calls. The same origin policy prevents JavaScript in one domain from executing in another. For example, this policy will prevent a webpage in one domain from making XmlHttpRequest web-service calls to a domain other than the one where it is hosted. SharePoint takes advantage of this by deploying each App to its own domain.

As illustrated above the URL of the App web has the following structure:

clip_image010

The placeholders are defined as follows:

  • App Prefix is any string set by the farm administrator in Central Administration or Windows PowerShell.  The default is "default." In my example above the administrator has changed this to "app."  In Office 365 this would be the Tenant’s name.
  • App ID is a hexadecimal number generated internally when the app is installed.
  • App Domain is any string set by the farm administrator in Central Administration or Windows PowerShell.  The default is the domain of the SharePoint web application.  In my example, the administrator has removed the "www." and set contosoapps.com as the app base domain.
  • Host web is the relative URL of the parent host web, in this case sites/SiteCollectionA.
  • App name is the name of the App given by the developer, in this case Poll.

For more information around configuring your Farm to support Apps, and to configure the URL components defined above, please see the next article in this series: How To Configure SharePoint 2013 On-Premise Deployments for Apps.

App Permissions

One final area to mention is that of permissions.  There's lots of information around this on TechNet and some great blog posts out there on this topic, so we won't labour this for too long here.  However it is worth covering off some key points to complete this post.

For Apps that use an App web, the App will have full control rights to the App web, so it will only need to request and have permissions assigned to resources in the Host web or other locations outside the App web.

SharePoint Apps use permission requests to specify the permissions that are needed at a particular scope.  There are different scopes that can be specified for content and in addition to these, there are also scopes for things like performing search queries, accessing taxonomy data, and microfeed activities to name a few.  More details can be found here: App permissions in SharePoint 2013.

App permission rights indicate the activities that an app is permitted to do within the requested scope which are also detailed in the article referenced above. Unlike SharePoint user roles, these rights levels are not customizable.

It's worth pointing out that the user installing an App must have full permissions on the Host web that an App is requesting, otherwise installation of the App will not be possible.  Presuming the user does have sufficient permissions, on installation the user will be notified as to what permissions the App requires as per the screenshot below.

the user will be notified as to what permissions the App requires

That's all for this blog post, hopefully this article has helped you take a step forward in understanding what Apps in SharePoint 2013 are about.  For more information on setting up your farm for Apps, please see the next article in this series: How To Configure SharePoint 2013 On-Premise Deployments for Apps.

Thanks!

Posted by Frank Battiston , MSPFE Editor

Comments