Sequencing Azure Http Trigger Function runs during simultaneous calls

While working on Group provisioning process (blog here), we encountered an issue with parallel calls to Azure Functions from Flow. Even though, Microsoft flow supports sequencing flow runs but doesn’t queue them one after the other. Bummer !! However, we were able queued the requests at Azure Http function level, which was quite simple actually.

Azure Queue Triggers are mostly recommended in this case but with Queue trigger, the queue would always trigger at least two runs and the poison queue wouldn’t trigger after failing for more than 5 times

Hence we ended up managing it by the Http trigger function.

The process is quite simple and could be easily done by modifying the host.json file of the Azure function.

Note: Host.json is a global configuration file for all functions within a Function app, hence the below changes would affect all functions in that particular app.

Note: More details about host.json schema could be found in the Microsoft article here.


{
"http": {
"routePrefix": "api",
"maxOutstandingRequests": -1,
"maxConcurrentRequests": 1,
"dynamicThrottlesEnabled": false
}
}

Automation and Creation of Office 365 groups using Flow, Microsoft Graph and Azure Function – Part 1

Automating the creation of Office 365 groups via an event triggered process can help business teams use a consistent template across all their groups, especially if there are numerous groups provisioned throughout the year.

For example, in our case we have 500+ custom Office 365 groups that are created and maintained each year. Hence in this case it became obvious we wanted to spin up an Office 365 group from a SharePoint list where users could make the request on their own. Below is a quick overview of the approach and some of the learnings from it. Hopefully this helps.

In this blog – Part 1, we will discuss the approach to the Group creation process and important considerations for provisioning groups. In the upcoming blog – Part 2, we will look at using the Graph App for invoking the graph service and then implementation of the group provisioning process.

Solution overview

The solution uses the below applications.

  1. SharePoint List – Data Entry for Groups requests
  2. Microsoft Flow – Handles events on the list item create and update
  3. Azure AD Apps – Generate App ID and App secret for Graph API calls
  4. Azure Function – Automation Code for applying additional rules on the SharePoint sites after the Group is created

High level business logic

The high-level logic flow of the process is as follows. First users make an entry into a SharePoint list. Next step, is to invoke a flow from the SharePoint list item. The flow is based on the defined rules and calls the Azure Function with appropriate parameters. The Azure function then creates the group using the Graph service and assigns owners and members to the group. After the group is created, the Azure Function also applies the later changes to the Group using the SharePoint CSOM.

After the Azure Function has created the group and provisioned the SharePoint artefacts, it will send the success response as the result. In the case of an error, it will reply with an error response.Office365GroupsProvisioningFlow

Important Considerations

For the above process we must make a few important considerations before implementation. There may be slight modifications based on these.

Azure Function Call Sequencing

The most important part of the above process is how we handle parallelism. The Microsoft graph service is not capable of too many subsequent requests from a single tenant, so to make it more robust we can sequence the Azure Function to handle only one request at one time. This can be done by modifying the host.json of the Azure Function as below.

{
  "http": {
    "routePrefix": "api",
    "maxOutstandingRequests": -1,
    "maxConcurrentRequests": 1,
    "dynamicThrottlesEnabled": false
  }
}

Group and SharePoint Site Permission Sync – A LONG wait…

Group creation is managed through an integrated provisioning process handled by Microsoft, so not all artefacts of an Office 365 group are created at the same time.  Some components are created instantaneously, such as the Exchange mailbox and SharePoint Site, but others take time to provision such as the AD Office Group security sync.  In some cases, the AD Security sync can take as long as 15 min to finish.  As such, we must wait to obtain owner level access.

For provisioning the SharePoint artefacts, you can use this blog to set the SharePoint site to allow site scripts.

Error Handling

Since the Group creation process is a long running process, it will be important to make sure that any failure is handled properly, and the process is re-run later.

In our case, we will use the Flow to handle any error case until we have a success as shown below. If you’re using an Azure Queue Storage trigger for the Azure Function, then we can use the Poison queue for handle error runs.

Office365GroupsProvisioningErrorHandlingInFlow

Conclusion

In this blog post, we covered the broad level process of the Group Provisioning process, and some important considerations associated with it. Next, we will see how we can implement the remaining processes in the follow up blog.

Reset to default New Document dropdown for SharePoint Modern Libraries with custom document content types

We are working on an auto provisioning process using PnP Provisioning Template. While working on the libraries, we saw a deviation from the default behaviour for “New” Command in Modern Libraries. The new dropdown worked differently after we changed from Default Document type to our Child content type (which inherits from Document Content type). A brief overview of the default new button before and later when a child content type is associated is as below:

 In order to get back the default “New Button” behaviour, we can use one of the below approaches

  1. Single custom content type: Set “Allow Management of Content Types” to “No”. And that’s it !!!
  2. Multiple custom content types: Set the Template path of the child content type to point to Root content type. In case, you have multiple content types or there are requirements for having “Allow Management of Content Types” to “No”, then follow the below steps:
    • Open the child content type
    • Go to “Advanced Settings”
    • Change the template.dotx location to point to the root template document to [site location]/[Library Name]/Forms/template.dotx 
    • Save the changes and it will show the full “New Button” menu again

Hence above we saw how we can reset the New Button on Modern Document libraries.

Creating SharePoint Modern Team sites using Site Scripts, Flow and Azure Function

With Site Scripts and Site design, it is possible to invoke custom PnP Provisioning for Modern Team Sites from a Site Script. In the previous blog, we saw how we can provision Simple modern sites using Site Scripts JSON. However, there are some scenarios where we would need a custom provisioning template or process such as listed below:

  • Auto deploy custom web components such as SPFx extension apps
  • Complex Site Templates which couldn’t be configured
  • Complex Document libs, content types that are provided by JSON schema. For an idea of support items using the OOB schema, please check here.

Hence, in this blog, we will see how we can use Flow and Azure Functions to apply more complex templates and customization on SharePoint Modern Sites.

Software Prerequisites:

  • Azure Subscription
  • Office 365 subscription or MS Flow subscription
  • PowerShell 3.0 or above
  • SharePoint Online Management Shell
  • PnP PowerShell
  • Azure Storage Emulator*
  • Postman*

* Optional, helpful for Dev and Testing

High Level Overview Steps:

  1. Create an Azure Queue Storage Container
  2. Create a Microsoft Flow with Request Trigger
  3. Put an item into Azure Queue from Flow
  4. Create an Azure Function to trigger from the Queue
  5. Use the Azure Function to apply the PnP Provisioning template

Detailed Steps:

This can get quite elaborate, so hold on!!

Azure

  • Create an Azure Queue Store.

Note: For dev and testing, you can use the Azure Storage Emulator to emulate the queue requirements. For more details to configure Azure Emulator on your system, please check here.

Microsoft Flow

  • Create a Microsoft Flow with Request trigger and then add the below JSON.

Note: If you have an Office 365 enterprise E3 license, you get a Flow Free Subscription or else you can also register for a trial for this here.


{
"type": "object",
"properties": {
"webUrl": {
"type": "string"
},
"parameters": {
"type": "object",
"properties": {
"event": {
"type": "string"
},
"product": {
"type": "string"
}
}
}
}
}

  • Enter a message into the Queue in the Flow using the “Add message to Azure Queue” action.

MicrosoftFlow_SiteScript

Note: The flow trigger URL has an access key which allows it to be called from any tenant. For security reasons, please don’t share it with any third parties unless needed.

Custom SharePoint Site Template (PowerShell)

  • Next create a template site for provisioning. Make all the configurations that you will need for the initial implementation. Then create the template using PnPPowerShell, use the PnP Provisioning Command as shown below.
Get-PnPProvisioningTemplate -Out .\TestCustomTeamTemplate.xml -ExcludeHandlers Navigation, ApplicationLifecycleManagement -IncludeNativePublishingFiles

Note: The ExclueHandlers option depends on your requirement, but the configuration in the above command will save a lot of issues which you could potentially encounter while applying the template later. So, use the above as a starting template.

Note: Another quick tip, if you have any custom theme applied on the template site, then the provisioning template doesn’t carry it over. You might have to apply the theme again!

  • Export and save the PowerShell PnP Module to a local drive location. We will use it later in the Azure Function.
powershell Save-Module -Name SharePointPnPPowershellOnline -Path “[Location on your system or Shared drive]”

SharePoint


<AppPermissionRequests AllowAppOnlyPolicy="true" >
<AppPermissionRequest Scope="http://sharepoint/content/tenant&quot; Right="FullControl" />
</AppPermissionRequests>

Azure Function

  • Create a Queue Trigger PowerShell Azure function
  • After the function is created, go to Advance Editor (kudu) and then create a sub folder “SharePointPnPPowerShellOnline” in site -> wwwroot -> [function_name] -> modules. Upload all the files from the saved PowerShell folder in the Step above into this folder.
  • Add the below PowerShell to the Azure Function


Write-Output "Incoming request for '$in'"
Connect-PnPOnline -AppId $env:AppId -AppSecret $env:AppSecret -Url $in
Write-Output "Connected to site"
Apply-PnPProvisioningTemplate -Path D:\home\site\wwwroot\<function name>\<template>.xml

  • Test the Function by the below input in PowerShell
$uri = "[the URI you copied in step 14 when creating the flow]"
$body = "{webUrl:'somesiteurl'}"
Invoke-RestMethod -Uri $uri -Method Post -ContentType "application/json" -Body $body

PowerShell and JSON script

  • Create a Site Script with the below JSON and add it to a Site Design. For more details, please check the link here for more detailed steps.


{
"$schema": "schema.json",
"actions": [
{
"verb": "triggerFlow",
"url": "[paste the workflow trigger URL here from Flow]",
"name": "Apply Template",
"parameters": {
"param1":"",
"param2":""
}
}
],
"bindata": {},
"version": 1
}

After the above, you are finally ready to run the provisioning process. Yay!!

But before we finish off, one quick tip is that when you click manual refresh, the changes are not immediately updated on the site. It may take a while, but it will apply.

Conclusion:

In the above blog we saw how we can create Site templates using custom provisioning template by Flow and Azure Function using SharePoint site scripts and design.