One of the challenges with the SharePoint 2013 App pattern are certain limitations compared to the server side code. These will be gradually obviously addressed with the upcoming releases to ensure that the normal enterprise scenarios can be also implemented using the SP App world. One example of these limitations is the lack of site collection creation capabilities in on-premises deployments.
Office365 or SP Online supports creation of site collections remotely using specific online extensions to the CSOM (part of the Windows PowerShell for SharePoint Online package), but this set of functionalities is not available for on-premises (or Office365-Dedicated) currently. This is really powerful capability which is well demonstrated by Richard diZerega in his blog post called Self-Service Site Provisioning using Apps for SharePoint 2013.
It’s however pretty common that we need custom self service site collection creation capabilities also for on-premises, so that we can provide enterprise ready end user experience to requesting new site collections with needed customizations and branding. This blog post explains how this can be achieved using the same SP App provider hosted patterns like in cloud. Reference code is also available for download.
How to address this gap in on-premises?
There’s actually pretty simple solution for this – let’s expose the needed capability as custom extension point until the gap is addressed natively in the product. This can be achieved pretty easily by deploying custom WCF end point to the SharePoint farm, which is exposing the needed server side self service site collection API to be used externally as well.
In high level our architecture will look as follows. We have three specific phases.
- Actual site collection creation UI is hosted by the provider hosted app or the requests are stored in agreed location
- Provider hosted app will process the request and will provision site collection based on the given values
- Site collection provisioning is done using custom WCF end point which provider hosted app is calling with given parameters
- Can include custom themes, master pages, elements and layouts… whatever is needed based on business requirements
This pattern can be easily extended as needed to support additional capabilities. Here’s a architecture for real world implementation where also AD and FIM integration was included to the process.
- End users select the template and provide other needed attributes for the site collection
- Request is stored to specific list in the SharePoint
- This also means that when site collection creation is natively supported in CSOM, we can quickly just replace the needed code in step 5 and all other code will be remain intact
So you’d be still adding farm solution to your farm?
Yes and that might seem silly at fist, but there’s a clear difference comparing to the more classic approaches where we deploy the whole functionality as farm solution. Key difference is that with this solution we ONLY expose additional APIs which are not available by default, but we don’t actually provide any real UI or other customizations which we would have to maintain in SharePoint side.
Key point is to evaluate how often you actually need to change the exposed API set, compared on the UI or other customizations related on the provisioning? – not that often most likely, which means that we can concentrate on maintaining the code in provider hosted app side, rather than on the SharePoint side. This means less service breaks and more robust development opportunities without compromising the whole SharePoint farm.
It’s also important to notice that this is just a temporary solution until needed capabilities are available natively remotely. Since we will implement all other needed customizations using the App pattern as well, we can easily replace the site collection creation with native API, when that’s available.
Why would you use SP Apps in on-premises?
This is pretty common question which I thought to address slightly. Obviously it’s completely up to you to use the app pattern or not in on-premises. In general this is however the roadmap of the product and we are gradually moving to this direction also in on-premises. Many of our enterprise customers are looking into using App pattern also in on-premises to keep the deployment compliant with the cloud practices, so that they can easily move to the cloud, if decided to do so.
On big advantage also for on-premises is that when we utilize the App pattern, we don’t have to perform as frequent maintenance breaks as classically with the farm solutions. It means that all the customizations are running outside of the SharePoint or as un-ghosted elements and therefore customization changes will only impact the app platform, not actual SharePoint services, like accessing critical documents from collaboration sites. We also more precisely maintain or update only specific apps, without impacting the other services. This provides us clear benefits and will make the whole ALM process much more agile and dynamic.
There are lot of opinions on this one which are definitely all more than justified. When we design customization architectures for the customers, these things are not black or white. It all depends on the business requirements, including short and long term roadmap for the particular deployment.
Video recording of the demo code
In this video I’ll quickly walk through the provide example code which includes the WCF end point and the provider hosted app for actually requesting the site collections.
Few useful links and resources related on this blog post.
- Code example used in video – ‘SharePoint 2013 – Contoso.Services.SiteManager.zip‘ – SkyDrive
- Direct link to YouTube video – YouTube
- Self-Service Site Provisioning using Apps for SharePoint 2013 – Richard diZerega MSDN blog post
- Shows how similar implementation can be achieved for Office365 or SharePoint Online
- Windows PowerShell for SharePoint Online – TechNet
- Contains the tenant admin CSOM interface for the cloud based implementation