I’m happy to announce that I’ll be speaking at the SharePoint Conference 2020 in May of this year!
One of the sessions I’ll be doing is about something that is close to my heart: provisioning. I’ve been working on the PnP Provisioning Engine since day one (and actually on my own provisioning engine before that), and over the years this engine has grown to be basically the de-facto standard in the SharePoint world.
However, we’re expanding the scope of the engine: we scaled out to include now for instance Microsoft Teams, Azure Active Directory and there will be more areas coming in the future too!
A bit of history
The PnP Provisioning Engine started off as a side project of the PnP Sites Core .NET library. We wanted to provide those developers that worked with SharePoint Online with an experience that was similar to the good-old Site Definitions (anyone remember ONET.XML?). Given that you could not use Site Definitions with SharePoint Online (at the time only sandboxed solutions and web templates were available, each coming with its own limitations) we decided to implement a similar model to ONET.XML but then using client side technology.
We started with an XML schema, implementing the basic functionality we thought was relevant at the time. And from there it took off. The provisioning engine really hit base with many people working with provisioning and SharePoint Online. We started to expand the engine, solving the more complex tasks (fields, content types, content type inheritance, lists, lookup fields come to mind). We saw the usage numbers increase, we saw the pull requests on our open source repo (https://github.com/sharepoint/pnp-sites-core) increase.
Over the years the engine has been used by both in-house developers, consultants but it is also used in commercial products and in Microsoft owned offerings (https://lookbook.microsoft.com).
A bit of the future
We are changing the direction of the engine a bit. You’ll for sure noticed that Microsoft released Site Scripts and Site Designs as part of SharePoint Online. And they work great for what they can do. But there are a few downsides in using Site Designs:
- You cannot provision tenant wide artifacts. Site Designs and Site Scripts, the names give it away, work on -site- level.
- Not all the artifacts that you would want to provision, like complex modern pages for instance, are being supported by Site Designs.
- Site Scripts are ‘fixed in place’. The means that a site design cannot adapt itself to a situation based on variables, unlike the PnP Provisioning Engine.
But, having set that, there is a benefit of Site Designs: they run on the server. You do not need your own ’engine’ or PowerShell session to run them. Site Designs are growing in functionality, and while not yet at the level of the PnP Provisioning Engine, if a site design solves your needs, then you should absolutely use them.
We are slowly changing the focus of the PnP Provisioning Engine from purely sites to the tenant. There are many ways to provision certain artifacts to Microsoft 365: Teams have their own JSON based templates, Azure has their own Azure Resource Management Templates. SharePoint has the Site Script Templates.
Wouldn’t it be nice if we could provision an Azure artifact, a SharePoint site, and a Teams team using one templating technology? That’s where the PnP Provisioning Engine comes in.
.NET Core / .NET Standard
We are expanding the reach of the PnP Provisioning Engine, and we are moving the engine to somewhat more modern technology:
- We will introduce a JSON based template format
- The engine will be rewritten in .NET Standard, which makes the engine available in PnP PowerShell for PowerShell Core (hhttps://github.com/PowerShell/PowerShell)
- You will be able to run the engine in Azure Functions V2
Notice that this is quite some work (we’re going to do some heavy refactoring behind the scenes to make it faster, even more stable, and in general even better). We are however depending on some releases from Microsoft to happen: CSOM for .NET Standard. As much of the code in the PnP Provisioning Engine is based upon .NET Framework CSOM, we will have to rewrite that for CSOM for .NET Standard. However, a big part of our work will also be that we will focus on the Microsoft Graph APIs first. We will provision, where possible, artifacts through the Graph. If needed we will fall back to other APIs though.
When this will be available: we don’t know right now, we are still planning. Soon we hope! Who knows, maybe we have something to show you during the SharePoint Conference 2020 in Las Vegas!
BTW: if you’re thinking of going, a easy way to get a 50 USD discount when you register is by clicking this link: https://sharepointna.com/#!/register?utm_term=HUNEN