With the rise of cloud platform and cloud model (office 365), app model came into conversation with addressing the some of the drawbacks which was with SharePoint custom solutions. Even though there are many disadvantages with the App model solution designers go to this model with the requirement.
Following few points better to know before jump into the model;
- W3wp.exe – SharePoint worker process which manages solutions which deployed as a farm solution
- SPUWorkerProcess.exe – worker process which manages solutions which deployed as a sandbox solution
Since all the models which were before running inside the SharePoint, there is high couple and dependencies which can be accounted as a disadvantages.
- There is possibility of custom codes affect the processes and codes of SharePoint – scalability and environment risks
- Less ability to upgrade the SharePoint with the tightly coupled behavior and its complex behavior – high dependencies
- When code running with elevated privilege can do any action which site administrator (security violation with impersonation) can do. Sandbox box solutions scope this impact to some extent but code within the scope will affected – permission issue
- Sandbox solutions it’s not possible to run code with impersonation and only capable of running codes as current user – impersonation issue
- Final major problem with the installation and upgrading. This may require restart of IIS on front-end servers – installation and upgrading issue
Impersonation in SharePoint
Running custom codes as an administrator to perform some task which signed in or other users could not perform. This achieved by using SPSecurity.RunWithElevatedPriviledges.
Advantages of SharePoint app model
- App support for both Office 365 (cloud) and on premise
- App code runs separately apart from SharePoint environment
- Code can be run under distinct authentications
- Apps deployed using app catalog make easier to discover, install and upgrade
- App code access the SharePoint point across web service entry points
Set of site collections configured and administered as a set (bundle). Business users who access the tenancy knows a tenants.
When O365 creates new tenancy, it created new administrative site collection with can be accessibly by the tenant administrator.
When deploying apps into SharePoint on premise it takes “default tenancy” where tenancy concept that much not important.
Services which supports for SharePoint app model
App Management Service
It contains configuration data for Apps which installed, configured, permissions and licensing of SharePoint apps. This can be configured manually in the ‘Central Administration’ and it’s already configured in the Office 365.
Site Subscription Setting service
Contains configuration data of every site tenancy and includes those in its own database. This need to be configured using PowerShell and pre-configured in the Office 365.
Scopes of SharePoint Apps (App installation scopes)
1. Site Scope
Launched and installed in the same scope of SharePoint site.
2. Tenancy Scope
App installed in special type of SharePoint site known as “app catalog”. So that users can use the app in site as they prefer. This scope is useful when users in the tenancy can pick the app and use in their site as prefer. Permission handling on app still with the administrator.
There are two isolated places where you can push custom codes to SharePoint. Those are as bellows;
- Server side – can be write with language like C# and this need to execute code outside the SharePoint host environment. This mostly become a cloud hosted app.
In later post I will be further talking about hosting models, configuration files within the apps, packaging and etc.