One of the highly requested samples related on the Office 365 and Azure usage is the asynchronous self-service site collection provisioning. This is pretty much a follow up for the similar blog post concentrating for the on-premises and Office 365 Dedicated side, but this one concentrates on the normal Office 365 with the provider hosted apps hosted in Microsoft Azure platform. There are small differences between the on-prem and the cloud, but the logical design is pretty much the same as in following picture, but for this one I wanted to indicate where the individual elements are actually hosted and using which technique.
- End users are exposed self service site collection creation UI
- Request are saved to SharePoint list, which could be optionally associated with a workflow for approval purposes. You could also store the requests to some other centralized location, like to Azure Storage Queue, which is then accessible by the remote timer job. Details on this slightly depends on the exactly business requirements.
- Remote timer job is schedule as a web job or as a worker process, which is checking if there’s any site collections to be created in the request queue. If there are and the request have been approved in the case of approval workflow, remote timer jobs actually starts the creation of the site collection
- Needed assets like images and themes are stored in some location where the remote timer job can provision them to the newly created sites
- Actual creation starts by creating out of the box site and then site can be specialized based on end user selection, like for example by providing multiple different adaptations of the team sites, which can differentiate for example with the created document library or content type perspective. Whatever is needed for the particular deployment.
How do I handle branding for the sites? Do I use web templates?
This is pretty common question and the recommendation is to use directly CSOM as part of the remote timer job to deploy the needed assets to the just created site collection. The reason why we don’t recommend web templates is that they are not automatically updated whenever the introduce any new capabilities ot the out of the box site definitions. This means that after a while, your web templates are falling behind of the updates which are applied to the out of the box sites.
Ok – so how should I approach this then?
You should always start by provisioning out of the box site, which means basically either team site or publishing site. Next step is then to apply the needed changes to the provisioned sites based on the selected template. This means branding, content types, libraries and whatever is needed, which we used to provision to the sites using the web template technique. That does not mean that you are limited to just few templates, you can still have many templates like with web templates side, but you just start with by creating the site using out of the box site.
- Provisioning engine which could be hosted in Azure or in on-premises. Could be as simple as set of PowerShell scripts which are provisioning the site collection and uploading the needed elements.
- We always start with the out of the box site provisioning, so that you get all the latest improvements for the sites.
- Actual specialization based on the user selection. Is it collaboration, project or organizational site. This is pretty much the stage which can be compared to the web templates. Main difference is however that we apply the needed settings and configurations to the sites using CSOM/REST. Uploading of the assets or creating the needed content types. This way the site has no dependencies on any external elements, which will help with the future updates on the service.
How is it developed?
You can download the code from the Office 365 Patterns and Practices guidance (PnP) and for detailed explanation, please check this video from Channel 9 by Andrew Connell where he explains the code structure and how things work based on the code we provided in the PnP project.
How would I deploy this to Azure and Office 365?
Like explained in AC’s video, this sample consists from two different part. One part is the UI part which exposes the self service site collection request form, which does not actually provision anything. Second part is then the remote timer job part. UI part will be deployed to the Microsoft Azure as a web site and the remote timer part will be added there as a web job. This way you can easily schedule how often your code is executed.
Following video is showing deployment to the Office 365 and Microsoft Azure in practice.
Like mentioned in the video, the normal timeout for the web job execution in the Microsoft Azure is 121 seconds. Since the site collection creation and applying the customizations will take longer than that, you’ll need to increase this timeout. This can be done by adding SCM_COMMAND_IDLE_TIMEOUT key to the application settings using the Azure console or you could also add this to the app.config of the console application when you deploy that to Azure.
Office 365 Developer Patterns and Practices
Techniques showed in this blog post are part of the Provisioning.Cloud.Async sample in the Office 365 Developer Patterns and Practices guidance, which contains more than 50 projects demonstrating different patterns and practices related on the app model development. Check the details directly from the GitHub project at https://aka.ms/OfficeDevPnP. Please join us on sharing patterns and practices for the community.
“From the community for the community” – “Sharing is caring”