Understanding SharePoint Apps SharePoint 2013
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.
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.
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.
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 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.
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.
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 URL for the App web would actually look something like this: http://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:
The placeholders are defined as follows:
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.
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.
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.
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.
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.
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.
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.
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 http://intranet.contoso.com/sites/SiteCollectionA, you may expect the App web URL to be http://intranet.contoso.com/sites/SiteCollectionA/Poll. This is not the case!The URL for the App web would actually look something like this: http://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:
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.
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.
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.
Comments
Post a Comment