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.
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.
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.
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.
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.
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.