Tuesday, 11 December 2018

Slide decks – PowerApps and Azure Functions talks from ESPC 2018

I had a great time speaking at ESPC 2018 last week (the European SharePoint, Office 365 and Azure Conference) in lovely Copenhagen. Not that I saw too much of the city, but I did get to catch-up with many friends and Microsoft people from the Office 365/SharePoint community, which I enjoyed a lot. It was also an honour to be on the programme team for the conference this year. I think the event was fantastic overall, and I saw a lot of great content in the sessions I got to. I also had some great conversations with attendees – thank you to everyone who came up to  ask a question, comment on something I’d talked about or just to say hello! That aspect is always the bit I enjoy most about these conferences. 

I’m publishing the slide decks, videos and some sample code used in both of my talks. The slides should be embedded below (at least if you’re viewing this on a PC), but are also linked.

An A-Z of Azure Functions for the Office 365 developer

I think most people would agree that understanding Azure Functions is critical to being a productive Office 365 developer. Areas of focus in this talk included performance, pricing, use of Visual Studio vs. VS Code, extending PowerApps and Flow with custom code in an Azure Function, extending SharePoint Site Designs with Functions for templating modern SharePoint sites (including those for Microsoft Teams) and more.

I also have videos from my demos available at the link below:

The videos don’t have captions, but do run through the steps to accomplish the goal (e.g. extend PowerApps/Flow with custom code) and should make sense when viewed alongside the deck.

AF 6

Enterprise PowerApps – rich apps with offline support and on-premises data

PowerApps are getting stronger and stronger, and this talk was part case study/part informational. I focused on how to implement offline support, how to connect to on-premises data, and various tips for performance and management. I also talk about what I find to be the most important PowerApps functions from the list of 150+ that can be used in PowerApps formulas.

Again, I’m also publishing a couple of related things:

COB PowerApps 1

Thanks to the folks who took these photos and put them on Twitter.

Hopefully that’s of some use to people – and hopefully I’ll see you next year in Prague!

Monday, 12 November 2018

Speaking at the European SharePoint, Office 365 and Azure Conference 2018

ESPC18 logoIn two weeks’ time, ESPC 2018 takes place in Copenhagen – this year’s event looks amazing, and I think it’s no secret that Microsoft now use this event as their European platform, rather than running their own major Office 365 conference in the region. I’m honoured to have two speaking slots, and this year I’m actually on the programme team for the conference so I’ve been involved in putting the schedule and speakers together, along with some other responsibilities.

It’s not too late to get a ticket! I’m biased this year of course, but I don’t there’s any comparable event in Europe where you can learn as much and have great conversations with Microsoft product group people, senior execs, MVPs, and highly-talented people in the industry. Microsoft are sending a lot of people, including:

  • Jeff Teper - Corporate Vice President for SharePoint, OneDrive and Office
  • Dan Holme - Director of Product Marketing (SharePoint)
  • Adam Harmentz - Partner Group Programme Management on SharePoint and Office 365
  • Omar Shahine - Director of Program Management, OneDrive and SharePoint
  • Aaron Rimmer - Director of OneDrive Product Marketing
  • Vesa Juvonen - Senior Program Manager, SharePoint engineering (tech keynote)
  • Sean Squires - Senior Program Manager, SharePoint experiences
  • Mike Ammerlaan - Director, Office & SharePoint Ecosystem Marketing
  • Naomi Moneypenny - Senior Product Manager, Enterprise Search
  • Chris McNulty - Senior Product Manager, SharePoint and Office 365
  • Karuana Gatimu - Principal Program Manager, Customer Advocacy Group, Microsoft Teams Engineering

There are a lot more too! See https://www.sharepointeurope.com/microsoft-sessions-espc18/ for full details.

My sessions

The details of my talks are:

Enterprise PowerApps – rich apps with offline support and on-premises data (Tuesday 27 November, 15:15)

PowerApps can be simple at first, but more advanced scenarios can be tricky. In this session we’ll look at key recipes for building enterprise apps, including what you need to do to make your app work offline and how to connect to on-premises data. We’ll also consider “the good, the bad and the ugly” of PowerApps – from use across devices, techniques for improving performance, through to common headaches when building applications.

An A-Z of Azure Functions (Wednesday 27 November, 15:15)

Azure Functions are the “get out of jail card” for the architect/developer implementing Office 365 solutions. Can’t do exactly what you need in a Flow? Need to look-up some data when your PowerApp loads? Implementing custom team sites using Site Designs? Need to run a process on a schedule? Chances are that an Azure Function is the answer – so you need a thorough understanding of this building block to weave it into your solutions effectively. We’ll look at authentication, scaling, coding styles, calling the Microsoft Graph and other advanced features, so that you can always call out to some custom behaviour whatever your scenario is.

Go talk to your boss!

This event goes from strength to strength, and previous years in Barcelona, Stockholm, Vienna and Dublin were all amazing. I strongly recommend trying to attend if at all possible – and I haven’t even mentioned the full day pre-conference tutorials from the likes of Andrew Connell, Paolo Pialorsi, Susan Hanley, John White and Tiago Costa, and the fantastic evening events. It’s been great working with the other members of the programme team (Mike Ammerlaan, Bill Baer, Jussi Roine, Agnes Molnar, Donald Hessing and of course Tracy O’Connell) so far, and I’m looking forward to a great event now.

Full details are at https://www.sharepointeurope.com of course. Hope to see you there!


Monday, 5 November 2018

Office 365 dev scenarios to master – top of mind November 2018

Every now and then I like to gather a list of scenarios that I think are important for Office 365/SharePoint developers to have experience in. Occasionally I’ll put a slide together to list them out, something that’s a better format than my rough OneNote notes, and put in front of my team (and myself!) as a checklist of useful skills and techniques for delivering solutions in Office 365. No doubt there is no single “correct” list and it’s all very subjective – however, the image below shows some that are top of mind for me at the moment, and I thought it might be worth sharing. I’ve had to deal with nearly all these recently, so that’s completely shaping my list! But I figure a developer who can deal with all these scenarios efficiently has quite a lot of capability in Office 365 at the moment:

(Click to enlarge)

365 dev scenarios - Nov 2018

Very shortly I’d expect to add a bunch of SPFx/Teams integration scenarios to this list (when SPFx 1.7 lands) – and no doubt there are lots of other areas to consider too. It’s an ever-changing landscape, and I think going through the exercise semi-regularly is useful in itself! 

Thursday, 4 October 2018

3 ways to create and debug Azure Functions – CLI, VS Code and Visual Studio

Recently I’ve been thinking about different ways to work Azure Functions, and the pros and cons of each. I wanted to better understand the Azure Functions Core Tools (also known as the CLI), and that role that plays in developing functions locally and then publishing them to Azure. I’d recently seen a Microsoft guy use this in his demos, and I was wondering if I was missing an important aspect of Azure Functions (which I try to stay on top of). Between Visual Studio Code/full Visual Studio/the command-line approach with the Core Tools, there’s a lot of overlap – so which is best when?

Things you should be aware of when developing with Azure Functions:

  Azure Functions v2:
Microsoft have recently launched v2 of Azure Functions, which has some differences around bindings, runtime behaviour and performance. However, if you’re an Office 365/SharePoint person, note that at this time (October 2018), you need to stay with v1 for C# functions if you want to use CSOM or PnP. This is because we don’t yet have a .NET Core version of these packages – and v2 runs on .NET Core. So, you’ll get errors if you try to build functions using v2 if you try to use these packages. Hopefully we won’t have to wait too long though – see https://twitter.com/vesajuvonen/status/1045668458971766784

  The Azure Functions Core Tools/CLI:
Although I talk about 3 options for developing/publishing functions here, in fact the Core Tools are a pre-requisite for all of them. Whether you choose to use Visual Studio Code or full Visual Studio to write your code, *debugging* is handled by the Core Tools in all cases. I note the installation process in the “option 1” section below..

OK, back to the development options. First let’s be clear on what the process looks like with each.

Option 1 - with Azure Functions Core Tools/CLI

The command-line approach can be interesting because it’s the same across platforms, although to be fair it’s currently only version 2 of Azure Functions which can be used across macOS and Linux. But what you get here is the ability to:

  • Create your function
  • Run it locally
  • Deploy to a Function App in Azure 


  • Ensure you have .NET and node.js installed on your machine (for npm)
  • Install Azure Functions Core Tools using npm install -g azure-functions-core-tools@core
  • See Install the Azure Functions Core Tools for more info


We’ll create a simple HTTP function in JavaScript in this case. As you might expect, we run commands at the command-line to create new functions and work with them.

    1. Create a folder for the function you’ll create, and open a command prompt there.
    2. Type func init to initalize the folder with the files needed for an Azure Function:

    3. To create a function, type func new to start the process. In V1 functions, you’ll need to provide:
      1. The language
      2. The trigger
    4. Provide a name for your function:       
      1. Now open the function folder in VS Code (you do know about the “code .” command to open to the current directory right?):

        1. <VS Code opens>
          1. If you have the VS Code extension for Azure Functions installed, you’ll see this:


            This is basically asking you if you’d like to switch to the VS Code way of doing things. For now, we’ll close this message to work with the command-line/Core Tools experience.

            1. Now you can add code to your function as needed.
            2. Now type func run <Your function name> to run the function locally –the first time you do this, you’ll see this message that we need to OK:

            3. In the case of a HTTP function like this, we should pass some content in the POST body using the --content flag. To match up with the default code that the generator added, let’s pass some JSON including a ‘name’ attribute:

            4. You should now see the functions runtime spin up and serve your function:

            5. Since your function is being served on a local endpoint, you’ll most likely want to use Postman or similar as you develop the code (as per the earlier recommendation) since this is much richer than the --content flag. The output from the Core Tools will tell you the URL to hit, but by default it is http://localhost:7071/api/[function name]:


            Publishing the (JavaScript) function using the CLI and Visual Studio Code

              After developing the code some more, we can deploy directly to a Function App in Azure with other commands. Most likely you’ll need to login first, and this is done with the following command:

              func azure login --username [username] --password [password]

              If you don’t provide a username/password, you’ll be prompted interactively:


              You may need to explicitly choose the Azure subscription (once you’ve signed-in) with this command, for example if that account has access to multiple subscriptions:

              func azure account set [AzureSubscriptionID]

              From here you can use the following to deploy the function:

              func azure functionapp publish <FunctionAppName>


              This is great, but something is missing – debugging!

              Debugging the (JavaScript) function using the CLI and Visual Studio Code

              At first I thought it wasn’t possible to debug functions locally using the CLI, but it is by combining it with VS Code. The process is:

              • Put a breakpoint in your code in VS Code
              • Run your function from the CLI and add the --debug flag – so func run <Your function name> –debug
              • Hit F5 (or go to the Debug tab and press Play)
              • Make a request to your function’s local URL e.g. http://localhost:7071/api/[function name]:
              • Your breakpoint will now be hit and you can make use of all of VS Code’s debugging capabilities:

              NOTE:- debugging C# functions isn't quite this simple in VS Code. See my section later on this.
              So the CLI isn't useful on it's own?
              At this point, you might be wondering why you'd work with Azure Functions using the CLI if you need to use Visual Studio Code to debug. Me too! The Azure Functions extension for VS Code is essentially running the commands against the CLI for you, and gives you some menu options/commands in the command pallette to work with, thus providing a much nicer experience. For me, the only scenarios where you'd focus on the CLI for running/publishing functions are:
              • DevOps scenarios, where you have some automation scripts to run/test your functions (either locally or by deploying them up to Azure)
              • You're trying to be ultra-hip
              For everything else, there's Visual Studio Code or Visual Studio. Disagree? Am I missing something? Let me know in the comments!

              Option 2 – with Visual Studio Code



              Creating a function in VS Code is easy:

              1. First, create a folder on your machine to host the files – I named my folder “COB-JS-Functions” to reflect what we’re doing here.
              2. Open VS Code to this folder.
              3. Hit CTRL SHIFT + P for the VS Code command bar, and start typing “Azure Functions” to pull up those commands. Select the “Create New Project” command:
              4. Follow the prompts in the command bar to select the folder – accept the default if you’re already in the folder you created earlier:
              6. When it comes to selecting a language, select your preference – I’m using JavaScript here (and you might want to consider my overall message that C# functions are generally easier in full-blown Visual Studio!):
              7. Your folder will now be scaffolded with the starter files:

              8. Now let’s add an individual function. Hit CTRL SHIFT + P again, and find the “Create Function” command under Azure Functions:
              9. Accept that we’ll use the current folder:
              10.   Select the trigger:
              11. Enter the name for your function:
              12. And then the authentication type:
              13. A bunch of new files will now be added to your folder, including the “index.js” file for your function implementation:

              You can now code away and start to build out your function. Most likely you’ll want to bring in some npm modules for a JavaScript function, and start to work against the Graph, SharePoint or whatever you need. I really like being guided through the process through the VS Code command palette, I think it works really well.

              Debugging Azure Functions locally in Visual Studio Code

              VS Code works great as a debugger for JavaScript functions, PowerShell scripts and more. The next sections have a couple of notes on language-specific details:

              For JavaScript Functions 

              JavaScript mainly “just works”, although you’ll need to hit the local URL your function is hosted on (e.g. with Postman or similar) by default. You can go a step further and amend your launch.json file so that F5 does everything - I had to add a configuration for ‘launch’ as well as ‘attach’. The process looks like this:

              1. Add a breakpoint to your code.
              2. Once your launch.json is good, ensure you have a “launch” configuration selected in the debug config selector – this ensures node.js is started, rather than assuming it’s running already and you can attach to it:
              3. You should see VS Code spin up the functions host for you by running func host start:

              4. You’ll actually need to hit the URL for your function to start the execution and hit your breakpoint. VS Code makes this easy by providing a clickable link in the terminal output:
              5. This will open a new browser tab, hit your function endpoint, and your breakpoint will be hit
              For PowerShell Functions

              See my “Running a PowerShell script in the cloud with an Azure Function, PnP and the Graph” article, specifically the “Debugging our PowerShell script locally with F5” section – I show the process in detail here. In short it works well, but remember that PowerShell only has experimental language status in Functions V1, and this did not go forward into V2.

              For C# Functions

              Well, debugging C# functions which are .cs files (not .csx) in Visual Studio Code is somewhat different – the OmniSharp extension is required (https://marketplace.visualstudio.com/items?itemName=ms-vscode.csharp) and there is some shennanigans involved to debug V1 functions since they are 32-bit. See https://github.com/Microsoft/vscode-azurefunctions/blob/master/docs/func64bit.md. Overall I feel that full Visual Studio is a simpler approach for C# functions.

              Publishing files to an Azure Function from VS Code:

              In the spirit of re-use, this section comes straight from my PowerShell functions article :) The steps here are the same regardless of your function language.

              You can publish your function to Azure in a variety of ways, but VS Code makes this easy:

              1. Switch to Azure tab in VS Code (bottom icon):

              2. Find the Function App you created earlier. Right-click on it, and select “Deploy to Function App”:
              3. Step through prompts in the VS Code command palette – the defaults are generally what you need:

              4. Accept the prompt:


              5. VS Code will then start the publish operation:

              6. You’ll then find that your files have been deployed as a Function to the selected Function App:


              Option 3 – using Visual Studio

              Visual Studio is my preferred option for C# functions (for the moment at least).



              There is a VS project template, so creating a new project is easy:

              1. Create a new project using Create > New Project:
              2. Add a new Function from the context menu on the project:
                Select the trigger type:

              Debugging a function in Visual Studio:

              This is as simple as adding a breakpoint and hitting F5. For C# functions, as things stand this is much simpler than the other options. You’ll see the Core Tools function host spin-up, and the URL of your function will be provided – you’ll need to hit this in a browser or with Postman, although you could configure the “Debug” tab of your project to launch a browser or script to do this automatically (similar to the idea of editing the launch.json file if using Visual Studio Code):


              Your breakpoint will then be hit:


              Remember that you can also debug a function running live in Azure if it was published in debug mode. If you’re developing against a dev/test Office 365 tenant and Azure subscription this can be very helpful (but not recommended for production obviously). Use the Cloud Explorer to find your function, right-click and select “Debug”.

              Publishing a function from Visual Studio

              Anyone who’s worked with functions in VS is probably familiar with this, but as you’d expect it’s a slick experience:



              But as the saying goes, friends don’t let friends publish Azure Functions directly to production (and potentially other environments too). Use one of the other deployment methods, perhaps one based on continuous deployment if appropriate. 


              That was quite a lot detail. In summary, if you write the majority of your other code with VS Code and/or are writing functions in JavaScript, then VS Code is probably your best choice – just make sure you install the Azure Functions VS Code extension. If you’re mainly using full Visual Studio, then stick with that for functions development too – just make sure you install the Azure Functions Visual Studio extension if your VS instance doesn’t have it already.

              Using the Core Tools directly from the command-line is best-suited to CI/CD/DevOps automation, or those who feel the need to be particularly hipster.

              Tuesday, 18 September 2018

              An Azure Function to keep other Functions/URLs warmed up

              imageJust a very quick post to share some code that might be useful. If you’re running Azure Functions on a consumption plan (i.e. pay for what you use), then you might know that a function app can go to sleep, leading to cold start issues. If it’s code you’re running behind a web part, PowerApp or other user-facing thing (usually on a HTTP trigger), then every now and then users will get really bad performance as they wait for the function app to spin back up again. Currently the timeout period for Azure Functions is 20 minutes – so if there are periods where your function won’t run, you’ll suffer from this issue.

              As noted in Understanding serverless cold start and Azure Functions cold starts in numbers, just how long it takes to warm-up your function depends on many things. JavaScript functions can be slower than other languages if you’re using lots of npm modules for example.

              You *could* switch to an App Service plan for your function. But then your costs will (typically) be much higher because you’re paying for dedicated VM instances in Azure, rather than taking advantage of one of the key advantages of serverless, in that you can pay for only the time your code is executing.

              So, why not have another function which runs on a timer and just hits a series of URLs you specify in config?  This is a nice way of having one centralized function that can help out with *many* other functions distributed across many function apps on a consumption plan. So long as this code runs more frequently than the timeout period, you can be guaranteed that your other functions will be kept alive and performance will be good. Of course, there are numerous ways you could do this (a PowerShell script running somewhere, a Flow which executes on a schedule etc.) but if you like the idea of another function, then you can copy/paste my code below and get the solution implemented in minutes.

              Here’s some code for a C# function to do this. You might want to take things further in terms of error-handling or something else, but it does the core job and might save you a quick coding/testing exercise - simply create a new C# function and use this as the implementation:

              The code above expects an App Setting named “EndPointUrls” where the value contains a list of semi-colon separated URLs - your code will hit each of these:


              You should then see a successful execution every 10 minutes (or whatever schedule you chose):


              NOTE – you should be able to run *this* function on a consumption plan too without any problems. I’ve seen issues with timer functions not running in some circumstances, but none should apply in this case. But look out for these in your other timer functions perhaps:

              • Functions which make async HTTP calls with HttpClient or similar, but are not async “all the way down”. To make use of this with “await”, you should change the signature of your Run() method to be:
              • Functions which run for longer than the schedule e.g. runs for 1 minute 20 seconds but is scheduled every minute. Of course you’ll miss executions!
                • NOTE – the myTimer.IsPastDue property show in my first log statement can help you understand if this execution is due to this
              • Functions being missed due to app restarts
                • You might want to consider what other things exist in the same Function App
              • Look at the “useMonitor” flag for frequently-running functions

              Also see:

              Friday, 31 August 2018

              Using a custom Azure Function in PowerApps (e.g. to call the Graph)

              In the last post we looked at how to call out to your custom code from Flow. In this article I want to talk about the similar process for PowerApps, so that we can get to the point when our own code is running - perhaps when a button is clicked in the PowerApp or a screen in the app loads. This article is essentially a companion article to the last one. In fact, we did the important work of creating a custom connector (required by both PowerApps and Flow to call into our function code) there – so if you’re using my posts as a guide, you’ll need to reference my Flow article even if you’re only working with PowerApps. Here are the links again:

              In both cases, it’s all about creating a custom connector which talks to your Azure Function, and then using the connector appropriately in PowerApps/Flow.

              A recap on the overall process

              Essentially the bit that’s different between PowerApps and Flow is the bit at the end – the overall process looks like this:


              A PowerApp to update the user’s profile

              In my last article, I used the idea of an Azure Function/custom connector that can update the user’s Office 365 profile from Flow. We’ll use the very same Azure Function/custom connector but from PowerApps this time. Since we already have the connector defined, it’s fairly easy to start using it in PowerApps.

              I created a fairly simple PowerApp that uses each of my API’s functions:

              • Fetch profile details –> run when the “Lookup user” button is clicked
              • Update profile details –> run when the “Update user” button is clicked

              In some ways, this could potentially be a useful PowerApp in the enterprise with a bit more work. Perhaps it could be useful for first line employees who rarely use a desktop PC, but occasionally need to update their profile for example. In any case, the overall recipe of a PowerApp which can do powerful things by calling into an Azure Function is certainly a useful technique to have in the toolbox.

              For my app, I didn’t do too much on the user interface - here’s what it looks like:


              In real life I’d lose the “Lookup user” button and just have the user’s existing data be loaded when the app loads – but for now, having the two buttons is useful to help illustrate my two methods and how to wire things up. If you did want to fetch the data without a button click, you would just take the PowerApps formula in the “Lookup user” button’s OnSelect event and use it in the first screen’s OnStart or OnVisible event instead.

              Adding a data source

              Once you have your connector created and made available, to use it in PowerApps you need to add a data source which points to the connector. You can then use your methods in PowerApps formulas. Creating the data source is done like this:



              In the panel that appears now, find the connector which represents your API/Azure Function:


              It should then be successfully added:


              That’s it – you can now call your Azure Function from PowerApps.

              Wiring up to app controls

              Essentially, what you’ll find is that when you’re typing a formula somewhere in PowerApps, your API is available and has some auto-completion/IntelliSense on the methods. So in my case, I can start typing ‘cob’ and then my API’s methods appear:


              When I select a method, I get prompted for the parameter(s) required:



              Using in practice

              The first thing we do is set the default value of the text input controls to the appropriate value of the JSON object returned from fetching the user’s data – for example, here’s the display name text box:


              All we’re doing here is working with variables in PowerApps, but if you’re new to this there is some weirdness compared to coding. You need to understand PowerApps commands such as Set, UpdateContext, Collect/ClearCollect etc. This guide helps you out - Understand canvas-app variables in PowerApps

              Once our text input controls are set to display the values of the “fetchedUserData” variable, we populate that object by calling into our custom connector.

              On the “Lookup user” button’s OnSelect event  (or screen OnVisible event) – note that we’re passing in the current user’s account name from the label next to the photo. This is simply obtained from User() function in PowerApps, specifically User().Email (I’m assuming the e-mail address matches the account name in this case):

              Consider that what we're doing here is calling the function once, and then storing the overall JSON returned as a variable. This matches up with how I've assigned the default value of my text input controls i.e. fetchedUserData.displayName.

              On the “Update user” button:

              NOTE: Don’t make the mistake of calling your function multiple times, once for each time you reference a value. That would look like this:

              As per the comment, this approach means that your function is called multiple times rather than just once. Instead, ensure you call your function just once and then store the returned JSON in a variable. Each form control then references a child element of that JSON.


              That’s it! You can now use Azure Functions within your PowerApps, which can open up lots of possibilities. In production you’ll need to consider who the custom connector is shared with/how it is made available (amongst other things), but the general process is quite straight-forward once you’ve done the hard work of defining your Open API definition etc.